Re: Empty ""s in ARG in ${x:+ARG} expand to no words instead of the empty word if prepended/appended with space
On 21.7. 07:44, Bob Proulx wrote:
Denys Vlasenko wrote:
$ f() { for i; do echo "|$i|"; done; }
$ x=x
$ e=
$ f ${x:+ ""}
^^^ prints nothing, bug?
$ ${x:+"" }
^^^ prints nothing, bug?
Insufficient quoting. That argument should be quoted to avoid the
whitespace getting stripped. (Is that during word splitting phase
using the IFS? I think so.)
Try this:
f "${x:+ ""}"
f "${x:+"" }"
That's not the same at all. With outer quotes, the result will always be
a single word. Without them, having an empty 'x' would result in no word:
Without outer quotes:
$ for cond in "" "1" ; do for value in "" "*" ; do printf "<%s>\t"
"$cond" "$value" ${cond:+"$value"}; echo; done; done
<> <>
<> <*>
<1> <> <>
<1> <*> <*>
With outer quotes:
$ for cond in "" "1" ; do for value in "" "*" ; do printf "<%s>\t"
"$cond" "$value" "${cond:+"$value"}"; echo; done; done
<> <> <>
<> <*> <>
<1> <> <>
<1> <*> <*>
I suppose that could be used to pass optional arguments to some command.
Though different shells do behave a bit differently here, and I'm not
sure which behaviour is the correct one. With the values from the third
line in the above test (the other three seem consistent), different shells:
No extra spaces in ${cond:+"$value"}:
$ for shell in bash dash ksh "zsh -y" ; do $shell -c 'cond=1; value="";
printf "<%s> " "$0" ${cond:+"$value"}; echo;' ; done
<>
<>
<>
Extra spaces in ${cond:+ "$value" }:
$ for shell in bash dash ksh "zsh -y" ; do $shell -c 'cond=1; value="";
printf "<%s> " "$0" ${cond:+ "$value" }; echo;' ; done
<>
<>
<>
Or with multiple words inside:
$ for shell in bash dash ksh "zsh -y" ; do $shell -c 'cond=1; printf
"<%s> " "$0" ${cond:+"" "x" ""}; echo;' ; done
<> <>
<>
<> <>
It doesn't seem like a very good idea to rely on this, arrays would of
course work better.
Bash: GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)
ksh:version sh (AT&T Research) 93u+ 2012-08-01
zsh: zsh 5.3.1 (x86_64-debian-linux-gnu)
dash: Debian's 0.5.8-2.4
--
Ilkka Virta / itvi...@iki.fi
Re: Empty ""s in ARG in ${x:+ARG} expand to no words instead of the empty word if prepended/appended with space
On 7/20/18 10:43 AM, Denys Vlasenko wrote:
> $ f() { for i; do echo "|$i|"; done; }
> $ x=x
> $ e=
Thanks for the report. I'll take a look at what needs to be done here.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Empty ""s in ARG in ${x:+ARG} expand to no words instead of the empty word if prepended/appended with space
On 7/21/18 12:44 AM, Bob Proulx wrote:
> Denys Vlasenko wrote:
>> $ f() { for i; do echo "|$i|"; done; }
>> $ x=x
>> $ e=
>> $ f ${x:+ ""}
>> ^^^ prints nothing, bug?
>>
>> $ ${x:+"" }
>> ^^^ prints nothing, bug?
>
> Insufficient quoting. That argument should be quoted to avoid the
> whitespace getting stripped. (Is that during word splitting phase
> using the IFS? I think so.)
Even if the whitespace gets stripped out, the quoted null string should
result in an empty argument. Different shells are inconsistent about this,
but I believe that if word splitting occurs, the empty string (or "$e",
anything that expands to an empty string) should result in a null word.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Empty ""s in ARG in ${x:+ARG} expand to no words instead of the empty word if prepended/appended with space
Chet Ramey wrote:
> Bob Proulx wrote:
> > Denys Vlasenko wrote:
> >> $ f() { for i; do echo "|$i|"; done; }
> >> $ x=x
> >> $ e=
> >> $ f ${x:+ ""}
> >> ^^^ prints nothing, bug?
> >>
> >> $ ${x:+"" }
> >> ^^^ prints nothing, bug?
> >
> > Insufficient quoting. That argument should be quoted to avoid the
> > whitespace getting stripped. (Is that during word splitting phase
> > using the IFS? I think so.)
>
> Even if the whitespace gets stripped out, the quoted null string should
> result in an empty argument. Different shells are inconsistent about this,
> but I believe that if word splitting occurs, the empty string (or "$e",
> anything that expands to an empty string) should result in a null word.
Gotcha. Thanks!
And further testing confirms the inconsistent shells. bash and ksh
both seem to be the outliers in different ways in terms of behavior.
dash and zsh seem to be consistent and correct in this.
Bob
Re: Empty ""s in ARG in ${x:+ARG} expand to no words instead of the empty word if prepended/appended with space
Date:Sat, 21 Jul 2018 11:33:18 -0400 From:Chet Ramey Message-ID: <2fe93203-93fd-2a97-ff54-7cb748294...@case.edu> | Even if the whitespace gets stripped out, the quoted null string should | result in an empty argument. Yes, it certainly should (and unless IFS has been set "oddly" the white space will be removed, but that's irrelevant). For what it is worth, as recently as 4.2.0 (and maybe more recently) bash got this right, so it is something that has changed in 4.3 or 4.4 (or maybe later in 4.2). kre
v4.4 segfault in 'decode_prompt_string' when processing special parameter
This only works in 4.4; earlier versions throw a 'bad substitution' error. It
causes an infinite loop of calls between 'expand_prompt_string' and
'decode_prompt_string',
where calls to 'xmalloc' exhaust the heap:
$\{_@P};${_@P}
I decided to report this because it is not a user-defined recursive
function and it exhausts the heap rather than the stack.
Here is a call trace that just repeats itself as you go back further (you
can see #7 and #0 are the same):
#0 decode_prompt_string (string=0x8dca08 "${_@P}") at
/usr/homes/chet/src/bash/src/parse.y:5471
#1 0x004cf5e0 in string_transform (xc=, v=0x84ca88,
s=0x8dca08 "${_@P}") at subst.c:5127
#2 0x004cc7c5 in parameter_brace_transform (varname=, value=, ind=, xform=,
rtype=0,
quoted=, flags=) at subst.c:5263
#3 0x004c5a3d in parameter_brace_expand (string=,
quoted=, pflags=,
contains_dollar_at=,
indexp=, quoted_dollar_atp=) at
subst.c:8364
#4 param_expand (string=, sindex=,
quoted=, expanded_something=,
contains_dollar_at=, quoted_dollar_at_p=,
had_quoted_null_p=, pflags=) at subst.c:8740
#5 0x004b2640 in expand_word_internal (word=,
quoted=, isexp=,
contains_dollar_at=,
expanded_something=) at subst.c:9301
#6 0x004b16ca in expand_prompt_string (string=0x8dc908 "${_@P}",
quoted=1, wflags=) at subst.c:3732
#7 0x00434fe0 in decode_prompt_string (string=) at
/usr/homes/chet/src/bash/src/parse.y:5833
Re: v4.4 segfault in 'decode_prompt_string' when processing special parameter
The payload got filtered, so here it is again (substitute the actual
character for [at]):
$\{_[at]P};${_[at]P}
On Sat, Jul 21, 2018, 1:47 PM Chris Schoenberg wrote:
> This only works in 4.4; earlier versions throw a 'bad substitution' error. It
> causes an infinite loop of calls between 'expand_prompt_string' and
> 'decode_prompt_string',
> where calls to 'xmalloc' exhaust the heap:
>
...
>
Re: v4.4 segfault in 'decode_prompt_string' when processing special parameter
On 7/21/18 2:47 PM, Chris Schoenberg wrote:
> This only works in 4.4; earlier versions throw a 'bad substitution' error. It
> causes an infinite loop of calls between 'expand_prompt_string' and
> 'decode_prompt_string',
> where calls to 'xmalloc' exhaust the heap:
>
> $\{_@P};${_@P}
>
> I decided to report this because it is not a user-defined recursive
> function and it exhausts the heap rather than the stack.
It's user-defined recursive parameter expansion. A string that undergoes
prompt expansion performs parameter expansion, as documented. If that
parameter expansion passes the same string to prompt expansion, which
performs parameter expansion, you've got user-defined recursion.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: v4.4 segfault in 'decode_prompt_string' when processing special parameter
Fair enough. Even though the behavior is different, the end is the same as
udf so makes sense of you want to leave it. Weird how it popped up in 4.4
though.
On Sat, Jul 21, 2018, 6:58 PM Chet Ramey wrote:
> On 7/21/18 2:47 PM, Chris Schoenberg wrote:
> > This only works in 4.4; earlier versions throw a 'bad substitution'
> error. It
> > causes an infinite loop of calls between 'expand_prompt_string' and
> > 'decode_prompt_string',
> > where calls to 'xmalloc' exhaust the heap:
> >
> > $\{_@P};${_@P}
> >
> > I decided to report this because it is not a user-defined recursive
> > function and it exhausts the heap rather than the stack.
>
> It's user-defined recursive parameter expansion. A string that undergoes
> prompt expansion performs parameter expansion, as documented. If that
> parameter expansion passes the same string to prompt expansion, which
> performs parameter expansion, you've got user-defined recursion.
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
>
Re: v4.4 segfault in 'decode_prompt_string' when processing special parameter
On 7/21/18 9:16 PM, Chris Schoenberg wrote:
> Fair enough. Even though the behavior is different, the end is the same as
> udf so makes sense of you want to leave it. Weird how it popped up in 4.4
> though.
The ${param@op} expansions were introduced in bash-4.4.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: v4.4 segfault in 'decode_prompt_string' when processing special parameter
Thanks for taking the time to explain that :) I'll do more homework next
time
On Sat, Jul 21, 2018, 8:51 PM Chet Ramey wrote:
> On 7/21/18 9:16 PM, Chris Schoenberg wrote:
> > Fair enough. Even though the behavior is different, the end is the same
> as
> > udf so makes sense of you want to leave it. Weird how it popped up in 4.4
> > though.
>
> The ${param@op} expansions were introduced in bash-4.4.
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
>
