[bash 3.2.39] File descriptor 10 is always duplicated from 0 and cannot be closed
Hi, all: When I was doing some testing I found the file descriptor 10 is always duplicate of fd 0 and it cannot be closed. See the following commands: # echo $BASH_VERSION 3.2.39(1)-release # read line 10 hello--- input from keyboard # echo $line hello # exec 10---- try to close fd 10 # read line 10--- no error reported, so fd 10 is still open? hello--- input from keyboard # echo $line hello # read line 11--- test with fd 11 bash: 11: Bad file descriptor #
Re: [bash 3.2.39] File descriptor 10 is always duplicated from 0 and cannot be closed
On 2008-10-31, Clark J. Wang wrote: ... # read line 11--- test with fd 11 bash: 11: Bad file descriptor # You haven't opened file descriptor 11: $ ( exec 11$HOME/.bashrc while read 11 do printf . done echo exec 11- ) -- Chris F.A. Johnson, webmaster http://Woodbine-Gerrard.com === Author: Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Re: [bash 3.2.39] File descriptor 10 is always duplicated from 0 and cannot be closed
On Fri, Oct 31, 2008 at 14:59, Chris F.A. Johnson [EMAIL PROTECTED]wrote: On 2008-10-31, Clark J. Wang wrote: ... # read line 11--- test with fd 11 bash: 11: Bad file descriptor # You haven't opened file descriptor 11: You're right. I just want to show the different behavior of fd 10 and 11. Fd 10 is closed but afterward read from it reported no error. That's the problem. $ ( exec 11$HOME/.bashrc while read 11 do printf . done echo exec 11- ) -- Chris F.A. Johnson, webmaster http://Woodbine-Gerrard.com === Author: Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Re: [bash 3.2.39] File descriptor 10 is always duplicated from 0 and cannot be closed
On Fri, Oct 31, 2008 at 14:18, Clark J. Wang [EMAIL PROTECTED] wrote: Hi, all: When I was doing some testing I found the file descriptor 10 is always duplicate of fd 0 and it cannot be closed. See the following commands: # echo $BASH_VERSION 3.2.39(1)-release # read line 10 hello--- input from keyboard # echo $line hello # exec 10---- try to close fd 10 # read line 10--- no error reported, so fd 10 is still open? hello--- input from keyboard # echo $line hello # read line 11--- test with fd 11 bash: 11: Bad file descriptor # And, even though we can read from fd 10 but there's no such an fd under /proc/$$/fd directory.
formatting typo in bash man page
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-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -DRECYCLES_PIDS -I. -I. -I./include -I./lib
-D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe
-Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
-fasynchronous-unwind-tables
uname output: Linux compdna3 2.6.18-92.1.13.el5PAE #1 SMP Thu Sep 4
04:05:54 EDT 2008 i686 i686 i386 GNU/Linux
Machine Type: i686-redhat-linux-gnu
Bash Version: 3.2
Patch Level: 25
Release Status: release
Description:
There is a formatting typo in the bash man page, in the section
describing the ${parameter/pattern/string} expansion.
Repeat-By:
Look at the bash man page with `man bash`.
Fix:
Here is a patch:
--- bash-3.2/doc/bash.1.orig2008-10-30 15:33:37.0 -0400
+++ bash-3.2/doc/bash.1 2008-10-30 15:33:50.0 -0400
@@ -2539,7 +2539,7 @@
pathname expansion.
\fIParameter\fP is expanded and the longest match of \fIpattern\fP
against its value is replaced with \fIstring\fP.
-If \Ipattern\fP begins with \fB/\fP, all matches of \fIpattern\fP are
+If \fIpattern\fP begins with \fB/\fP, all matches of \fIpattern\fP are
replaced with \fIstring\fP. Normally only the first match is replaced.
If \fIpattern\fP begins with \fB#\fP, it must match at the beginning
of the expanded value of \fIparameter\fP.
smime.p7s
Description: S/MIME Cryptographic Signature
