Re: [minor] Space after last element on assoc print

2016-10-20 Thread Chet Ramey 
On 10/20/16 5:25 PM, Dan Douglas wrote:
> By the way, that space at the end has been pointed out a number of
> times lately. I think Chet clarified at some point that that's just
> the way the serializer prints it - so it's nothing. Apparently a lot
> of people think it's meaningful.

I should add a space at the beginning for symmetry.

-- 
``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: [minor] Space after last element on assoc print

2016-10-20 Thread Quentin L'Hours 

On 10/20/2016 10:40 PM, Dan Douglas wrote:

On Wed, Oct 19, 2016 at 11:47 PM, Quentin L'Hours

Useless space after last item of a declare -p on an assoc array (indexed
arrays don't print it, and neither does ksh typeset on assoc arrays).
It doesn't seem to have any consequence though.

Repeat-By:

$ declare -A capital[fr]=Paris
$ declare -p capital
declare -A capital=([fr]="Paris" )


You cannot assign an attribute to an individual element of any array. The
behaviour for indexed arrays is described in the manual:

"declare -a name[subscript] is also accepted; the subscript is ignored."

In the case of a previously declared associative array in the current
scope, one might argue that bash should throw an error instead. I think
what you're seeing is bash taking a "reasonable default" instead of
throwing an error in response to a nonsensical assignment.


I think you misunderstood what I was really talking about, I was just 
pointing out a useless space printed by declare -p on an assoc array 
(which isn't present for indexed arrays).
I'm not trying to add any attribute to an individual element, I'm just 
printing the contents of the array.


Sorry if the example was misleading,

--
Quentin L'Hours

Re: [minor] Space after last element on assoc print

2016-10-20 Thread Dan Douglas 
By the way, that space at the end has been pointed out a number of
times lately. I think Chet clarified at some point that that's just
the way the serializer prints it - so it's nothing. Apparently a lot
of people think it's meaningful.

Re: [minor] Space after last element on assoc print

2016-10-20 Thread Dan Douglas 
On Wed, Oct 19, 2016 at 11:47 PM, Quentin L'Hours
 wrote:
> Hi,
>
> Bash Version: 4.4
> Release Status: release
>
> Description:
>
> Useless space after last item of a declare -p on an assoc array (indexed
> arrays don't print it, and neither does ksh typeset on assoc arrays).
> It doesn't seem to have any consequence though.
>
> Repeat-By:
>
> $ declare -A capital[fr]=Paris
> $ declare -p capital
> declare -A capital=([fr]="Paris" )

You cannot assign an attribute to an individual element of any array. The
behaviour for indexed arrays is described in the manual:

"declare -a name[subscript] is also accepted; the subscript is ignored."

In the case of a previously declared associative array in the current
scope, one might argue that bash should throw an error instead. I think
what you're seeing is bash taking a "reasonable default" instead of
throwing an error in response to a nonsensical assignment.

Note that ksh93 is different in some respects because it allows "nested
variables".

Re: Assigning to BASHPID fails silently

2016-10-20 Thread Chet Ramey 
On 10/20/16 3:57 PM, Dan Douglas wrote:

>> No, it's trivial.  It's an assignment failure.  The fix is to remove
>> the readonly attribute.
> 
> Makes sense to me. I noticed the problem on the same day this was
> reported while trying to compare two environments while eliminating all
> the non-constant dynamic variables from the comparison, that I could
> only override BASHPID by calling bash with:

It's interesting how the reports cluster like that.  The behavior has
been the same since December, 2006 (development implementation, very
soon after bash-3.2 released) and February, 2009 (bash-4.0 released).

-- 
``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: Is this the expected behaviour for nameref in Bash 4.4 now?

2016-10-20 Thread Dan Douglas 
Yes that was an intentional change to require valid identifiers. I can't
say it will always be that way or that there won't at some point be a
workaround. You can stiill use `${!param}' for now to refer to positional
parameters as you always could, but as usual that isn't useful if you
want to assign by reference.

Re: Assigning to BASHPID fails silently

2016-10-20 Thread Dan Douglas 
On Thu, Oct 20, 2016 at 2:35 PM, Chet Ramey  wrote:
> On 10/20/16 11:32 AM, Martijn Dekker wrote:
>
>> So, in some contexts this bug causes a premature exit of the shell, in
>> others it causes a premature exit of a loop. This bug hunt could get
>> interesting.
>
> No, it's trivial.  It's an assignment failure.  The fix is to remove
> the readonly attribute.

Makes sense to me. I noticed the problem on the same day this was
reported while trying to compare two environments while eliminating all
the non-constant dynamic variables from the comparison, that I could
only override BASHPID by calling bash with:

env BASHPID= -- bash -c ...

Seems removing readonly is the thing to do to make it work as
described in variables.c without having to call bash through env.

Re: Assigning to BASHPID fails silently

2016-10-20 Thread Chet Ramey 
On 10/20/16 11:32 AM, Martijn Dekker wrote:

> So, in some contexts this bug causes a premature exit of the shell, in
> others it causes a premature exit of a loop. This bug hunt could get
> interesting.

No, it's trivial.  It's an assignment failure.  The fix is to remove
the readonly attribute.

-- 
``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/

Is this the expected behaviour for nameref in Bash 4.4 now?

2016-10-20 Thread kjkuan 
set -x

var_123=123
f() {
while (( $# )); do
shift
local var=var_123
local -n var=$var; : status is $?
local -p
: var is $var
done
}

f one two


Running above script gives the follow output:

+ var_123=123
+ f one two
+ ((  2  ))
+ shift
+ local var=var_123
+ local -n var=var_123
+ : status is 0
+ local -p
var=var_123
+ : var is 123
+ ((  1  ))
+ shift
+ local var=var_123
+ local -n var=123
./x.sh: line 10: local: `123': invalid variable name for name reference
+ : status is 1
+ local -p
var=var_123
+ : var is 123
+ ((  0  ))


With Bash 4.3 the output is:

+ var_123=123
+ f one two
+ ((  2  ))
+ shift
+ local var=var_123
+ local -n var=var_123
+ : status is 0
+ local -p
var=var_123
+ : var is 123
+ ((  1  ))
+ shift
+ local var=var_123
+ local -n var=var_123
+ : status is 0
+ local -p
var=var_123
+ : var is 123
+ ((  0  ))


Thanks
Jack

Re: Assigning to BASHPID fails silently

2016-10-20 Thread lolilolicon 
On Fri, Oct 21, 2016 at 1:31 AM, lolilolicon  wrote:
> bash simply aborts this command.

I think I mean "list".

Re: Assigning to BASHPID fails silently

2016-10-20 Thread lolilolicon 
On Thu, Oct 20, 2016 at 11:32 PM, Martijn Dekker  wrote:
> #! /usr/local/bin/bash
> insubshell() {
> return "$((BASHPID=$$))"
> # ^ fatal typo
> }
> for ((i=0; i<1; i++)); do insubshell; done
> echo $i
> insubshell || echo ok
> echo continuing
>
> The output of this script on my copy of bash-4.4.0 is consistently:
>
> | 0
> | continuing
>
> Clearly, that 0 should be 1. The 'insubshell' function somehow
> manages to interrupt the 'for' loop.

It's not so much the for loop. See,

$ BASHPID= echo k
bash: BASHPID: readonly variable
k
$ BASHPID=; echo k
$ echo k
k

See the second k is not printed. bash simply aborts this command. In
your case, the for compound command.
The bug probably is very clear to Chet already.

Re: Assigning to BASHPID fails silently

2016-10-20 Thread Martijn Dekker 
Op 20-10-16 om 14:22 schreef Greg Wooledge:
> On Wed, Oct 19, 2016 at 11:53:37PM +0200, Martijn Dekker wrote:
>> Assigning to BASHPID most certainly does have an effect. Since you
>> didn't quote that part, I think you might have missed my point that
>> attempting this will silently exit the shell without any error message,
>> causing the problem to be hard to track down.
> 
> Cannot reproduce:
> 
> imadev:~$ bash
> imadev:~$ echo $$
> 5659
> imadev:~$ BASHPID=923
> imadev:~$ echo $$
> 5659
> imadev:~$ exit
> imadev:~$ 

Urgh...

#! /usr/local/bin/bash
insubshell() {
return "$((BASHPID=$$))"
# ^ fatal typo
}
insubshell
echo continuing

The above script failed to produce output *once* (when run as 'bash
test.sh' with bash 4.4) and then output "continuing" ever since, so I
was suspecting a race condition. I can't reproduce it that way now for
the life of me, though.

However, a tweak proves I didn't lose my mind after all:

#! /usr/local/bin/bash
insubshell() {
return "$((BASHPID=$$))"
# ^ fatal typo
}
for ((i=0; i<1; i++)); do insubshell; done
echo $i
insubshell || echo ok
echo continuing

The output of this script on my copy of bash-4.4.0 is consistently:

| 0
| continuing

Clearly, that 0 should be 1. The 'insubshell' function somehow
manages to interrupt the 'for' loop.

So, in some contexts this bug causes a premature exit of the shell, in
others it causes a premature exit of a loop. This bug hunt could get
interesting.

This is on bash 4.4.0-release compiled by myself with default options on
Mac OS X 10.11.6 using "Apple LLVM version 7.3.0 (clang-703.0.31)",
architecture x86_64.

HTH,

- M.

Re: Assigning to BASHPID fails silently

2016-10-20 Thread Chet Ramey 
On 10/19/16 5:53 PM, Martijn Dekker wrote:
> Op 19-10-16 om 15:18 schreef Chet Ramey:
>> On 10/17/16 2:38 PM, Martijn Dekker wrote:
>>> bash 4.4.0 (I did not investigate other versions) does not produce an
>>> error message if you try to assign something to the BASHPID readonly
>>> using either arithmetic or normal assignment. Other readonlies produce a
>>> message on an assignment attempt. BASHPID seems to be an exception.
>>
>> BASHPID is a dynamic variable.  There should be a sentence in the man
>> page that says assignments to it have no effect (as it does for GROUPS
>> and FUNCNAME, for example).
> 
> Assigning to BASHPID most certainly does have an effect. Since you
> didn't quote that part, I think you might have missed my point that
> attempting this will silently exit the shell without any error message,

This is a consequence of it being marked as readonly, and you running it
in a configuration where assignment errors cause the shell to exit.  It
shouldn't be marked as readonly, and it should be documented that
assignments to it are discarded.

> In what possible context would assigning to any of these variables make
> sense, or be an indication of anything other than a fatal bug in the
> script? I think they should all be readonly, and produce a proper
> diagnostic error message upon exit if assigning is attempted.

OK, you've made your position clear.

-- 
``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/

[minor] Space after last element on assoc print

2016-10-20 Thread Quentin L'Hours 

Hi,

Bash Version: 4.4
Release Status: release

Description:

Useless space after last item of a declare -p on an assoc array (indexed 
arrays don't print it, and neither does ksh typeset on assoc arrays).

It doesn't seem to have any consequence though.

Repeat-By:

$ declare -A capital[fr]=Paris
$ declare -p capital
declare -A capital=([fr]="Paris" )

Fix:

Maybe just rlen-- just after looping on all elements in assoc.c

--
Quentin L'Hours

Re: Assigning to BASHPID fails silently

2016-10-20 Thread PePa 
Picking 2 allows old scripts that work to keep working. Changing to 1
would change the functionality of formerly working scripts in very
undesirable ways. ;-)

> 1. BASHPID is readonly, therefore assignment to it is fatal and the script 
> exits
> (with an error message printed). That's what my previous patch did.
> 
> 2. BASHPID is not read-only, but changes to it are discarded (with the null
> assignement function). Assignments to BASHPID are non-fatal, and it's possible
> to unset it. Once it's unset, it's magical meaning is lost. (I think this is
> what Chet is proposing). noro_bashpid.patch
> 
>> In what possible context would assigning to any of these variables make
>> sense, or be an indication of anything other than a fatal bug in the
>> script? I think they should all be readonly, and produce a proper
>> diagnostic error message upon exit if assigning is attempted.
> [...]
> 
> I wonder the same thing. I don't understand the reasoning for picking (2).
>

Re: Assigning to BASHPID fails silently

2016-10-20 Thread Greg Wooledge 
On Wed, Oct 19, 2016 at 11:53:37PM +0200, Martijn Dekker wrote:
> Assigning to BASHPID most certainly does have an effect. Since you
> didn't quote that part, I think you might have missed my point that
> attempting this will silently exit the shell without any error message,
> causing the problem to be hard to track down.

Cannot reproduce:

imadev:~$ bash
imadev:~$ echo $$
5659
imadev:~$ BASHPID=923
imadev:~$ echo $$
5659
imadev:~$ exit
imadev:~$