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
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
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'
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'
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
ANSI
[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
[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
-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
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 precisely
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:
This is
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
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 go
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
13 matches
Mail list logo
