poor <&- behavior under ulimit -n
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -DRECYCLES_PIDS -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic uname output: Linux office 2.6.34.7-61.fc13.x86_64 #1 SMP Tue Oct 19 04:06:30 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-redhat-linux-gnu Bash Version: 4.1 Patch Level: 7 Release Status: release Description: Bash does not behave well when under artificial fd pressure due to ulimit -n. It issues a spurious warning to stderr because it tries to save necessary fds starting at 10. Compare this with ksh93, which saves fds starting at 3. Many other shells (for example, dash or BSD /bin/sh) exit with non-zero status if they can't use fd 10, rather than proceeding onwards. At any rate, bash MUST exit with failure if it cannot save an fd, even if you decide that it is unsafe to copy ksh93's action of saving at fd 3 rather than 10. The current behavior results in bash silently corrupting stdin! Merely warning me that you lost stdin, but still exiting with 0 status, is a disservice. Repeat-By: $ ksh -c 'ulimit -n 10; : <&-; exec 3<&0'; echo $? 0 $ ksh -c 'ulimit -n 3; : <&-; exec 3<&0'; echo $? ksh[1]: open file limit exceeded [Invalid argument] 1 $ ksh -c 'ulimit -n 10; : <&-'; echo $? 0 $ bash -c 'ulimit -n 11; : <&-'; echo $? 0 $ # This next step should either silently work or die with an error $ bash -c 'ulimit -n 10; : <&-'; echo $? bash: redirection error: cannot duplicate fd: Invalid argument 0 $ # Proof that you silently lost stdin during the : <&- step. $ bash -c 'ulimit -n 10; : <&-; exec 3<&0'; echo $? bash: redirection error: cannot duplicate fd: Invalid argument bash: 0: Bad file descriptor 1 Fix: The bare minimum fix is to error out if you cannot dup() a fd to preserve it across the duration of a temporary redirection. But the nicer fix would be to follow ksh's lead and start saving fd's at 3, even if this means doing more bookkeeping of which fds have been put into use by the user vs. used by bash (that is, if stdin was saved by bash in fd 3, but then the script asks to redirect fd 3, then bash would have to re-save fd 3 to somewhere else). -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Ctrl-L does nothing
Configuration Information [Automatically generated, do not change]: 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='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2 uname output: Linux chorion 2.6.26-2-vserver-686 #1 SMP Thu Sep 16 23:09:48 UTC 2010 i686 GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 4.0 Patch Level: 0 Release Status: release Description: From a fresh installed Debian Lenny, and a CentOS 5 in a Linux-Vserver, I've downloaded and compiled bash 4.0, and Ctrl-L does nothing, but going to a new prompt line as a single Enter would. usually Ctrl-L clear the screen. Repeat-By: Ctrl-L
Re: Ctrl-L does nothing
hum...@chorion.ath.cx wrote: > From a fresh installed Debian Lenny, and a CentOS 5 in a > Linux-Vserver, I've downloaded and compiled bash 4.0, and Ctrl-L > does nothing, but going to a new prompt line as a single Enter > would. usually Ctrl-L clear the screen. Thank you for the report. Please keep bug-bash in the recipient list for any follow-ups so that the group can participate. This behavior that you describe is the behavior that bash uses when it does not have termcap/terminfo for your terminal type. Does 'clear' do anything in your present environment? $ clear Normally that would produce terminal escape sequences but if it doesn't then that would be another indicator that your terminal is not configured sufficiently. What is your TERM variable? $ echo $TERM Bob
Re: Ctrl-L does nothing
On 10/27/10 8:09 AM, hum...@chorion.ath.cx wrote: > Configuration Information [Automatically generated, do not change]: > 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='/usr/local/share/locale' -DPACKAGE='bash' > -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2 > uname output: Linux chorion 2.6.26-2-vserver-686 #1 SMP Thu Sep 16 23:09:48 > UTC 2010 i686 GNU/Linux > Machine Type: i686-pc-linux-gnu > > Bash Version: 4.0 > Patch Level: 0 > Release Status: release > > Description: > From a fresh installed Debian Lenny, and a CentOS 5 in a > Linux-Vserver, I've downloaded and compiled bash 4.0, and Ctrl-L does > nothing, but going to a new prompt line as a single Enter > would. > usually Ctrl-L clear the screen. > > Repeat-By: > Ctrl-L Make sure that C-l is bound to clear-screen (bind -p | grep clear) and make sure the terminal you're using has the `cl' termcap capability. All the clear-screen command does is send whatever string the `cl' capability is bound to to the display. 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/
