Commands that work in bash-5.0 but not in bash-5.1-rc1
< bash-5.0 >
bash$ echo hello | cat <(cat) > >(tr a-z A-Z)
HELLO
< bash-5.1-rc1 >
bash$ echo hello | cat <(cat) > >(tr a-z A-Z)
<-- empty
---
< bash-5.0 >
bash$ cat <<\@ | gcc -fPIC -shared -Wl,--version-script=<(cat) -o
libfoo.so foo.c
LIBFOO_1.0 {
global:
libfoo_init; libfoo_doit; libfoo_done;
local:
*;
};
@
< bash-5.1-rc1 >
bash$ cat <<\@ | gcc -fPIC -shared -Wl,--version-script=<(cat) -o
libfoo.so foo.c
LIBFOO_1.0 {
global:
libfoo_init; libfoo_doit; libfoo_done;
local:
*;
};
@
/usr/bin/ld:/dev/fd/63:0: syntax error in VERSION script
< Error occurred
collect2: error: ld returned 1 exit status
New feature in bash 5.1/readline-8.1 rc1 breaks python-pexpect
Hi,
after build rc1 of bash 5.1 as well as readline-8.1 I've set up test
staging process. During build the package python-pexpect throws errors
in its test suite, e.g.
[ 260s] self =
[ 260s]
[ 260s] def test_async_replwrap_multiline(self):
[ 260s] bash = replwrap.bash()
[ 260s] coro = bash.run_command("echo '1 2\n3 4'", async_=True)
[ 260s] res = run(coro)
[ 260s] > self.assertEqual(res.strip().splitlines(), ['1 2', '3 4'])
[ 260s] E AssertionError: Lists differ: ['\x1b[?2004l',
'\x1b[?2004h\x1b[?2004l', '1 2', '3 4', '\x1b[?2004h'] != ['1 2', '3 4']
[ 260s] E
[ 260s] E First differing element 0:
[ 260s] E '\x1b[?2004l'
[ 260s] E '1 2'
[ 260s] E
[ 260s] E First list contains 3 additional elements.
[ 260s] E First extra element 2:
[ 260s] E '1 2'
[ 260s] E
[ 260s] E - ['\x1b[?2004l', '\x1b[?2004h\x1b[?2004l', '1 2', '3 4',
'\x1b[?2004h']
[ 260s] E + ['1 2', '3 4']
I found this is caused by (_rl_)enable[-_]bracketed[-_]paste as the sequences
are defined in rlprivate.h
#define BRACK_PASTE_INIT "\033[?2004h"
#define BRACK_PASTE_FINI "\033[?2004l\r"
indeed it is a nice feature to see highlighted paste content on the interactive
command line, but why this interferes with tools like pexpect using bash in
interactive mode?
Werner
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
signature.asc
Description: PGP signature
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 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
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: New feature in bash 5.1/readline-8.1 rc1 breaks python-pexpect
On 10/16/20 5:41 AM, Dr. Werner Fink wrote:
> Hi,
>
> after build rc1 of bash 5.1 as well as readline-8.1 I've set up test
> staging process. During build the package python-pexpect throws errors
> in its test suite, e.g.
>
> [ 260s] self = testMethod=test_async_replwrap_multiline>
> [ 260s]
> [ 260s] def test_async_replwrap_multiline(self):
> [ 260s] bash = replwrap.bash()
> [ 260s] coro = bash.run_command("echo '1 2\n3 4'", async_=True)
> [ 260s] res = run(coro)
> [ 260s] > self.assertEqual(res.strip().splitlines(), ['1 2', '3 4'])
> [ 260s] E AssertionError: Lists differ: ['\x1b[?2004l',
> '\x1b[?2004h\x1b[?2004l', '1 2', '3 4', '\x1b[?2004h'] != ['1 2', '3 4']
> [ 260s] E
> [ 260s] E First differing element 0:
> [ 260s] E '\x1b[?2004l'
> [ 260s] E '1 2'
> [ 260s] E
> [ 260s] E First list contains 3 additional elements.
> [ 260s] E First extra element 2:
> [ 260s] E '1 2'
> [ 260s] E
> [ 260s] E - ['\x1b[?2004l', '\x1b[?2004h\x1b[?2004l', '1 2', '3 4',
> '\x1b[?2004h']
> [ 260s] E + ['1 2', '3 4']
>
> I found this is caused by (_rl_)enable[-_]bracketed[-_]paste as the sequences
> are defined in rlprivate.h
>
> #define BRACK_PASTE_INIT "\033[?2004h"
> #define BRACK_PASTE_FINI "\033[?2004l\r"
>
> indeed it is a nice feature to see highlighted paste content on the
> interactive
> command line, but why this interferes with tools like pexpect using bash in
> interactive mode?
Yes, bracketed paste is currently enabled by default. I may change that by
the time 5.1 is released.
I don't understand your question about tools like pexpect. If bracketed
paste mode is on, it's on. How is readline supposed to know whether or not
its stdin and stdout are connected to expect? How is the interactive shell
run by pexpect different from one connected to a terminal?
--
``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: New feature in bash 5.1/readline-8.1 rc1 breaks python-pexpect
On 2020/10/16 09:03:53 -0400, Chet Ramey wrote:
> On 10/16/20 5:41 AM, Dr. Werner Fink wrote:
> > Hi,
> >
> > after build rc1 of bash 5.1 as well as readline-8.1 I've set up test
> > staging process. During build the package python-pexpect throws errors
> > in its test suite, e.g.
> >
> > [ 260s] self = > testMethod=test_async_replwrap_multiline>
> > [ 260s]
> > [ 260s] def test_async_replwrap_multiline(self):
> > [ 260s] bash = replwrap.bash()
> > [ 260s] coro = bash.run_command("echo '1 2\n3 4'", async_=True)
> > [ 260s] res = run(coro)
> > [ 260s] > self.assertEqual(res.strip().splitlines(), ['1 2', '3 4'])
> > [ 260s] E AssertionError: Lists differ: ['\x1b[?2004l',
> > '\x1b[?2004h\x1b[?2004l', '1 2', '3 4', '\x1b[?2004h'] != ['1 2', '3 4']
> > [ 260s] E
> > [ 260s] E First differing element 0:
> > [ 260s] E '\x1b[?2004l'
> > [ 260s] E '1 2'
> > [ 260s] E
> > [ 260s] E First list contains 3 additional elements.
> > [ 260s] E First extra element 2:
> > [ 260s] E '1 2'
> > [ 260s] E
> > [ 260s] E - ['\x1b[?2004l', '\x1b[?2004h\x1b[?2004l', '1 2', '3 4',
> > '\x1b[?2004h']
> > [ 260s] E + ['1 2', '3 4']
> >
> > I found this is caused by (_rl_)enable[-_]bracketed[-_]paste as the
> > sequences
> > are defined in rlprivate.h
> >
> > #define BRACK_PASTE_INIT "\033[?2004h"
> > #define BRACK_PASTE_FINI "\033[?2004l\r"
> >
> > indeed it is a nice feature to see highlighted paste content on the
> > interactive
> > command line, but why this interferes with tools like pexpect using bash in
> > interactive mode?
>
> Yes, bracketed paste is currently enabled by default. I may change that by
> the time 5.1 is released.
>
> I don't understand your question about tools like pexpect. If bracketed
> paste mode is on, it's on. How is readline supposed to know whether or not
> its stdin and stdout are connected to expect? How is the interactive shell
> run by pexpect different from one connected to a terminal?
I'm aware that if tools like pexpect uses a terminal emulator there is not
way to detect this. If this feature can (in principal) not distinguish between
a real paste on a real command line and input from an (p)expect tools then it
should (IMHO) not be enabled. Also a warning hint in the manual page could
help users before enabling this feature :)
Werner
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
signature.asc
Description: PGP signature
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: New feature in bash 5.1/readline-8.1 rc1 breaks python-pexpect
On 10/16/20 9:16 AM, Dr. Werner Fink wrote: > Also a warning hint in the manual page could > help users before enabling this feature :) I agree, and the manual page in the release will reflect bracketed paste's default setting. However, readline doesn't try to enable bracketed paste if tcgetattr fails, which it will on an fd that's not a terminal, so I am fairly sure that expect/pexpect use ptys to masquerade as terminals. The biggest problem with bracketed paste is that right now, there's simply no way to determine whether or not a particular terminal supports it. As for the hint, the man page is the wrong place for it. It's one of the items in CHANGES: h. Bracketed paste mode is enabled by default (for now). -- ``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: New feature in bash 5.1/readline-8.1 rc1 breaks python-pexpect
On Fri, Oct 16, 2020 at 09:28:26AM -0400, Chet Ramey wrote: > On 10/16/20 9:16 AM, Dr. Werner Fink wrote: > > > Also a warning hint in the manual page could > > help users before enabling this feature :) > > I agree, and the manual page in the release will reflect bracketed paste's > default setting. However, readline doesn't try to enable bracketed paste if > tcgetattr fails, which it will on an fd that's not a terminal, so I am > fairly sure that expect/pexpect use ptys to masquerade as terminals. They do -- or at least, the original Expect does. I'm guessing Pexpect follows Expect's lead here.
Name collision with nameref and local variable
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: x86_64-pc-linux-gnu-gcc
Compilation CFLAGS: -O2 -march=native -pipe -Wno-parentheses
-Wno-format-security
uname output: Linux sun 5.9.0-gentoo-k8s #1 SMP PREEMPT Tue Oct 13 23:59:55
CEST 2020 x86_64 AMD FX(tm)-8350 Eight-Core Processor AuthenticAMD GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.0
Patch Level: 18
Release Status: release
Description:
This worked just fine on Bash 4.2:
foo() {
local -a args=("${!1}")
echo "[IN] ${args[@]}"
}
declare -a args=("$@")
echo "Bash ${BASH_VERSION}"
echo "[OUT] ${args[@]}"
foo args[@]
eg.
$ ./test.sh 1 2 3
Bash 4.2.46(2)-release
[OUT] 1 2 3
[IN] 1 2 3
whereas on Bash 5.0 we get:
$ ./test.sh 1 2 3
Bash 5.0.18(1)-release
[OUT] 1 2 3
[IN]
Renaming local variable args (in foo) to something else also gives expected
results.
