Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: freebsd8.1
Compiler: cc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
-DCONF_OSTYPE='freebsd8.1' -DCONF_MACHTYPE='i386-portbld-freebsd8.1'
-DCONF_VENDOR='portbld' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -I/usr/local/include
-O -pipe -march=prescott
uname output: FreeBSD infra-build.traditionsa.lu 8.1-20101216-SNAP FreeBSD
8.1-20101216-SNAP #0: Thu Dec 16 09:27:37 UTC 2010
r...@public-build.traditionsa.lu:/usr/obj/usr/src/sys/GENERIC i386
Machine Type: i386-portbld-freebsd8.1
Bash Version: 4.1
Patch Level: 10
Release Status: release
Description:
bash's actual behavior differs from what the manual says regarding
the allocation of new file descriptors by redirection:
Each redirection that may be preceded by a file descriptor
number may instead be preceded by a word of the form
{varname}. In this case, for each redirection operator
except >&- and <&-, the shell will allocate a file
descriptor greater than 10 and assign it to {varname}.
If >&- or <&- is preceded by {varname}, the value of
varname defines the file descriptor to close.
On this system, the first fd created by this procedure is
number 10, which is not greater than 10.
This is probably more of a documentation bug than a bash bug.
Repeat-By:
exec {NEW}>&1
echo $NEW
Fix:
If it's a documentation bug, "greater than 9".
If it's a bash bug,
--- bash-4.1/redir.c.orig 2011-07-20 11:48:56.000000000 +0200
+++ bash-4.1/redir.c 2011-07-20 11:49:05.000000000 +0200
@@ -57,7 +57,7 @@
# include "input.h"
#endif
-#define SHELL_FD_BASE 10
+#define SHELL_FD_BASE 11
int expanding_redir;
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
postmas...@tradition.ch
