Configuration Information [Automatically generated, do not change]:
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'
Chet Ramey wrote:
[EMAIL PROTECTED] wrote:
hello,
i made some observation by chance.
bash 3.2 seems to leak environment variables into open() syscalls (older bash
2.0 does not show this behaviour)
Bash isn't doing the opens -- they're coming from the libc locale code.
Bash
AT-HE [EMAIL PROTECTED] wrote:
if you have a simlink pointing to a directory, chdir to that symlink
dir, and type something with '..',
you access the parent of real directory, not previous simlinked one.
That's the kernel's doing, not bash's. When interpreting pathnames
AT-HE wrote:
if you have a simlink pointing to a directory, chdir to that
symlink dir, and type something with '..', you access the
parent of real directory, not previous simlinked one.
Symlinks violate some principles of least surprise. Therefore it is
not surprise
[EMAIL PROTECTED] wrote:
Anyway, I wish there was a way to communicate a disown command or
something to that shell. stty -a shows a lot of weird keys. Anyway, it
would be neat if there was a key e.g., C-y, that would have the
effect of C-z bg, but without ever letting the job in question feel
Gentlemen, I have discovered a documentation oversight. In the manual,
we see:
-u Treat unset variables as an error when performing param-
eter expansion. If expansion is attempted on an unset
variable, the shell prints an error
[EMAIL PROTECTED] wrote:
Gentlemen, I have discovered a documentation oversight. In the manual,
we see:
You've discovered a bug. They should be treated the same way.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]
Hi
I stumbled over that variables defined outside of blocks of code do
not get altered by assignment statements to that variable within the
block when the output of the block is piped to some other process.
Re-direction of the block output to a file or no re-direction changes
the outer
Thiemo Kellner [EMAIL PROTECTED] wrote:
Maybe the piping converts the block implicitly to a subshell.
Yes, it does. This is documented in the man page, under Pipelines
in the SHELL GRAMMAR section, and in the FAQ, entry E4.
paul
