Re: issue with vredir6.sub and AIX - bash (sub-shell) is crashing durig manual replication of test

[Chet Ramey]

On 10/15/20 3:03 AM, Michael Felt wrote:
> Hi.
> 
> I don't actually use bash myself - so something that would be apparent
> to a bash user is invisible to me.
> 
> As part of the packaging of bash-5.0.18 (i.e., 5.0 at patch level 18) I
> ran the test suite.
> 
> a) is there a flag I can pass so that it ignores the UTF-8 tests? I do
> not want to not build UTF-8 support - for anyone who does load those
> language filesets, but I would prefer to not see that test show up as
> failed - rather as skipped.

There isn't. There isn't any way to make any part of the test suite
optional. I'd argue that UTF-8 support is the rule, rather than the
exception, anyway.

> 
> b) I have - apparently - been a LONG time since I last ran `make test`
> for bash, as I get the same error on bash-4.4 patch level 23, and on
> bash-5.0 patch level 11 and bash-5.0 patch level 18.
> 
> run-vredir
> 14,16c14,16
> < ./vredir.tests: line 25: $v: A file descriptor does not refer to an
> open file.
> < ./vredir.tests: line 26: $v: A file descriptor does not refer to an
> open file.
> < ./vredir.tests: line 27: $v: A file descriptor does not refer to an
> open file.
> ---
>> ./vredir.tests: line 25: $v: Bad file descriptor
>> ./vredir.tests: line 26: $v: Bad file descriptor
>> ./vredir.tests: line 27: $v: Bad file descriptor
> 90,91c90,91
> < ./vredir6.sub: redirection error: cannot duplicate fd: The process
> file table is full.
> < ./vredir6.sub: line 13: /dev/null: The process file table is full.
> ---
>> ./vredir6.sub: redirection error: cannot duplicate fd: Invalid argument
>> ./vredir6.sub: line 13: /dev/null: Invalid argument

These are simply different error messages for the same underlying error
(AIX is famous for these) or system calls returning different values of
errno for the same underlying failure (the last example above is EMFILE
vs. EINVAL, for instance). Some of the tests warn about this:

warning: the text of a system error message may vary between systems and
warning: produce diff output.


> $ exec </dev/null
> $ exit

You changed the shell's input -- from where it is reading commands -- to
/dev/null, the next read returned EOF, and the shell exited. It printed
`exit' so you know what's going on, just as if you had typed ^D at an
interactive shell prompt. This doesn't happen when you're executing a
script because the shell is reading commands from the script file.

> root@x065:[/data/prj/gnu/bash/bash-5.0.18]
> 
> ```
> 
> As you can see by the return of the original PS1 - the sub-shell
> (./bash) 'crashed' -- I did not type 'exit' - that is a result of the
> 'exec </dev/null' command the line before.

That's not a crash.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/