GNOME Bugzilla – Bug 724982
Zsh should not print VTE escape sequences during cd when stdout is not terminal
Last modified: 2014-03-27 18:16:39 UTC
Reason: it breaks scripts / commands. How to reproduce: zsh (cd)|hexdump -C Attached patch fixes the problem for me.
Created attachment 270019 [details] [review] Patch
I don't think the patch is right. The vte.sh script already is only doing anything for interactive shells: # Not an interactive shell? [[ $- == *i* ]] || return 0 This works for bash; possibly it needs some other test to work in zsh ?
According to http://zsh.sourceforge.net/Guide/zshguide02.html , zsh's way is [[ -o interactive ]]
Oh, sorry, according to http://zsh.sourceforge.net/Doc/Release/Parameters.html#Parameters-Set-By-The-Shell , $- also works.
(In reply to comment #2) > I don't think the patch is right. The vte.sh script already is only doing > anything for interactive shells: > > # Not an interactive shell? > [[ $- == *i* ]] || return 0 This does not help. If you run a command in a subshell of an interactive shell, e.g. you run interactively "(cd)", the interactive flag is still set in the subshell. Morover vte.sh is not evaluated in this case at all. The difference between bash and zsh is that for zsh we hook into cd command, whereas for bash we print the escape sequence as a part of the prompt. Therefore under bash, "(cd)" itself does not print anything. Maybe, correct thing for zsh would be to hook into prompt expansion, similarly as it is done in bash. Current hooking into cd has another drawback. Consider the following sequence of commands: # In gnome-terminal zsh cd # Change to $HOME (cd /tmp) # Change to /tmp in subshell # We're still in $HOME # Open new tab in gnome-terminal - this opens in /tmp instead of at # $HOME Thanks, -Michal
(In reply to comment #5) > This does not help. If you run a command in a subshell of an interactive > shell, e.g. you run interactively "(cd)", the interactive flag is still > set in the subshell. But then "test -t 1" wouldn't work either, would it? This also evaluates to true in a subshell. > Maybe, correct thing for zsh would be to hook into prompt expansion, > similarly as it is done in bash. Sounds the right thing for me to do.
(In reply to comment #6) > (In reply to comment #5) > > > This does not help. If you run a command in a subshell of an interactive > > shell, e.g. you run interactively "(cd)", the interactive flag is still > > set in the subshell. > > But then "test -t 1" wouldn't work either, would it? This also evaluates to > true in a subshell. Yes, but my original problem was that the output of a command redirected to a file contained some garbage (i.e. VTE escape sequence). Calling test -t helped in this case. > > Maybe, correct thing for zsh would be to hook into prompt expansion, > > similarly as it is done in bash. > > Sounds the right thing for me to do. I'm attaching an updated patch.
Created attachment 270081 [details] [review] Patch that changes zsh hook used to print VTE escape sequence
Fixed in vte-0-36. Keeping open for vte-next.
Thanks Michal, it was a nice catch! :)
Fixed on master.