Re: varenv3.sub fails on some systems some of the time.
On 2/20/15 6:56 AM, Scott wrote: Hi, When we run the bash unittests on some system we occasionally get a error in the varenv3.sub script. ./varenv3.sub: cannot open named pipe /tmp/bash_tests.8150/sh-np-5140328 for writing: No such file or directory ./varenv3.sub: line 30: /tmp/bash_tests.8150/sh-np-843885584: No such file or directory Does the directory (which I assume is $TMPDIR) exist? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
varenv3.sub fails on some systems some of the time.
Hi, When we run the bash unittests on some system we occasionally get a error in the varenv3.sub script. ./varenv3.sub: cannot open named pipe /tmp/bash_tests.8150/sh-np-5140328 for writing: No such file or directory ./varenv3.sub: line 30: /tmp/bash_tests.8150/sh-np-843885584: No such file or directory We cross compile bash for our system with: ./configure --build=x86_64-unknown-linux-gnu --host=x86_64-pc-linux-gnu --libdir=/lib64 --prefix=/ --disable-nls ac_cv_func_mmap_fixed_mapped=yes gt_cv_int_divbyzero_sigfpe=yes ac_cv_func_strcoll_works=yes bash_cv_func_ctype_nonascii=no bash_cv_dup2_broken=no bash_cv_pgrp_pipe=no bash_cv_sys_siglist=no bash_cv_decl_under_sys_siglist=yes bash_cv_under_sys_siglist=yes bash_cv_opendir_not_robust=no bash_cv_ulimit_maxfds=yes bash_cv_getenv_redef=yes bash_cv_getcwd_malloc=yes bash_cv_func_sigsetjmp=present bash_cv_func_strcoll_broken=no bash_cv_printf_a_format=yes bash_cv_must_reinstall_sighandlers=no bash_cv_job_control_missing=present bash_cv_sys_named_pipes=present bash_cv_wcontinued_broken=no bash_cv_unusable_rtsigs=no bash_cv_dev_fd=absent bash_cv_dev_stdin=absent bash_cv_mail_dir=/dev/null GCC 4.8.2, glibc 2.18, seen on kernels 3.14.8 and 3.16.6 I'm hoping someone can help me narrow down the issue to find out what we are doing wrong. The problem seems to have been there since we upgraded to bash 4.3. Happy to give more information and try things out. Kind Regards Scott.
Re: varenv3.sub fails on some systems some of the time.
On Fri, Feb 20, 2015 at 09:08:30AM -0500, Chet Ramey wrote: On 2/20/15 6:56 AM, Scott wrote: Hi, When we run the bash unittests on some system we occasionally get a error in the varenv3.sub script. ./varenv3.sub: cannot open named pipe /tmp/bash_tests.8150/sh-np-5140328 for writing: No such file or directory ./varenv3.sub: line 30: /tmp/bash_tests.8150/sh-np-843885584: No such file or directory Does the directory (which I assume is $TMPDIR) exist? Yeah, directory exists which is why it works some of the time. I can reproduce the error with chmod u+x varenv3.sub; while ./varenv3.sub ; do sleep 0.1; done with default TMPDIR. HTH. Scott. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Trap does not work if a subshell wait(s) for job
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/18/15 8:06 AM, Dr. Werner Fink wrote:
Hi,
found due to a hang in the test suite of gnutls, after debugging I've
extract the example code
launch_server () { sleep 100 l=$!; trap kill -15 $l 15; echo $l;
wait $l; }
launch_server x=$!
sleep 2
kill $x
which does wait the full 100 seconds with bash 4.3 but with the old bash 4.2
only 2 seconds.
It sleeps 2 seconds on Mac OS X, Debian 7, Ubuntu 14, OpenSuSE 13, and
RHEL 5. Check whether or not SIGTERM is trapped or ignored when you run
the script.
- --
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (Darwin)
iEYEARECAAYFAlTnTPAACgkQu1hp8GTqdKsL0ACeJIi8wbkDqT2ZxJPF7xU99Y4h
WiMAn1BxOheMJyrbnLlqqg+GGACzPKi4
=DvS9
-END PGP SIGNATURE-
Re: array subscripts act differently for integers(ie. let)
On Thu, Feb 19, 2015 at 7:47 PM, Chet Ramey chet.ra...@case.edu wrote:
On 2/18/15 4:14 PM, emanuelczi...@cryptolab.net wrote:
tl;dr: thanks! no reply needed;
Thanks guys. I had a hard time accepting that this is how it's supposed to
work.
I accepted it now. :)
Yeah. The expression between (( and )) is word expanded, since (( ... ))
is supposed to be exactly equivalent to let
The real issue is that assignment statements in arithmetic expressions
that contain array references are also word expanded, almost as if they
were executed in an assignment statement context. This is how bash has
always behaved, though; backwards compatibility is a concern.
The way bash works right now allows safely handling arbitrary
associative array keys. This is a pretty good illustration:
$ bash -c 'key=\]; typeset -A a=([$key]=x [y]=y); unset -v
a[\${key}]; typeset -p a'
declare -A a='([y]=y )'
$ ksh -c 'key=\]; typeset -A a=([$key]=x [y]=y); unset -v
a[\${key}]; typeset -p a'
typeset -A a=([']']=x [y]=y)
Since ksh doesn't do parameter expansion while resolving variables
quite consistently it's impossible to handle this case. (I'll have to
ask about it on their list one of these days).
IMO bash is exactly correct. I don't know how this could be fixed in
a way that would satisfy people without changing something very
fundamental. If you disable the initial expansion to `(())', then
`(($x))' wouldn't work (because arithmetic evaluation doesn't itself
evaluate parameter expansions). However if you disabled evaluating
parameter expansions during variable resolution (for array indexes)
then you would be stuck with exactly the above ksh problem.
It's unfortunate people don't understand this, but when you think
about it it can't really work any other way.
--
Dan Douglas
Re: declare in a function makes a variable unable to be found with declare -p in some cases
Yes. The issue is that the assignment doesn't make the variable visible, when it clearly should. I've attached a patch that will fix that. And it does. The next version of bash will do things differently, as noted in a couple of followups to this message. The proposal that prompted the changes is part of a long thread from December: http://lists.gnu.org/archive/html/bug-bash/2014-12/msg00115.html Thanks to you both for the answers. I am glad to see that my original issue has been fixed. The thread is indeed long and detailed, so let me just leave a note about a weird behaviour with 4.4.0 (devel) I have that may or may not be the intended behaviour. bash-4.4$ e='(`uname 2`)'; declare -a a=$e; echo [$a] Linux [] bash-4.4$ e='(`uname 2`)'; declare -a a=$e; echo [$a] [(`uname 2`)] As you can see, only in the second case uname is not run. (One can also type unset a to have it execute again.) So there seems to be another inconsistency. By the way, I use `cmd` instead of $() because I have this: $ : $(echo x) bash: command substitution: line 8: syntax error near unexpected token `)' bash: command substitution: line 8: `echo x)'
