On Tue, Dec 9, 2014 at 7:29 AM, Linda Walsh wrote:
> Instead of dumbing down bash, why not lobby for bash to record
> which variables contain tainted input -- and throw an error they are eval'ed
> (based on an option setting, of course)?
For compatibility's sake I think it's a good idea
On Tue, Dec 9, 2014 at 9:40 PM, Stephane Chazelas
wrote:
> 2014-12-09 20:55:02 +0800, konsolebox:
> [...]
>> As for the other things, I was actually only concerned about the
>> dangerous behavior that's synonymous to "eval $b" so I didn't really
>> thought about discussing them. And I'm only refe
On 12/9/14, 9:47 AM, Stephane Chazelas wrote:
> 2014-12-09 07:14:16 -0700, Eric Blake:
> [...]
>> No, you get the correct behavior. Newer bash fixed the parser bug to
>> comply with POSIX.
>>
>> For comparison, try:
>>
>> $ echo . ${VAR:=""} .
>> . .
>> $ echo . "${VAR:=""}" .
>> . .
> [...]
>
>
On Dec 9, 2014, at 9:47 AM, Stephane Chazelas
wrote:
> It's a bit confusing that ${VAR:-""} should be treated
> differently from ${VAR:=""}. Was there a rationale for changing
> the behaviour other than strict POSIX conformance? AFAICT, ksh
> and mksh behave differently (from bash and from each
2014-12-09 07:14:16 -0700, Eric Blake:
[...]
> No, you get the correct behavior. Newer bash fixed the parser bug to
> comply with POSIX.
>
> For comparison, try:
>
> $ echo . ${VAR:=""} .
> . .
> $ echo . "${VAR:=""}" .
> . .
[...]
It's a bit confusing that ${VAR:-""} should be treated
differe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/9/14, 9:14 AM, Eric Blake wrote:
> No, with bash 3.2, you are tripping up on a parser bug. Bash 3.2
> incorrectly handled double quotes inside unquoted parameter
> expansion.
This is mostly true, but it has nothing to do with the parser. This
On 12/9/14, 8:24 AM, Olivier TROCHERIE wrote:
> I would like to report to you a problem I encounter with bash 4.3.30.
>
> In the following example, VAR is undefined.
>
>
>
> With bash 3.2, when I run the following commands:
>
>
>
> if [ -d ${VAR:=""} ]
>
> then
>
> echo yes
>
> else
On 12/09/2014 06:24 AM, Olivier TROCHERIE wrote:
> With bash 3.2, when I run the following commands:
>
> if [ -d ${VAR:=""} ]
Insufficient quoting. You are executing:
[ -d ]
which is a test whether the single argument "-d" is not empty (which is
true), ergo the exit 0 status.
You MEANT to use
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu'
-DCONF_VENDOR='unknown'
-DLOCALEDIR='/homedir/otroch
While compiling Bash, I couldn't help but notice that all over GNU's website it
is spelled with a capital B. However, when I tried to compile Bash, I noticed a
message that said "GNU bash, version 4.3.30(1)-release (i686-pc-linux-gnu)" in
a box surrounded by stars. Why is the B not capitalized h
2014-12-09 20:55:02 +0800, konsolebox:
[...]
> As for the other things, I was actually only concerned about the
> dangerous behavior that's synonymous to "eval $b" so I didn't really
> thought about discussing them. And I'm only referring to Bash when I
> made the suggestions. Other shells certai
On Tue, Dec 09, 2014 at 08:55:02PM +0800, konsolebox wrote:
> > declare -g "$var=$something"
>
> It actually should be completely avoided. eval is the right tool for
> that job (besides a variable declared with -n in 4.3+).
Unfortunately, "declare -n" is the same as eval. We've had this
discuss
On Tue, Dec 9, 2014 at 6:59 PM, Stephane Chazelas
wrote:
> BTW, it's worth noting (and maybe documenting) that word
> splitting and filename generation are performed in:
>
> declare -g $var=$something
> (or declare ''var=$something or declare f\oo=$bar...)
>
> So it must be indeed:
>
> declare -g
2014-12-09 10:59:14 +, Stephane Chazelas:
[...]
> $ a=0 ksh -c 'function f { typeset a=1; g; h; echo "f: $a"; }; function g {
> a=2; }; function h { typeset a=3; };f'
> f: 1
>
> "f" doesn't have to worry about alien functions changing its
> local variables under its feet.
[...]
(for clarific
Thanks konsolebox and Eduardo, glad to see I'm not the only one
seeing an issue in that.
A few additions inline:
2014-12-09 10:51:51 +0800, konsolebox:
[...]
> (But I think those who used to recommend using declare as a general tool
> for assigning values remotely over evil eval would love it sin
15 matches
Mail list logo
