Re: FIFO race condition on SunOS kernels
On 1/2/19 9:48 PM, Clark Wang wrote: > On Wed, Jan 2, 2019 at 8:38 PM Vladimir Marek > wrote: > >>> >>> Thanks, that's good to have confirmed! It was hoping as much -- it would >>> have been hard to believe that something this basic is broken on Solaris >> in >>> general. >> >> Heh :) I am heavy shell scripter/user and I have found multiple bugs in >> various shells. But I don't remember single issue with bash. >> > > I've been using Bash for ~15 years (from v2.05 to v5.0) and only hit a few > bugs. I appreciate you reporting them! -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
JIT in bash
The following test cases show that the variable length can significantly affect the runtime in bash. But the variable length doesn't seem to have a significant effect in some other interpreted languages, such as python. I can understand that variables length will slow down the runtime, as bash is interpreted. But I didn't expect that it should slow down the runtime so much. Does anybody happen to know the cause of the problem on why bash is slowed down so much compared with python when the variable length is increased? One way that I think can mitigate (but not solve the original problem) the problem is to use just-in-time (JIT) compilation. Python has a JIT compiler pypy. However, I don't see that bash has a JIT compiler. Is it because people think that bash is just a glue language so that making it run faster is not important, therefore there is no need to make a JIT compiler for bash? Or it is because the current bash code started very early and has certain limitation which makes it hard to create a new JIT compiler based on it? $ cat ./main.sh #!/usr/bin/env bash # vim: set noexpandtab tabstop=2: TIMEFORMAT=%R set -v time for ((i=0;i<1;++i)); do : done > /dev/null time for ((i=0;i<1;++i)); do : done > /dev/null time ./main.py 100 time ./main.py 1000 time ./main_long.py 100 time ./main_long.py 1000 $ cat main.py #!/usr/bin/env python # vim: set noexpandtab tabstop=2 shiftwidth=2 softtabstop=-1 fileencoding=utf-8: import sys for i in xrange(int(sys.argv[1])): pass $ ./main.sh time for ((i=0;i<1;++i)); do : done > /dev/null 0.148 time for ((i=0;i<1;++i)); do : done > /dev/null 0.321 time ./main.py 100 0.188 time ./main.py 1000 0.822 time ./main_long.py 100 0.164 time ./main_long.py 1000 0.945 -- Regards, Peng
Re: [IDEA] more granular shell options to fix errexit
Hi, [...] > The following suggested options aim to eliminate all cases that still exist, > outlined on the above link, where an exit code of a command is > swallowed/ignored. [...] My take on this, purely from user's point of view is to be able to instruct bash to exit any time any command returns non-zero value unless the situation is handled in the code. That means inside of if command; then ... or command || blah So what you suggested is something I would like to use. If I would to have command which does not terminate command || : If I want to catch the return value command && RET=$? || RET=$? OUT=$(command) && RET=$? || RET=$? Cheers -- Vlad
