Re: Change in behavior

2016-12-13 Thread Vladimir Marek 
> >> Posix says a word expansion error shall cause a non-interactive shell to
> >> exit:
> >>
> >> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_08_01
> >>
> >> Bash posix mode changed as the result of this report:
> >>
> >> http://lists.gnu.org/archive/html/bug-bash/2015-08/msg00013.html
> > 
> > That is what I wanted to hear, many thanks!
> 
> If you want the previous behavior, set the shell's compatibility level
> to `43'.

Nice. Thank you
-- 
Vlad

Re: Change in behavior

2016-12-13 Thread Chet Ramey 
On 12/13/16 10:37 AM, Vladimir Marek wrote:
>> Posix says a word expansion error shall cause a non-interactive shell to
>> exit:
>>
>> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_08_01
>>
>> Bash posix mode changed as the result of this report:
>>
>> http://lists.gnu.org/archive/html/bug-bash/2015-08/msg00013.html
> 
> That is what I wanted to hear, many thanks!

If you want the previous behavior, set the shell's compatibility level
to `43'.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Change in behavior

2016-12-13 Thread Vladimir Marek 
> Posix says a word expansion error shall cause a non-interactive shell to
> exit:
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_08_01
> 
> Bash posix mode changed as the result of this report:
> 
> http://lists.gnu.org/archive/html/bug-bash/2015-08/msg00013.html

That is what I wanted to hear, many thanks!
-- 
Vlad

Re: Change in behavior

2016-12-13 Thread Chet Ramey 
On 12/13/16 10:08 AM, Vladimir Marek wrote:
> Hi,
> 
> by coincidence I found change in behavior in how bash treats syntax
> error. Can you see the difference on your machines too?
> 
> $ cat configure
> set -o posix
> echo ${0.8}
> echo after
> 
> $ bash a.sh
> 3.2.52(1)-release
> a.sh: line 3: ${0.8}: bad substitution
> after
> 
> $ bash a.sh
> 4.3.46(1)-release
> build/i86/configure: line 3: ${0.8}: bad substitution
> after
> 
> $ bash a.sh
> 4.4.5(1)-release
> build/i86/configure: line 3: ${0.8}: bad substitution
> 
> 
> I also tried on Gentoo and bash 4.4.5 didn't run the last line similarly
> to my tests. Is it intended change?

Posix says a word expansion error shall cause a non-interactive shell to
exit:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_08_01

Bash posix mode changed as the result of this report:

http://lists.gnu.org/archive/html/bug-bash/2015-08/msg00013.html

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Change in behavior

2016-12-13 Thread Greg Wooledge 
On Tue, Dec 13, 2016 at 09:16:12AM -0600, Eduardo Bustamante wrote:
> On Tue, Dec 13, 2016 at 9:08 AM, Vladimir Marek
>  wrote:
> [...]
> > $ cat configure
> > set -o posix
> > echo ${0.8}
> > echo after
> >
> > $ bash a.sh
> > 3.2.52(1)-release
> > a.sh: line 3: ${0.8}: bad substitution
> > after
> Is `a.sh' a copy of `configure'?

I figured he simply lied about all of his "pasted terminal output".
Notice how the pathname spat out as $0 keeps changing too.

Nonetheless, the result can be reproduced, but only in posix mode.

imadev:~$ bash-4.3 -posix -c $': ${0.8}\necho after'
bash-4.3: ${0.8}: bad substitution
after
imadev:~$ bash-4.4 -posix -c $': ${0.8}\necho after'
bash-4.4: ${0.8}: bad substitution
imadev:~$

Re: Change in behavior

2016-12-13 Thread Vladimir Marek 
> > $ cat configure
> > set -o posix
> > echo ${0.8}
> > echo after
> >
> > $ bash a.sh
> > 3.2.52(1)-release
> > a.sh: line 3: ${0.8}: bad substitution
> > after
> Is `a.sh' a copy of `configure'?

Oh, yes, sorry, it's the same file. It's a part of libvisual-plugins's
configure script.

-- 
Vlad

Re: Change in behavior

2016-12-13 Thread Eduardo Bustamante 
On Tue, Dec 13, 2016 at 9:08 AM, Vladimir Marek
 wrote:
[...]
> $ cat configure
> set -o posix
> echo ${0.8}
> echo after
>
> $ bash a.sh
> 3.2.52(1)-release
> a.sh: line 3: ${0.8}: bad substitution
> after
Is `a.sh' a copy of `configure'?

Re: change in behavior starting with bash-4.3_p14 and $@ in [[...]]

