21:32:13 +0100
> From: Nicolas Iooss
> To: Dominick Grift
> Cc: seli...@vger.kernel.org
> Subject: Re: Bash 5 change in behavior and SELinux
>
> On Sun, Feb 24, 2019 at 7:37 PM Dominick Grift
> wrote:
>>
>> On Sun, Feb 24, 2019 at 07:17:33PM +0100, Nicolas
On Sun, Feb 24, 2019 at 5:14 PM Dominick Grift
wrote:
>
> Simple test:
This seems to be the same as
https://lists.gnu.org/archive/html/bug-bash/2019-01/msg00276.html
https://lists.gnu.org/archive/html/bug-bash/2019-02/msg0.html
Which has been fixed in the devel branch
e came up with the
> following analysis:
>
> - Forwarded message from Nicolas Iooss -
>
> Date: Sun, 24 Feb 2019 21:32:13 +0100
> From: Nicolas Iooss
> To: Dominick Grift
> Cc: seli...@vger.kernel.org
> Subject: Re: Bash 5 change in behavior and SELinux
>
> On
analysis:
- Forwarded message from Nicolas Iooss -
Date: Sun, 24 Feb 2019 21:32:13 +0100
From: Nicolas Iooss
To: Dominick Grift
Cc: seli...@vger.kernel.org
Subject: Re: Bash 5 change in behavior and SELinux
On Sun, Feb 24, 2019 at 7:37 PM Dominick Grift
wrote:
>
> On Sun, Feb 24, 2019
> >> 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-ba
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
> 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.h
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
&
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
> > $ 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.
--
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'?
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
On 11/7/16 4:49 AM, Dan Douglas wrote:
> On Sun, Nov 6, 2016 at 3:46 PM, Chet Ramey wrote:
>> On 11/1/16 5:57 AM, Dan Douglas wrote:
>>> On a possibly related note, would you consider adjusting +, :+, -, :-,
>>> as in "${var[@]+word}" to align with the meaning of [[ -v var[@] ]] as
>>> discussed i
On Sun, Nov 6, 2016 at 3:46 PM, Chet Ramey wrote:
> On 11/1/16 5:57 AM, Dan Douglas wrote:
>> On a possibly related note, would you consider adjusting +, :+, -, :-,
>> as in "${var[@]+word}" to align with the meaning of [[ -v var[@] ]] as
>> discussed in
>> https://lists.gnu.org/archive/html/bug-
On 11/1/16 5:57 AM, Dan Douglas wrote:
> On Mon, Oct 24, 2016 at 8:25 AM, Chet Ramey wrote:
>> On 10/21/16 5:41 PM, L. A. Walsh wrote:
>>> On 4.3 and earlier, at least on arrays, one could have
>>> the illusion of this working w/o complaint -- and returning
>>> 0 when the array was 0-len or unset,
On Mon, Oct 24, 2016 at 8:25 AM, Chet Ramey wrote:
> On 10/21/16 5:41 PM, L. A. Walsh wrote:
>> On 4.3 and earlier, at least on arrays, one could have
>> the illusion of this working w/o complaint -- and returning
>> 0 when the array was 0-len or unset, or the array length,
>> otherwise:
>>
>>
>>
Chet Ramey wrote:
On 10/29/16 2:04 AM, L. A. Walsh wrote:
You can claim a feature is a certain way because posix requires it
when you are operating in posix-only mode.
Not actually true. I can claim bash implements a particular feature the
way bash implements it.
---
True, but
On 10/29/16 2:04 AM, L. A. Walsh wrote:
>
>
> Chet Ramey wrote:
>> Come on, don't be willfully obtuse. You know better than this. Posix mode
>> doesn't mean "turning it off does everything the way Linda wants."
>>
> No, but claiming posix as a backing for features running that are
> not runnin
Chet Ramey wrote:
Come on, don't be willfully obtuse. You know better than this. Posix mode
doesn't mean "turning it off does everything the way Linda wants."
No, but claiming posix as a backing for features running that are
not running with posix-mode set, is equally obtuse.
Bash is not l
On 10/28/16 3:43 PM, L. A. Walsh wrote:
>
>Please, I'm not running in posix mode, so how would their rules
> apply?
Because you're using `bash', not `walsh'?
Bash is a posix shell. Would the bash documentation convince you? You
could go read that instead.
> Just because posix defines
Chet Ramey wrote:
On 10/24/16 7:32 PM, L. A. Walsh wrote:
I don't understand the ambiguity. If param= "#obj[@]", then it
is clear to me that the user wants the length of an array named "obj".
Stop there. In something like ${#obj[@]}, `param' is `obj[@]'. The
`${#param}' is a c
On 10/24/16 7:32 PM, L. A. Walsh wrote:
>I don't understand the ambiguity. If param= "#obj[@]", then it
> is clear to me that the user wants the length of an array named "obj".
Stop there. In something like ${#obj[@]}, `param' is `obj[@]'. The
`${#param}' is a clearly-defined word expansio
Chet Ramey wrote:
On 10/21/16 5:41 PM, L. A. Walsh wrote:
[previously] one could have the illusion of this working
w/o complaint -- and returning 0 when the array was 0-len
or unset, or the array length, otherwise:
echo ${#array[@]:-0}
But I note it only seemed to work in arrays, and in
On 10/21/16 5:41 PM, L. A. Walsh wrote:
> On 4.3 and earlier, at least on arrays, one could have
> the illusion of this working w/o complaint -- and returning
> 0 when the array was 0-len or unset, or the array length,
> otherwise:
>
>
> echo ${#array[@]:-0}
>
> But I note it only seemed to wor
On Fri, Oct 21, 2016 at 09:19:08PM -0700, L. A. Walsh wrote:
> Eduardo Bustamante wrote:
> >what's wrong with?:
> >echo ${#array[@]}
> Not when "-u" is set, which I often have on to help catch misspellings.
>
> set -u
> echo ${#array[@]}
> bash: array: unbound variable
See http://mywiki.wooledge
what's wrong with?:
echo ${#array[@]}
It will return:
- With array=(1 2 3) -> 3
- With array=() -> 0
- With unset array -> 0
- With declare -a array -> 0
Seems to do what you're looking for.
Eduardo Bustamante wrote:
what's wrong with?:
echo ${#array[@]}
It will return:
- With array=(1 2 3) -> 3
- With array=() -> 0
- With unset array -> 0
- With declare -a array -> 0
Seems to do what you're looking for.
Not when "-u" is set, which I often have on to help catch misspellings
On 4.3 and earlier, at least on arrays, one could have
the illusion of this working w/o complaint -- and returning
0 when the array was 0-len or unset, or the array length,
otherwise:
echo ${#array[@]:-0}
But I note it only seemed to work in arrays, and in 4.4 gets a
syntax error:
echo ${#ar
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"), th
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 sou
-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 sam
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.
i can't tell from the thread whether this was intentional:
https://lists.gnu.org/archive/html/help-bash/2014-04/msg4.html
-mike
signa
32 matches
Mail list logo
