Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

console title should change after youtube-dl finishes [fails in Terminal.app] #1782

Open
phihag opened this issue Nov 17, 2013 · 19 comments
Open
Labels

Comments

@phihag
Copy link
Contributor

@phihag phihag commented Nov 17, 2013

Reported by @joeschmoe40:

If you use --console-title, the console title is left changed (messed up)
after the program exits (at least on Mac OSX).

@phihag
Copy link
Contributor Author

@phihag phihag commented Nov 17, 2013

Can you elaborate messed up? What would you expect to see if youtube-dl finishes? As far as I understand console titles, a program can just set them, not get or unset them.

@joeschmoe40
Copy link

@joeschmoe40 joeschmoe40 commented Nov 17, 2013

I don't claim to be particularly knowledgeable about these things, but I think it is possible for a program to set it to something special while the program is running but then have it revert to whatever it was before when the program exits.  I've seen other programs that do this.

And, by "messed up", I mean, it still says something like "YouTube.DL 100% of 3 Mb or whatever or whatever", in the console title, after it has returned to the shell prompt.

Note, BTW, that I can fix this (on the Mac), after the shell prompt has returned, by typing Shift/Command/I, then Enter and Ctrl/W.  But this is obviously not optimal.

On Sunday, November 17, 2013 6:32 AM, Philipp Hagemeister notifications@github.com wrote:

Can you elaborate messed up? What would you expect to see if youtube-dl finishes? As far as I understand console titles, a program can just set them, not get or unset them.

Reply to this email directly or view it on GitHub.

@phihag
Copy link
Contributor Author

@phihag phihag commented Nov 17, 2013

Can you name at least one program that you've seen that does this?

@joeschmoe40
Copy link

@joeschmoe40 joeschmoe40 commented Nov 17, 2013

Well, to answer your specific question: Not in a way that you would find useful.

However, I Googled "retrieve xterm window title" and this URL:

http://www.perlmonks.org/?node_id=792957

seems to speak to the problem and suggests that it is possible.  The context is Perl, but it seems generic.  I did not take the time to follow all the ins-and-outs of that article/thread, but you might find it useful.

On Sunday, November 17, 2013 9:04 AM, Philipp Hagemeister notifications@github.com wrote:

Can you name at least one program that you've seen that does this?

Reply to this email directly or view it on GitHub.

@phihag phihag closed this in bdde425 Nov 17, 2013
@phihag
Copy link
Contributor Author

@phihag phihag commented Nov 17, 2013

Thank you for the report. This has been fixed in youtube-dl 2013.11.17. Type sudo youtube-dl -U to update.

@joeschmoe40
Copy link

@joeschmoe40 joeschmoe40 commented Nov 18, 2013

Alas, it doesn't work (at least on Mac OSX):

$ python --version
Python 2.7.2
$ youtube-dl.py --version
2013.11.17
$ youtube-dl.py --console-title --no-mtime --write-description -q -o xxx.flv "http://www.youtube.com/watch?..."

downloads the file, but leaves my console title as:

youtube-dl - 100.0% of 6.84MiB at 1.12MiB/s ETA 00:00  -- bash -- 84x25

(which I then need to fix manually, using the Command/Shit/I interface)

On Sunday, November 17, 2013 4:26 PM, Philipp Hagemeister notifications@github.com wrote:

Thank you for the report. This has been fixed in youtube-dl 2013.11.17. Type sudo youtube-dl -U to update.

Reply to this email directly or view it on GitHub.

@phihag phihag reopened this Nov 18, 2013
@phihag
Copy link
Contributor Author

@phihag phihag commented Nov 18, 2013

Mmm, that's unfortunate. You're using Terminal.App instead of xterm, right? Unfortunately I can't find a way to buy Mac OS X online, let alone get a free trial. Sorry, but that means that we'll have to wait until someone to test it. vim seems to use XGetWMName, but that's only useful for X-based applications. I can't find the title-restoring code in the vim OSX code.

@joeschmoe40
Copy link

@joeschmoe40 joeschmoe40 commented Nov 18, 2013

