Old behavior, bash 4.2.45:
$ bash -c 'set -u; echo ${#arr1[@]}'; \
bash -c 'set -u; declare var1; echo ${#var1}'; \
bash -c 'set -u; declare -a arr2; echo ${#arr2[@]}'
bash: arr1: unbound variable
bash: var1: unbound variable
0
New behavior, bash 4.3:
$ bash -c 'set -u; echo ${#arr1[@]}'; \
bas
On 3/19/14, 5:42 PM, Geir Hauge wrote:
> > Description:
> > With an associative array, assoc, ${assoc[key]+set} expands to the
> > empty string if the associated value is the empty string.
>
> Thanks for the report. This was a consequence of a change made back in
> 20
" bash doesn't do anything until the child exits" --- yes, that is exactly
what I have observed.
Thank you very much for your exclamation, Ramey.
/br
Ruan
-Original Message-
From: Chet Ramey [mailto:chet.ra...@case.edu]
Sent: 2014年3月19日 21:51
To: Ryan Ruan; bug-bash@gnu.org
Cc: chet.ra
2014-03-19 09:51:06 -0400, Chet Ramey:
[...]
> This is another instance of the question "what does bash do with a SIGINT
> it receives while waiting for a foreground process?" The answer is that it
> allows the child to decide what to do and responds accordingly: if the
> child exits due to being
Linda Walsh wrote:
Sure, you could forget the timing part -- and have bash check
for every child, it's reason for exiting and if ENOENT, then check
whatever path the child was just spawned with if you wanted a general
solution for a low-incident problem. It would still be better than
havin
Chris Down wrote:
Linda Walsh writes:
If this was a reactor control program, that's one thing, but in
deciding what solution to implement to save some small lookup time or
throw it away, an 90% solution is probably fine. It's called a
heuristic. AI machines use them. Thinking people use the
2014-03-18 16:19 GMT+01:00 Chet Ramey :
> On 3/18/14 5:36 AM, geir.ha...@gmail.com wrote:
>
> > Bash Version: 4.3
> > Patch Level: 0
> > Release Status: release
> >
> > Description:
> > With an associative array, assoc, ${assoc[key]+set} expands to the
> > empty string if the associated va
Mike Frysinger wrote:
i already highlighted a technical way of solving it 100% of the time.
-mike
Wasn't that the method of incurring the existence check
for all executions in the parent to check for the rare
case that a hashed image that a child was about to execute
didn't exist AND the
Thank you, Greg.
It turned out I was wrong in the basics.
Your explanation made me to review my code.
I will be more careful in the future.
19 марта 2014 г., в 18:27, Greg Wooledge написал(а):
> On Wed, Mar 19, 2014 at 02:18:52PM +0400, Dmitry Arkhireev wrote:
>> And if run it sample with echo
On Wed, Mar 19, 2014 at 02:18:52PM +0400, Dmitry Arkhireev wrote:
> And if run it sample with echo $I after ((I++)) everything works as expected
> I=0; while [ $I -ne 1 ]; do ((I++)); echo $I; done; echo $?
> 1
> 0
Here, $? is the exit status of the echo, instead of the ((...)) command.
The ((...)
Hello, I observe strange behavior in bash exit status
I=0; while [ $I -ne 1 ]; do ((I++)); done; echo $?
1
but
I=0; while [ $I -ne 0 ]; do ((I++)); done; echo $?
0
I=0; while [ $I -ne 2 ]; do ((I++)); done; echo $?
0
And if run it sample with echo $I after ((I++)) everything works as expected
I=
On 3/19/14 12:07 AM, Ryan Ruan wrote:
> Hello, guys:
>
> It is said that "ctrl-C sends INT to ALL processes under foreground job", but
> i found a weird phenomenon.
> I have not read source code yet, but it does not seem to ascribe to what
> specification says.
>
> Test code is like:
>
> 1
Linda Walsh writes:
> If this was a reactor control program, that's one thing, but in
> deciding what solution to implement to save some small lookup time or
> throw it away, an 90% solution is probably fine. It's called a
> heuristic. AI machines use them. Thinking people use them. Why
> shoul
2014-03-19 04:07:06 +, Ryan Ruan:
[...]
> It is said that "ctrl-C sends INT to ALL processes under foreground job", but
> i found a weird phenomenon.
> I have not read source code yet, but it does not seem to ascribe to what
> specification says.
>
> Test code is like:
>
> 1 tr
Hi Mike,
Thanks a lot for quick answer. I'm sure that you in the right way. And I
hope you will test autotool scripts for both cases (system installed
readline; and inside bash src readline) for the future releases. (by the
way, the same situation we have in GCC with gmp)
I will try to use AC_TRY
15 matches
Mail list logo
