. (source) builtin behavior changed when commands are in {} braces

In previous version (3.0) bash continue after {} braces. For example: { readonly a a=10 } || : echo hello In bash 3.2 we've got error message about readonly variable, but "hello" is not printed. Is this right behavior or bug? I investigate this problem and found, that there is added top_lev

Re: . (source) builtin behavior changed when commands are in {} braces

Roman Rakus wrote: In previous version (3.0) bash continue after {} braces. For example: { readonly a a=10 } || : echo hello In bash 3.2 we've got error message about readonly variable, but "hello" is not printed. Is this right behavior or bug? I'm not sure what changes you've made to the

CDPATH reports to stdout and even non-interactively

Configuration Information [Automatically generated, do not change]: Machine: i586 OS: linux-gnu Compiler: gcc -I/usr/src/packages/BUILD/bash-3.2 -L/usr/src/packages/BUILD/bash-3.2/../readline-5.2 Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i586' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYP

Perhaps more than CDPATH is risky

Configuration Information [Automatically generated, do not change]: Machine: i586 OS: linux-gnu Compiler: gcc -I/usr/src/packages/BUILD/bash-3.2 -L/usr/src/packages/BUILD/bash-3.2/../readline-5.2 Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i586' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYP

Re: \w in PS1 hopelessly confuses bash in workdir ending in \

Hi *, Am 2008-08-06 17:08:12, schrieb Chet Ramey: > > which seems harmless enough. However, if you do > > > > mkdir /tmp/chaos\\ ; cd /tmp/chaos\\ > > > > the prompt display hopelessly confuses bash. At first it displays > > nothing at all, then with repeated entries of RET fragments of color

Re: CDPATH reports to stdout and even non-interactively

[EMAIL PROTECTED] wrote: Bash Version: 3.2 Patch Level: 25 Release Status: release Description: If CDPATH is set, whenever bash changes directories to a non-absolute path it reports the new directory to stdout. This is done even if bash is running in non-interactive mode

Re: Perhaps more than CDPATH is risky

[EMAIL PROTECTED] wrote: I think somebody needs to audit bash to ask the following questions: (1) If environment variable X is imported to a script, what are the bad effects? (2) What is the probability that a script writer will remember to reset

Re: CDPATH reports to stdout and even non-interactively

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Chet Ramey on 8/15/2008 3:14 PM: > > This is the behavior that Posix requires: when CDPATH is used, bash > outputs the name of the new working directory to stdout. Commands > and shell functions need to take this into account. And in g

Re: CDPATH reports to stdout and even non-interactively

> And in general, it is a bad idea to export CDPATH. Using it in > interactive shells as a non-environment shell variable is fine, but > exporting it affects non-interactive shells. There are good reasons to export CDPATH. In particular, CDPATH is inherited by interactive subshells. For precise

Re: CDPATH reports to stdout and even non-interactively

>> Description: >> If CDPATH is set, whenever bash changes directories to a >> non-absolute path it reports the new directory to stdout. >> This is done even if bash is running in non-interactive mode, >> such as in a script. That breaks scripts that do things like >> this

Re: CDPATH reports to stdout and even non-interactively

Geoff Kuenning wrote: I don't mean that the shell should ignore ALL environment variables; that would break a ton of scripts. Even ignoring PATH would be a Very Bad Thing, since we've long ago grown used to inheriting PATH. Ignoring PATH would make life much, MUCH harder. I just finished writi

Re: CDPATH reports to stdout and even non-interactively

Geoff Kuenning <[EMAIL PROTECTED]> wrote: > BASH_ENVis the cracker's delight. Any setuid program that > invokes a Bash script, even indirectly, is completely > open to attack. Nope. Look at the -p option for set. BASH_ENV can be used to cause scripts to g

Re: CDPATH reports to stdout and even non-interactively

Geoff Kuenning wrote: Actually, the Posix standard is ambiguous. Although it (foolishly) requires reporting to stdout rather than stderr, it does not mention whether this behavior is required for both interactive and non-interactive shells. It's not, really. Unless otherwise specified (and t