Well, it was worth a shot (and thanks for the effort, BTW).

Yes, I am using the Terminal App.  I can also use xterm (it is installed on this machine; I've debated various workarounds for this issue that involve launching an xterm to do the actual downloading - it is on the plate...)

BTW, I just tested it now in an xterm and it does work correctly.  Unfortunately, I never got around to doing this test using the older version, so I can't be sure that the fix took place as scheduled.  Is there any way to get hold of older versions from the site? (If not, no big deal, I think I can find it somewhere else...)

For what it is worth, when you first asked if I knew of any app that does this correctly, my first thought was "vi", because when I launch vi from the shell prompt (in Terminal), the console title changes to something that indicates vi is running, then changes back to something containing "bash" after vi exits.  But I don't think this is being done by the "vi" app; it seems to be just a functionality of bash (as implemented on Mac OSX) and/or the Terminal App itself.  Further, note that other command line apps seem to have the same problem - they change the console title, but don't fix it on exit and it stays "messed up" until I manually fix it.  "ssh" is one such - if I "ssh" to another machine, on exit, the console title contains a complicated string including the name of the user and machine that I "ssh"'d to.  As noted, this persists until fixed manually.

Anyway, I guess we can call this "closed" at least for the time being...

On Monday, November 18, 2013 8:48 AM, Philipp Hagemeister notifications@github.com wrote:

Mmm, that's unfortunate. You're using Terminal.App instead of xterm, right? Unfortunately I can't find a way to buy Mac OS X online, let alone get a free trial. Sorry, but that means that we'll have to wait until someone to test it. vim seems to use XGetWMName, but that's only useful for X-based applications. I can't find the title-restoring code in the vim OSX code.

Reply to this email directly or view it on GitHub.

@joeschmoe40
Copy link

@joeschmoe40 joeschmoe40 commented Nov 18, 2013

Update: Just tested the old version in an xterm.  It does leave the console title messed up.  So, the fix did work - for xterms.  (But not for Terminals...)

On , J S joeschmoe40@yahoo.com wrote:

Well, it was worth a shot (and thanks for the effort, BTW).

Yes, I am using the Terminal App.  I can also use xterm (it is installed on this machine; I've debated various workarounds for this issue that involve launching an xterm to do the actual downloading - it is on the plate...)

BTW, I just tested it now in an xterm and it does work correctly.  Unfortunately, I never got around to doing this test using the older version, so I can't be sure that the fix took place as scheduled.  Is there any way to get hold of older versions from the site? (If not, no big deal, I think I can find it somewhere else...)

For what it is worth, when you first asked if I knew of any app that does this correctly, my first thought was "vi", because when I launch vi from the shell prompt (in Terminal), the console title changes to something that indicates vi is running, then changes back to something containing "bash" after vi exits.  But I don't think this is being done by the "vi" app; it seems to be just a functionality of bash (as implemented on Mac OSX) and/or the Terminal App itself.  Further, note that other command line apps seem to have the same problem - they change the console title, but don't fix it on exit and it stays "messed up" until I manually fix it.  "ssh" is one such - if I "ssh" to another machine, on exit, the console title contains a complicated string including the name of the user and machine that I "ssh"'d to.  As noted, this persists until fixed manually.

Anyway, I guess we can call this "closed" at least for the time being...

On Monday, November 18, 2013 8:48 AM, Philipp Hagemeister notifications@github.com wrote:

Mmm, that's unfortunate. You're using Terminal.App instead of xterm, right? Unfortunately I can't find a way to buy Mac OS X online, let alone get a free trial. Sorry, but that means that we'll have to wait until someone to test it. vim seems to use XGetWMName, but that's only useful for X-based applications. I can't find the title-restoring code in the vim OSX code.

Reply to this email directly or view it on GitHub.

@jaimeMF jaimeMF closed this in efd6c57 Nov 18, 2013
phihag added a commit that referenced this issue Nov 18, 2013
Correctly write and restore the console title on the stack (fixes #1782)
@phihag
Copy link
Contributor Author

@phihag phihag commented Nov 18, 2013

Reopening, it still doesn't work in Terminal.app, or does it?

@phihag phihag reopened this Nov 18, 2013
@jaimeMF
Copy link
Collaborator

@jaimeMF jaimeMF commented Nov 18, 2013

You're right. Anyways, you can install iTerm2 (open source).
I don't know if Terminal.app has support for those escape codes, someone will have to figure it out.

@joeschmoe40
Copy link

@joeschmoe40 joeschmoe40 commented Nov 19, 2013

Apropos of nothing, but I tried out iTerm2 - same problem (I.e., like the regular Terminal app, the title stays "messed up" after youtube-dl exits).

(Tested with latest - 2013-11-17 version)

On Monday, November 18, 2013 11:07 AM, Jaime Marquínez Ferrándiz notifications@github.com wrote:

You're right. Anyways, you can install iTerm2 (open source).
I don't know if Terminal.app has support for those escape codes, someone will have to figure it out.

Reply to this email directly or view it on GitHub.

@jaimeMF
Copy link
Collaborator

@jaimeMF jaimeMF commented Nov 19, 2013

@joeschmoe40 there isn't yet a new version, it has only been committed to the repo.

@phihag
Copy link
Contributor Author

@phihag phihag commented Nov 19, 2013

@jaimeMF Oh, does iTerm2 need the ;0? Sorry, I didn't get that. @joeschmoe40 2013.11.18 should add iTerm2 support.

@joeschmoe40
Copy link

@joeschmoe40 joeschmoe40 commented Nov 19, 2013

Oh, OK.  No worries, then.

Previous texts seemed to imply that it would already work with iTerm2.
Didn't realize that the program needed to be updated for iTerm2 to work.

On Tuesday, November 19, 2013 6:45 AM, Philipp Hagemeister notifications@github.com wrote:

@jaimeMF Oh, does iTerm2 need the ;0? Sorry, I didn't get that. @joeschmoe40 2013.11.18 should add iTerm2 support.

Reply to this email directly or view it on GitHub.

@jaimeMF
Copy link
Collaborator

@jaimeMF jaimeMF commented Nov 19, 2013

@phihag the ;0 is needed for both iTerm and the version of xterm that comes with OSX. Terminal.app doesn't seem to support those escape codes.
Sorry for the confusion.

@joeschmoe40
Copy link

@joeschmoe40 joeschmoe40 commented Nov 19, 2013

I just d/l'd the 2013.11.19 version.  Confirmed: It now works correctly in iTerm2.  Still doesn't work right in Terminal.App (as you've said).

Also, despite what you said, I think it has always worked in xterm (under OSX).  I'm pretty sure I tested with pretty old versions and had it do the right thing in an xterm - as I've detailed upthread.

On Tuesday, November 19, 2013 8:36 AM, Jaime Marquínez Ferrándiz notifications@github.com wrote:

@phihag the ;0 is needed for both iTerm and the version of xterm that comes with OSX. Terminal.app doesn't seem to support those escape codes.
Sorry for the confusion.

Reply to this email directly or view it on GitHub.

@jaimeMF
Copy link
Collaborator

@jaimeMF jaimeMF commented Nov 19, 2013

Oops, I tested an old version in xterm and you're right, it works. I was switching between the three programs, so I probably got confused,

@joeschmoe40
Copy link

@joeschmoe40 joeschmoe40 commented Nov 19, 2013

Perhaps beating a dead horse here, but just to clarify further, I just tested on xterm with the 11/16 version and it is messed up.  It got fixed for xterms sometime after 11/16 - presumably on the first commit in which this was marked as "fixed".  It has been OK for xterm ever since...

And now it works for iTerm2.

But not (alas) for Terminal.App...

On Tuesday, November 19, 2013 2:13 PM, Jaime Marquínez Ferrándiz notifications@github.com wrote:

Oops, I tested an old version in xterm and you're right, it works. I was switching between the three programs, so I probably got confused,

Reply to this email directly or view it on GitHub.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.