Inconsistent output in terminal emulator
Hi, I'm writing a simple terminal emulator (on linux using standard pty libraries) and have run across some behavior in bash that I cannot explain after several weeks of reading documentation. When I run a different shell, say zsh, it behaves the way I expect an interactive shell would. As characters are sent to the shell to build the command, the shell sends the characters back to the terminal to display. However with bash, the shell doesn't respond at all until a is sent, and then bash only sends the output of the command, not the command itself. If my terminal emulator is expecting the shell to provide all display text, it wouldn't show the commands at all. In all other ways, bash behaves like an interactive shell. My ...rc files are used correctly, and I can effectively launch and interact with other programs. The oddest part of all is that bash will start behaving like zsh if I run zsh, then exit back to bash, even though it's still the same process with the same environment. Can anyone explain why bash is operating in one mode or the other, and how I can explicitly set this behavior one way or the other? Thanks! Nico Here is log showing this. bash: no job control in this shell [BASH nra...@sofia:~]$ <- [BASH nra...@sofia:~]$ pwd <- pwd /home/nraffo <- # bash only sends back pwd output [BASH nra...@sofia:~]$ zsh <- zsh [ZSH nra...@sofia:~]$ <- <- # zsh repeats the command [ZSH nra...@sofia:~]$ pwd <- pwd pwd<- # zsh repeats the command /home/nraffo [ZSH nra...@sofia:~]$ exit <- exit exit <- # zsh repeats the command [BASH nra...@sofia:~]$ <- <- # now bash also repeats the command [BASH nra...@sofia:~]$ pwd <- pwd pwd<- # bash repeating command /home/nraffo [BASH nra...@sofia:~]$ --- Restarting in no-repeat mode: (These don't change after going in and out of zsh) --- bash: no job control in this shell [BASH nra...@sofia:~]$ [BASH nra...@sofia:~]$ set BASH=/bin/bash BASH_ARGC=() BASH_ARGV=() BASH_LINENO=() BASH_SOURCE=() BASH_VERSINFO=([0]="3" [1]="00" [2]="15" [3]="1" [4]="release" [5] ="x86_64-redhat-linux-gnu") BASH_VERSION='3.00.15(1)-release' COLORS=/etc/DIR_COLORS COLUMNS=168 DIRSTACK=() EDITOR=vi EUID=455 GROUPS=() G_BROKEN_FILENAMES=1 HISTFILE=/home/nraffo/.bash_history HISTFILESIZE=1000 HISTSIZE=1000 HOME=/home/nraffo HOSTNAME=sofia.XXX.com HOSTTYPE=x86_64 IFS=$' \t\n' INPUTRC=/etc/inputrc LANG=en_US.UTF-8 LESSOPEN='|/usr/bin/lesspipe.sh %s' LINES=44 LOGNAME=nraffo LS_COLORS= MACHTYPE=x86_64-redhat-linux-gnu MAIL=/var/spool/mail/nraffo MAILCHECK=60 MYVIMRC=/home/nraffo/.vimrc OPTERR=1 OPTIND=1 OSTYPE=linux-gnu PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/ home/nraffo/bin PIPESTATUS=([0]="0") PPID=31674 PS1='[BASH \...@\h:\w]$ ' PS2='> ' PS4='+ ' PWD=/home/nraffo SHELL=/bin/bash SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:interactive- comments SHLVL=3 SSH_CLIENT='10.10.0.64 50457 22' SSH_CONNECTION='10.10.0.64 50457 10.10.1.14 22' SSH_TTY=/dev/pts/1 SUPPORTED=en_US.UTF-8:en_US:en TERM=dumb TERMCAP=COLUMNS=168 UID=455 USER=nraffo VIM=/home/nraffo/.mybin/vim72/share/vim VIMRUNTIME=/home/nraffo/.mybin/vim72/share/vim/vim72 VIMSHELL=1 _=env [BASH nra...@sofia:~]$
'set -e' and 'trap 0' togheter does not work as expected on syntax errors
I have the following scripts: $ cat nobug.sh trap 'e=$?; [ $e -gt 0 ] && echo "OK" || echo "BAD"; exit $e' 0 # syntax error here && true $ cat bug.sh set -e trap 'e=$?; [ $e -gt 0 ] && echo "OK" || echo "BAD"; exit $e' 0 # syntax error here && true I thought that when bash detect a syntax errors in the script, it would pass a $? != 0 to the code in the exit trap, regardless of whether `set -e' is active or not. But if I run bug.sh with either bash-3.2 or bash-4.0, I get: $ bash bug.sh; echo $? bug.sh: line 4: syntax error near unexpected token `&&' BAD 0 On the other hand: $ bash nobug.sh; echo $? nobug.sh: line 4: syntax error near unexpected token `&&' nobug.sh: line 4: `&& true' OK 2 $ dash bug.sh; echo $? # Debian Alquist shell, version 0.5 bug.sh: 4: Syntax error: "&&" unexpected OK 2 $ zsh bug.sh; echo $? # Zsh, version 4.3 nobug.sh:4: parse error near `&&' OK 1 I think this can be classified as a bug in bash (in some situations, a very nasty one). Please let me know if I have misunderstood something, or if there is a simple workaround. More details about my environment and bash versions follow... --- Details on operating system: $ uname -s -r -m -o Linux 2.6.26-1-686 i686 GNU/Linux $ lsb_release -i -d -r -c Distributor ID: Debian Description: Debian GNU/Linux testing/unstable Release: testing/unstable Codename: n/a $ cat /etc/debian_version squeeze/sid --- Details on bash versions: Bash 4.0 --- Installed by hand from official tarball Complete version string: 4.0.0(1)-release Information from bashbug [Automatically generated]: Machine: i686 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/opt/bleedingedge/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I.. -I../include -I../lib -g -O2 Machine Type: i686-pc-linux-gnu Bash Version: 4.0 Patch Level: 0 Release Status: release Bash 3.2 --- Installed from debian package "bash", version "3.2-6" Complete version string: 3.2.48(1)-release Information from bashbug [Automatically generated]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 -Wall Machine Type: i486-pc-linux-gnu Bash Version: 3.2 Patch Level: 48 Release Status: release ---
bash won't let me bind \C-w
bash-4.0$ a () { bind '"\C-w": unix-filename-rubout'; }
bash-4.0$ b () { bind -p | grep 'unix.*rubout'; }
bash-4.0$ a; b
"\C-w": unix-filename-rubout
# unix-word-rubout (not bound)
bash-4.0$ b
# unix-filename-rubout (not bound)
"\C-w": unix-word-rubout
bash-4.0$
Same in bash-3.2.
bug with 'set -e' + 'trap 0' + syntax error
I have the following scripts: $ cat nobug.sh trap 'e=$?; [ $e -gt 0 ] && echo "OK" || echo "BAD"; exit $e' 0 # syntax error here && true $ cat bug.sh set -e trap 'e=$?; [ $e -gt 0 ] && echo "OK" || echo "BAD"; exit $e' 0 # syntax error here && true I thought that when bash detect a syntax errors in a script, it would pass a $? != 0 to the code in the exit trap, regardless of whether `set -e' is active or not. But if I run bug.sh with either bash-3.2 or bash-4.0, I get: $ bash bug.sh; echo $? bug.sh: line 4: syntax error near unexpected token `&&' BAD 0 On the other hand: $ bash nobug.sh; echo $? nobug.sh: line 4: syntax error near unexpected token `&&' nobug.sh: line 4: `&& true' OK 2 $ dash bug.sh; echo $? # Debian Alquist shell, version 0.5 bug.sh: 4: Syntax error: "&&" unexpected OK 2 $ zsh bug.sh; echo $? # Zsh, version 4.3 nobug.sh:4: parse error near `&&' OK 1 I think this can be classified as a bug in bash (in some situations, a very nasty one). Please let me know if I have misunderstood something, or if there is a simple workaround. More details about my environment and bash versions follow... --- Details on operating system: $ uname -s -r -m -o Linux 2.6.26-1-686 i686 GNU/Linux $ lsb_release -i -d -r -c Distributor ID: Debian Description: Debian GNU/Linux testing/unstable Release: testing/unstable Codename: n/a $ cat /etc/debian_version squeeze/sid --- Details on bash versions: Bash 4.0 --- Installed by hand from official tarball Complete version string: 4.0.0(1)-release Information from bashbug [Automatically generated]: Machine: i686 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/opt/bleedingedge/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I.. -I../include -I../lib -g -O2 Machine Type: i686-pc-linux-gnu Bash Version: 4.0 Patch Level: 0 Release Status: release Bash 3.2 --- Installed from debian package "bash", version "3.2-6" Complete version string: 3.2.48(1)-release Information from bashbug [Automatically generated]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 -Wall Machine Type: i486-pc-linux-gnu Bash Version: 3.2 Patch Level: 48 Release Status: release ---
Re: bug with 'set -e' + 'trap 0' + syntax error
Stefano Lattarini a écrit : > I thought that when bash detect a syntax errors in a script, > it would pass a $? != 0 to the code in the exit trap, regardless > of whether `set -e' is active or not. > > I think this can be classified as a bug in bash (in some > situations, a very nasty one). Please let me know if I > have misunderstood something, or if there is a simple > workaround. I am not familiar with the standard(s), but... isn't having expectations in the case of syntax errors a bit far-fetched?
Re: bug with 'set -e' + 'trap 0' + syntax error
> Stefano Lattarini a écrit : > > I thought that when bash detect a syntax errors in a script, > > it would pass a $? != 0 to the code in the exit trap, regardless > > of whether `set -e' is active or not. > > > > [CUT] > > > > I think this can be classified as a bug in bash (in some > > situations, a very nasty one). Please let me know if I > > have misunderstood something, or if there is a simple > > workaround. > > I am not familiar with the standard(s), but... isn't having > expectations in the case of syntax errors a bit far-fetched? > Well, I'd not expect that the exit trap is executed flawlessly, and not even that it is executed at all, but at least the shell should abort the script and exit with a non-zero status. This is a much more rational approach than having the flawed script exiting sucessfully, IMHO. In fact, I've been bitten by this "bug" (or limitation) when a stupid syntax error leaked in some scripts part of a testsuite (that was my fault). The scripts erroneously apperead as PASS'd, while they should have been marked as FAIL'd -- a vary bad thing in my opinion. And I discovered the bug only when I tried to run the testsuite with dash, to check its "portability". Aside that, the exit trap executes correctly even on bash when `set -e' is not active, which makes the described behaviour seeming more a bug rather than a limitation. By the way, sorry for the duplicate message. Regards, Stefano
Re: bash won't let me bind \C-w
Dieter Holkenpolk wrote:
> bash-4.0$ a () { bind '"\C-w": unix-filename-rubout'; }
> bash-4.0$ b () { bind -p | grep 'unix.*rubout'; }
> bash-4.0$ a; b
> "\C-w": unix-filename-rubout
> # unix-word-rubout (not bound)
> bash-4.0$ b
> # unix-filename-rubout (not bound)
> "\C-w": unix-word-rubout
> bash-4.0$
>
> Same in bash-3.2.
The last time this came up, I wrote:
Beginning with bash-3.0, after a number of requests for the feature,
readline began "honoring" the terminal special characters by binding
them to their readline equivalents at startup.
In bash-3.1, this was made dependent on the value of the readline variable
`bind-tty-special-chars', which is on by default.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: 'set -e' and 'trap 0' togheter does not work as expected on syntax errors
Stefano Lattarini wrote: > I have the following scripts: > > $ cat nobug.sh > trap 'e=$?; [ $e -gt 0 ] && echo "OK" || echo "BAD"; exit $e' 0 > # syntax error here > && true > > $ cat bug.sh > set -e > trap 'e=$?; [ $e -gt 0 ] && echo "OK" || echo "BAD"; exit $e' 0 > # syntax error here > && true > > I thought that when bash detect a syntax errors in the script, > it would pass a $? != 0 to the code in the exit trap, regardless > of whether `set -e' is active or not. It's not exactly a bug -- this behavior isn't standardized anywhere, and historical shells behave differently. The behavior you want is useful enough that I'll change it for bash-4.1, though. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
