Re: issue with vredir6.sub and AIX - bash (sub-shell) is crashing durig manual replication of test
On 10/24/20 1:17 PM, Michael Felt wrote: > OK. Thanks for the reply - and apologies for slow response. > > I was expecting a summary of the test results. I thought the other > projects you lead ended with test summaries. No, there have never been summaries. > If you care to help me find where the wrong error number is being > returned I'll try and come up with a PR to fix this test for AIX. If > not, we can consider this thread 'closed'. It's just AIX interpreting the error condition differently. I think POSIX permits both interpretations. Since bash just prints the error message corresponding to errno, and the test is ensuring that the shell prints an error message on this condition, it's dependent on what the system call returns. I don't think it's worth trying to work around it. -- ``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/
Re: issue with vredir6.sub and AIX - bash (sub-shell) is crashing durig manual replication of test
OK. Thanks for the reply - and apologies for slow response. I was expecting a summary of the test results. I thought the other projects you lead ended with test summaries. If you care to help me find where the wrong error number is being returned I'll try and come up with a PR to fix this test for AIX. If not, we can consider this thread 'closed'. Sincerely, Michael On 16/10/2020 15:16, Chet Ramey wrote: > On 10/16/20 6:31 AM, Michael Felt wrote: > >> 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. > There is no "rest of the test suite." That is the last test script. Bash > runs all the tests to completion. >
Re: issue with vredir6.sub and AIX - bash (sub-shell) is crashing durig manual replication of test
On 10/16/20 6:31 AM, Michael Felt wrote: > 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. There is no "rest of the test suite." That is the last test script. Bash runs all the tests to completion. -- ``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/
Re: issue with vredir6.sub and AIX - bash (sub-shell) is crashing durig manual replication of test
FYI: modified the script to:
```
root@x065:[/data/prj/gnu/bash/bash-5.0.18]cat -n *sub
1 unset v
2 exec {v}= 10 )); then echo ok 1; else echo bad 1; fi
5
6 exec {v}<&-
7
8 ulimit -n 6
9
10 exec 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 >> $ 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 > That's not a crash.
>>
>
>
Re: issue with vredir6.sub and AIX - bash (sub-shell) is crashing durig manual replication of test
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 > $ 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 That's not a crash. >
Re: issue with vredir6.sub and AIX - bash (sub-shell) is crashing durig manual replication of test
On 15/10/2020 16:11, k...@plushkava.net wrote: > On 15/10/2020 08:03, Michael Felt wrote: > >> $ exec > $ exit >> 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 Upon running "exec attached to your terminal emulator. Consequently, bash tries to read > from /dev/null, only to encounter EOF. As there is no further input to > be processed, it exits. > > You can prevent this from happening by running a script, or by using > the -c option to convey the code. Doing so will launch a > non-interactive instance of bash that does not read commands from the > standard input. > > Incidentally, it is not a subshell but an ordinary subprocess. Thanks - I'll try and give that a try to help understand what is going on in the test. As I'll mention in my reply to Chet - the concern is because 'make test' stops, rather than just report an error.
Re: issue with vredir6.sub and AIX - bash (sub-shell) is crashing durig manual replication of test
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 $ 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 http://tiswww.cwru.edu/~chet/
Re: issue with vredir6.sub and AIX - bash (sub-shell) is crashing durig manual replication of test
On 15/10/2020 08:03, Michael Felt wrote: $ exec Upon running "exec to your terminal emulator. Consequently, bash tries to read from /dev/null, only to encounter EOF. As there is no further input to be processed, it exits. You can prevent this from happening by running a script, or by using the -c option to convey the code. Doing so will launch a non-interactive instance of bash that does not read commands from the standard input. Incidentally, it is not a subshell but an ordinary subprocess. -- Kerin Millar
Re: issue with vredir6.sub and AIX - bash (sub-shell) is crashing durig manual replication of test
Just repeated this on a system with bash that I did not package - and I
get the same results:
BASH_VERSINFO=([0]="4" [1]="4" [2]="0" [3]="1" [4]="release"
[5]="powerpc-ibm-aix6.1.0.0")
BASH_VERSION='4.4.0(1)-release'
...
```
_=/usr/bin/bash
aixtools@gcc119:[/home/aixtools]PS1='$ '
$ unset v
$ exec {v} 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.
>
> 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
> root@x065:[/data/prj/gnu/bash/bash-4.4.23]
>
> To try and understand what is going on - I ran the following commands
> from the CLI. I hope you can give me some suggestions on what to look at.
>
> ```
>
> root@x065:[/data/prj/gnu/bash/bash-5.0.18]./bash
> root@x065:[/data/prj/gnu/bash/bash-5.0.18]PS1='$ '
> $ unset v
> $ exec {v} $ echo $v
> 10
> $ exec {v}<&-
> $ ulimit -n
> 2
> $ ulimit -n 6
> $ ulimit -n
> 6
> $ exec $ exit
> 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
> Hope this helps,
>
> Michael (aka aixtools).
>
>
>
>
issue with vredir6.sub and AIX - bash (sub-shell) is crashing durig manual replication of test
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.
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
root@x065:[/data/prj/gnu/bash/bash-4.4.23]
To try and understand what is going on - I ran the following commands
from the CLI. I hope you can give me some suggestions on what to look at.
```
root@x065:[/data/prj/gnu/bash/bash-5.0.18]./bash
root@x065:[/data/prj/gnu/bash/bash-5.0.18]PS1='$ '
$ unset v
$ exec {v}
