Re: Assigning to BASHPID fails silently
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:~$
Re: Assigning to BASHPID fails silently
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). >
[minor] Space after last element on assoc print
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
On 10/19/16 8:16 PM, Eduardo A. Bustamante López wrote: > I wonder the same thing. I don't understand the reasoning for picking (2). It's useful functionality with a particular meaning. If you want to use that variable for something else, you can. -- ``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: Assigning to BASHPID fails silently
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/
Re: Assigning to BASHPID fails silently
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
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
On Fri, Oct 21, 2016 at 1:31 AM, lolilolicon wrote: > bash simply aborts this command. I think I mean "list".
Is this the expected behaviour for nameref in Bash 4.4 now?
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
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/
Re: Assigning to BASHPID fails silently
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: Is this the expected behaviour for nameref in Bash 4.4 now?
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
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: [minor] Space after last element on assoc print
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: [minor] Space after last element on assoc print
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
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
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: Is this the expected behaviour for nameref in Bash 4.4 now?
Thanks for replying.
I was expecting that in the second iteration of the loop, the
local var=var_123 command would make var a normal variable again with
value "var_123"
and then the local -n var=$var would make var again a nameref to var_123.
This seems
to be the behavior of Bash 4.3.
But anyway, it's easy to work around by introducing another variable rather
than redefining the nameref var:
set -x
var_123=123
f() {
while (( $# )); do
shift
local var=var_123
local -n var_ref=$var
done
}
f one two
On Thu, Oct 20, 2016 at 4:02 PM, Dan Douglas wrote:
> 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.
>
