> On Thu, 20 Feb 2020, Chet Ramey wrote:
> On 2/20/20 10:05 AM, Ulrich Mueller wrote:
>>> On Thu, 20 Feb 2020, pepa65 wrote:
>>
>>> On 20/02/2020 19.48, Ulrich Mueller wrote:
Still, I think it's sad that there isn't a command that can test for
assigned vs void variable, without
2020-02-20 21:36 GMT+01:00, Chet Ramey :
> On 2/19/20 4:03 PM, Arfrever Frehtes Taifersar Arahesis wrote:
>> ${!variable@operator} does not work for variables without values.
>> See empty values for all occurrences of ${!var@...} below.
>>
>> ${variable@A} does not work for scalar variables
On 20/02/2020 15:55, Robert Elz wrote:
Date:Thu, 20 Feb 2020 09:16:05 +
From:Harald van Dijk
Message-ID:
| In that case, I think we can interpret the "when" in the description
| of the trap command literally except when 2.11 overrides it.
I think it
Chet Ramey 2020-02-20 21:22 UTC:
> On 2/19/20 7:46 PM, Arfrever Frehtes Taifersar Arahesis wrote:
>> But I am not interested in any ${!varname[@]}, but instead in applying
>> @operator transformations.
>
> OK, let's see how these work.
>
> Given the following
>
> VAR2=(aaa bbb)
> varname=VAR2
>
>
Chet Ramey 2020-02-20 20:41 UTC:
> On 2/19/20 5:22 PM, Arfrever Frehtes Taifersar Arahesis wrote:
>>> ${variable@A} does not work for scalar variables without values, but
>>> interestingly ${variable[@]@A} works for them.
>>
>> More precisely, ${variable[@]@A} is non-empty, but not exactly
On 2/19/20 7:46 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> But I am not interested in any ${!varname[@]}, but instead in applying
> @operator transformations.
OK, let's see how these work.
Given the following
VAR2=(aaa bbb)
varname=VAR2
What does
echo ${!varname[@]@Q}
output?
You
On 2/19/20 5:22 PM, Arfrever Frehtes Taifersar Arahesis wrote:
>> ${variable@A} does not work for scalar variables without values, but
>> interestingly ${variable[@]@A} works for them.
>
> More precisely, ${variable[@]@A} is non-empty, but not exactly correct.
>
>> See difference between
On 2/19/20 4:03 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> ${!variable@operator} does not work for variables without values.
> See empty values for all occurrences of ${!var@...} below.
>
> ${variable@A} does not work for scalar variables without values, but
> interestingly ${variable[@]@A}
On 2/19/20 7:46 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> Eli Schwartz 2020-02-20 23:49 UTC:
>> Your examples are all (still) broken.
>
> This would affect only 10 examples from 120, so only 8.33 % of
> examples, far from all examples.
[...]
> Majority (3 of 4) of bugs reported by me in
> On 2/19/20 4:03 PM, Arfrever Frehtes Taifersar Arahesis wrote:
>
> > However neither ${variable@A} nor ${variable[@]@A} works for arrays
> > without values.
>
> So you mean for unset variables, correct? Since the array variables
> haven't been assigned a value, they are unset, like VAR3 in
On 2/19/20 4:03 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> However neither ${variable@A} nor ${variable[@]@A} works for arrays
> without values.
So you mean for unset variables, correct? Since the array variables
haven't been assigned a value, they are unset, like VAR3 in your
script.
--
On 2/20/20 10:05 AM, Ulrich Mueller wrote:
>> On Thu, 20 Feb 2020, pepa65 wrote:
>
>> On 20/02/2020 19.48, Ulrich Mueller wrote:
>>> Still, I think it's sad that there isn't a command that can test for
>>> assigned vs void variable, without the need for parsing of declare -p
>>> output.
>
>>
On 2/19/20 4:03 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> ${variable@A} does not work for scalar variables without values, but
> interestingly ${variable[@]@A} works for them.
What does this mean? If you have, for instance,
declare -lr VAR1
echo ${VAR1@A}
echo ${VAR1[@]@A}
you get two
On 2/19/20 4:03 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> ${!variable@operator} does not work for variables without values.
> See empty values for all occurrences of ${!var@...} below.
I think you already realized that your test for this case was flawed.
For instance, given
var=VAR2
Date:Thu, 20 Feb 2020 09:16:05 +
From:Harald van Dijk
Message-ID:
| In that case, I think we can interpret the "when" in the description
| of the trap command literally except when 2.11 overrides it.
I think it should be interpreted just like its normal
On 2/19/20 4:59 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> Notice unnecessary space before closing parenthesis for non-empty
> associative arrays (VAR5, VAR6) below:
This is a purely cosmetic issue that makes no semantic difference.
--
``The lyf so short, the craft so long to lerne.'' -
On 2/19/20 2:36 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> When scalar variable is read-only, then calling 'local' for this
> variable (regardless of presence of value in assignment) is non-fatal
> and subsequent commands in function are executed.
Correct. This is an implementation choice,
On 2/20/20 3:02 AM, Denys Vlasenko wrote:
> On 2/19/20 9:30 PM, Chet Ramey wrote:
>> On 2/19/20 5:29 AM, Denys Vlasenko wrote:
>>> A bug report from Harald van Dijk:
>>>
>>> test2.sh:
>>> trap 'kill $!; exit' TERM
>>> { kill $$; exec sleep 9; } &
>>> wait $!
>>>
>>> The above script ought exit
On Thu, Feb 20, 2020 at 04:05:01PM +0100, Ulrich Mueller wrote:
> > On Thu, 20 Feb 2020, pepa65 wrote:
>
> > On 20/02/2020 19.48, Ulrich Mueller wrote:
> >> Still, I think it's sad that there isn't a command that can test for
> >> assigned vs void variable, without the need for parsing of
> On Thu, 20 Feb 2020, pepa65 wrote:
> On 20/02/2020 19.48, Ulrich Mueller wrote:
>> Still, I think it's sad that there isn't a command that can test for
>> assigned vs void variable, without the need for parsing of declare -p
>> output.
> There is no need to parse, the return value of
I've just figured that the [ -e "$1" ] in the handler might cause some
problems.
Sometimes, the named pipes isn't yet removed thus [ -e "$1" ] will be true and
the return part won't be called.
I'm not sure why it isn't removed directly, but it might just be how the AIX
kernel is handling
On 20/02/2020 19.48, Ulrich Mueller wrote:
> Still, I think it's sad that there isn't a command that can test for
> assigned vs void variable, without the need for parsing of declare -p
> output.
There is no need to parse, the return value of `declare -p var` or
`typeset -p var` will tell you
On Thu, Feb 20, 2020 at 01:46:25AM +0100, Arfrever Frehtes Taifersar Arahesis
wrote:
> Is there any way for using ${!variable} combined with
> ${variable@operator}
No.
> On Wed, 19 Feb 2020, Stephane Chazelas wrote:
> 2020-02-19 17:18:14 +0100, Ulrich Mueller:
> [...]
>> So, is there any syntax that allows to test if a value has been assigned
>> to the array variable? Especially, to distinguish VARNAME=() (empty
>> array) from VARNAME being unset?
> [...]
On 20/02/2020 01:55, Robert Elz wrote:
Date:Wed, 19 Feb 2020 23:53:56 +
From:Harald van Dijk
Message-ID: <9b9d435b-3d2f-99bd-eb3d-4a676ce89...@gigawatt.nl>
| POSIX says in the description of the trap command "Otherwise, the
| argument action shall be
On 2/19/20 9:30 PM, Chet Ramey wrote:
On 2/19/20 5:29 AM, Denys Vlasenko wrote:
A bug report from Harald van Dijk:
test2.sh:
trap 'kill $!; exit' TERM
{ kill $$; exec sleep 9; } &
wait $!
The above script ought exit quickly, and not leave a stray
"sleep" child:
(1) if "kill $$" signal is
26 matches
Mail list logo
