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

[Michael Felt]

On 15/10/2020 16:21, Chet Ramey wrote:
> 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.
Yes - AIX - without UTF-8 is the exception for bash. I was not concerned
about the report.
I know that AIX is 'exceptional' :) pun intended.
>
>> 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.
OK. While - perhaps the root cause is differences in error-codes, or
something like that - and not to be overly concerned about (as I am not
with the UTF-8 'errors') I am concerned that 'make test' terminates at
this point - rather than continuing with the rest of the test suite.
>
>> $ 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.
I should have known that - but shell scripting is not my favorite
pasttime :)
>
>> 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.
>