FYI: modified the script to:
```
root@x065:[/data/prj/gnu/bash/bash-5.0.18]cat -n *sub
1 unset v
2 exec {v}</dev/null
3
4 if (( v >= 10 )); then echo ok 1; else echo bad 1; fi
5
6 exec {v}<&-
7
8 ulimit -n 6
9
10 exec </dev/null
11 echo $0: ${LINENO}: Status is: $?
12
13 unset v
14 exec {v}</dev/null
15 echo $0: ${LINENO}: Status is: $?
16 echo ${v-unset}
```
Result is:
```
root@x065:[/data/prj/gnu/bash/bash-5.0.18]./bash vredir6.sub
ok 1
vredir6.sub: 11: Status is: 0
vredir6.sub: redirection error: cannot duplicate fd: The process file
table is full.
vredir6.sub: line 14: /dev/null: The process file table is full.
vredir6.sub: 15: Status is: 1
unset
```
If you assist - I am willing to help with developing a patch/PR for the
error message aka errno being returned by AIX.
Further, my real concern at this point is that `make test` or `make
check` stop with this test step.
Thanks for your consideration!
Michael
On 16/10/2020 12:31, Michael Felt wrote:
> 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.
>>
>
>
