wait and procsubs

[isabella parakiss]

wait doesn't wait for procsubs unless it's passed the pid as an argument

$ time { : <(sleep 1); wait; }
real: 0m0.002s, user: 0m0.000s, sys: 0m0.003s
$ time { : <(sleep 1); wait $!; }
real: 0m1.011s, user: 0m0.003s, sys: 0m0.007s

is this intended or is it a bug?

this also means it's impossible to wait for both y and z in x <(y) <(z)

---
xoxo iza

Re: GNU Bash 4.4 Test Discrepancy on OpenVMS

[Chet Ramey]

On 10/7/16 12:54 PM, Eric W. Robertson wrote:
> While building and testing GNU Bash 4.4 on OpenVMS, the GNU Bash test
> script issued the following difference between OpenVMS Bash produced output
> and reference output for the test sub-script tests/exp8.sub (lines 28 - 31)
> 
> unset array
> declare -A array
> array=( [$'x\001y\177z']=$'a\242b\002c' )
> echo ${array[@]@A}
> 
> Currently, the reference result expected for ALL platform implementations
> for the above sequence of Bash test commands is embodied in tests/exp.right
> (line 236):
> 
> declare -A array=([$'x\001y\177z']=$'a\242b\002c' )
> 
> on OpenVMS the following output is generated instead:
> 
> declare -A array=([$'x\001y\177z']=$'a¢b\002c' )
> 
> After studying the applicable sections of the relevant ISO and POSIX
> standards and inspection of Bash's execution within the OpenVMS Debugger, I
> have come to the conclusion that this difference arises out of an
> implementation dependent difference with respect to the locale dependent
> characteristics of characters in the C/POSIX locale.

You're right.  VMS happens to have a character mapped to that value in
the default locale (or at least your default locale), and no other
system does.  It's not a test failure; it's just an anomaly.  That value
was `chosen' because it is exactly the test script submitted as a bug
report in the past.


> While investigating this test discrepancy with Bash 4.4 on OpenVMS I came
> across another potential source code bug relating to the expansion of the
> ISPRINT() function macro. The expansion of the ISPRINT() function macro is,
> in turn, partially dependent on the expansion of the IN_CTYPE_DOMAIN()
> function macro. In the source code module include/chartypes.h, the function
> macro IN_CTYPE_DOMAIN() does not seem to be correctly defined for platforms
> not providing the isascii() function. 

If you're running on a platform that doesn't provide isascii(), and the
STDC_HEADERS define doesn't evaluate to something non-zero (see below, or
look at the comment in chartypes.h), all bets are off.  That
function/define is not optional (obsolescent is not optional); Posix
requires it and it's there on virtually every Unix system.

The constant 1 means you make a bet that the rest of the ctype functions
check that their arguments are valid ascii characters if it matters, and
otherwise it doesn't and you don't need to check it.


> Given the normative definition of the
> isascii() function in "The Open Group Base Specifications Issue 7 (IEEE Std
> 1003.1-2008) 2016 Edition", the current definition of the IN_CTYPE_DOMAIN()
> function macro (as the literal constant expression 1) is unlikely to result
> in any close approximation of correct behavior for most platforms not
> implementing the isascii() function. Instead, I believe the
> IN_CTYPE_DOMAIN() function macro would be better defined as follows:

Not quite.  The STDC_HEADERS define, if set, means that you don't have to
guard references to the ctype macros with checks using isascii().  You'd
be better off, if you wanted to really do it, with something like:

#if !defined (isascii) && !HAVE_ISASCII
#  define isascii(x)((x) >= 0 && (x) <= 127)/* basic */
#endif

and leave the rest of the code intact.

-- 
``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/

Bug: Failed to read initial configuration, open() syscall might be interrupted.

[Andriy Prystupa]

This was reproduced on Ubuntu 14.04 in VirtualBox. But I guess that issue
exists on other distros.
It is very timing dependent issue. Using Gdb or strace easily hide it.

Our kernel has custom LSM. so open() syscall timing might be little bit
changed some time. It has same effect as on slow devices I guess.


On Monday, October 10, 2016, Chet Ramey > wrote:

> On 10/5/16 9:04 AM, Andriy Prystupa wrote:
> > Hi,
> >
> >
> > Error:
> >
> > */bash: /etc/bash.bashrc: Interrupted system call /*
> >
> > Reproduced on bash-4.4 via *gnome-terminal* or *terminator* terminal.
>
> This is interesting.  On what version of Unix/Linux is open(2) on a regular
> file from the local file system interrupted?  Traditional behavior is that
> open can be interrupted when used on a `slow' device, but not otherwise.
>
> --
> ``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/~ch
> et/
>


-- 

Andriy Prystupa | SW Engineer
GlobalLogic
M +38.097.330.9412  S prandriy
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt

Re: Bug: Failed to read initial configuration, open() syscall might be interrupted.

[Chet Ramey]

On 10/5/16 9:04 AM, Andriy Prystupa wrote:
> Hi, 
> 
> 
> Error: 
> 
> */bash: /etc/bash.bashrc: Interrupted system call /*
> 
> Reproduced on bash-4.4 via *gnome-terminal* or *terminator* terminal.

This is interesting.  On what version of Unix/Linux is open(2) on a regular
file from the local file system interrupted?  Traditional behavior is that
open can be interrupted when used on a `slow' device, but not otherwise.

-- 
``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: Question about arithmetic expression grammar

[Stephane Chazelas]

2016-10-08 17:33:00 +0200, Conrad Hoffmann:
[...]
>   $ TEST=5; echo $((--TEST+++3)) # outputs 7
> 
> However, due to the documented operator precedence, I would have
> expected that expression to be equal to:
> 
>   $ TEST=5; echo $((--(TEST++)+3)) # outputs 8
> 
> Instead, though, it seems to be equal this one:
> 
>   $ TEST=5; echo $(((--TEST)+++3)) # outputs 7
> 
> So my qestions are:
> 
> Is this a bug? Or is this something that can't be resolved due
> ambiguities in the grammar? Or what's going on here at all?
[...]

--, ++ are optional in POSIX. That means you can't use those
operators in POSIX scripts and that if you need to combine two
unary - or + or a binary - with a unary -, you need to use
spaces or paren:

$((1--1)) # unspecified
$((--1)) # unspecified
$((--var)) # unspecified
$((1 - -1)) # OK
$((- -1)) # OK
$((1-(-1))) # OK
$((-(-1))) # OK

Now, if we look at the C spec, the way +++ is parsed is down to
tokenisation that will also go for the longest operator first.

There --test+++3 would be tokenised as -- test ++ + 3 which
would lead to a syntax error as test++ isn't an lvalue.

bash works differently.

>From what I understand from past discussions on the subject here
bash doesn't treat it as a syntax error and tries instead to tokenise
those incorrect ++/-- into multiple + or - operators if possible.

So here, --TEST+++3 is:

--TEST + +(+3)

And --(TEST++)+3

would be: -(-(TEST++))+3

-- 
Stephane