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
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 v
On Wed, Nov 26, 2008 at 01:25:17PM -0500, Chet Ramey wrote:
> [EMAIL PROTECTED] wrote:
> > Gentlemen, I have discovered a documentation oversight. In the manual,
> > we see:
> > set -u --
> > : $@ $*
> > : $1
> >
> > and
> >
> > set --
> > : ${*?} [EMAIL PROTECTED]
> > : ${1?}
> >
> > Therefore
[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]http://c
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 me
[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 questio
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
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
r
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 isn
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' -DPACKAGE='b
10 matches
Mail list logo
