On 2/28/19 2:32 PM, Robert Elz wrote:
> chet.ra...@case.edu also said:
> | Because ksh uses the open, open, close, close interpretation.
>
> Actually just the opposite,
Correct, my bad.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis''
Date:Mon, 25 Feb 2019 17:38:07 -0500
From:Grisha Levit
Message-ID:
First, apologies from me for missing this message from you. I don't
know if my spam filters caught it (for some unknown reason) or whether
it was delivered and I simply discarded it without notici
On 2/25/19 5:38 PM, Grisha Levit wrote:
> On Sun, Feb 24, 2019 at 11:22 PM Robert Elz wrote:
>> I think these are actually more the insertion of explicit null
>> strings, rather than $@ when it contains null strings. These
>> are essentially the same as the ${b+s ''} issue that was discussed
>>
On 2/24/19 6:37 PM, Grisha Levit wrote:
> There are some what seem to be regressions (?) in bash-4.4 and
> bash-5.0 regarding the handling of "$@" expansion when it consists
> entirely of null strings.
Thanks for the report and additional tests.
Chet
--
``The lyf so short, the craft so long to l
On Sun, Feb 24, 2019 at 11:22 PM Robert Elz wrote:
> I think these are actually more the insertion of explicit null
> strings, rather than $@ when it contains null strings. These
> are essentially the same as the ${b+s ''} issue that was discussed
> a week or so ago, and which Chet already said
Date:Sun, 24 Feb 2019 18:37:33 -0500
From:Grisha Levit
Message-ID:
| There are some what seem to be regressions (?) in bash-4.4 and
| bash-5.0 regarding the handling of "$@" expansion when it consists
| entirely of null strings.
I think these are actually mor
There are some what seem to be regressions (?) in bash-4.4 and
bash-5.0 regarding the handling of "$@" expansion when it consists
entirely of null strings.
The relevant commits are bash-20160722 [1], bash-20170331 [2],
bash-20190220 [3].
Using:
$ n() { echo $#; }
Since bash-20160722:
$ s
