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
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 pre
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
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 l
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 ari
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
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 t
On Fri, Oct 21, 2016 at 1:31 AM, lolilolicon wrote:
> bash simply aborts this command.
I think I mean "list".
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=
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.
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 assign
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 assi
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-cons
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
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.
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:
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
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
18 matches
Mail list logo