2014-08-13 Thread Chet Ramey 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/12/14, 11:05 PM, Mike Frysinger wrote:
 simple enough code:
 foo=(0 0 0); [[ -z ${foo[@]#0} ]]; echo $?
 
 with bash-4.3_p13 and older, this would show 0.  starting with bash-4.3_p14, 
 this now shows 1.

It's intentional, and part of the same bug fix.  Word splitting is
suppressed inside [[, so the array expands to a single word (0 0 0), the
0s are removed, leaving   , and that is the result the current version
uses.  The code before patch 14 ran the string through word splitting,
which removed the spaces.  FWIW, ksh93 returns the same result as the
patched bash, though I can't tell whether it's doing the exact same thing
internally.

Chet
- -- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlPrbIcACgkQu1hp8GTqdKtKBwCeJrFBvXyzXEzL/HABKzS1ZS/x
32sAn3PEPcEPfUuTRXCHPT+KLWimMJsf
=T5NC
-END PGP SIGNATURE-

Re: change in behavior starting with bash-4.3_p14 and $@ in [[...]]

2014-08-13 Thread Greg Wooledge 
On Wed, Aug 13, 2014 at 09:47:51AM -0400, Chet Ramey wrote:
 On 8/12/14, 11:05 PM, Mike Frysinger wrote:
  foo=(0 0 0); [[ -z ${foo[@]#0} ]]; echo $?

 Word splitting is
 suppressed inside [[, so the array expands to a single word (0 0 0), the
 0s are removed, leaving   

That doesn't sound right.  Either you get a single word and remove the
leading 0 only, or you remove the 0s from each array element first,
and then get a single word by concatenating what's left.

The code that Mike posted is pretty wonky in the first place.  I don't
understand what its intent is.  (It's expanding an array into a list of
words in a context where you can't have a list... and then checking the
string length of that list-not-list as if it were a string... what?)

The right-hand side of an assignment also suppresses word splitting, so
I tried this:

imadev:~$ foo=(0 0 0); x=${foo[@]#0}
imadev:~$ echo $x

imadev:~$ foo=(0 0 0); x=${foo[@]#0}
imadev:~$ echo $x
  
imadev:~$ echo $BASH_VERSION
4.3.22(5)-release

Looks like the second one expanded to a list of empty words and then
concatenated them together with spaces.  I have no idea what the first
one did, or why it's different.

Re: change in behavior starting with bash-4.3_p14 and $@ in [[...]]

2014-08-13 Thread Chet Ramey 
On 8/13/14, 10:09 AM, Greg Wooledge wrote:
 On Wed, Aug 13, 2014 at 09:47:51AM -0400, Chet Ramey wrote:
 On 8/12/14, 11:05 PM, Mike Frysinger wrote:
 foo=(0 0 0); [[ -z ${foo[@]#0} ]]; echo $?
 
 Word splitting is
 suppressed inside [[, so the array expands to a single word (0 0 0), the
 0s are removed, leaving   
 
 That doesn't sound right.  Either you get a single word and remove the
 leading 0 only, or you remove the 0s from each array element first,
 and then get a single word by concatenating what's left.

Not quite.  The expansion happens before word splitting, and the @ causes
the result to be treated specially.  This is the basic set of steps:

1.  The foo[@] is expanded into a list (0 0 0), noting that the @ was
present so the result can be handled accordingly.

2.  The #0 is applied to each member of the list, as it would be in any
other context.  If you were to echo the results here, kind of like
you did below, you would get three empty words.

3.  The results are `glued' together as if $* were used, due to the
presence of `@', so the three empty words are separated by two spaces.

4.  The two spaces remain because word splitting is not performed; the
empty words disappear.

 The code that Mike posted is pretty wonky in the first place.  I don't
 understand what its intent is.  (It's expanding an array into a list of
 words in a context where you can't have a list... and then checking the
 string length of that list-not-list as if it were a string... what?)

Yeah, I assume it's a quick way to test whether all elements of an array
are identical.

 
 The right-hand side of an assignment also suppresses word splitting, so
 I tried this:
 
 imadev:~$ foo=(0 0 0); x=${foo[@]#0}
 imadev:~$ echo $x
 
 imadev:~$ foo=(0 0 0); x=${foo[@]#0}
 imadev:~$ echo $x
   
 imadev:~$ echo $BASH_VERSION
 4.3.22(5)-release
 
 Looks like the second one expanded to a list of empty words and then
 concatenated them together with spaces.  I have no idea what the first
 one did, or why it's different.

It looks like a bug.  I assume it's because bash treats $@ and $@
(and their array equivalents) differently, even in contexts where word
splitting is not going to happen.  I will have to look at it.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/