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
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
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
>> 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
> 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
-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
[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
[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
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
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
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
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
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
13 matches
Mail list logo
