On Wed, Dec 15, 2021 at 04:54:19PM -0800, Eric Biggers wrote: > > Doesn't this happen with any shell command passed to -c, not just commands that > run an executable? In the commands below which are causing the problem, it is > actually the 'echo' built-in being used, not an executable. Well.... it happens with all executables and *some* built-in commands which returns an error. (See the postscript for a case where the line number is printed.) In the case of an error opening the redirected standard output, such as permission denied, the difference does occur: Compare: % schroot -c buster-amd64 -- bash -c "echo foo >> /bin/bash" bash: /bin/bash: Permission denied % schroot -c buster-amd64 -- bash --version GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu) Copyright (C) 2019 Free Software Foundation, Inc. ... with % schroot -c bullseye-amd64 -- bash -c "echo foo >> /bin/bash" bash: line 1: /bin/bash: Permission denied % schroot -c bullseye-amd64 -- bash --version GNU bash, version 5.1.4(1)-release (x86_64-pc-linux-gnu) ... I just used the example of "bash -c /etc/passwd" because it was simpler, and because it would be easy to verify regardless of whether the command was executed as root or not. For example: % schroot -c bullseye-amd64 -u root -- bash -c "echo foo >> /bin/bash" would have succeeded (and corrupted /bin/bash in my chroot :-). I suppose I could have used the "schroot -c ..." example in the commit description, but that's a debian-specific command, and I chose to err on the side of something simpler and easier to replicate. If Eryu would prefer, I can resend with a modified commit description, or he can feel free to edit the commit description with the above example if he thinks it's clearer. Cheers, - Ted P.S. The 5.1 behavior is actually a bit more consistent, since other errors involving built-ins do actualy print a line number (although not a *consistent* line number between bash 5.0 and 5.1: % schroot -c buster-amd64 -- bash -c "jobs --bad-option" bash: line 0: jobs: --: invalid option ... vs % schroot -c bullseye-amd64 -- bash -c "jobs --bad-option" bash: line 1: jobs: --: invalid option ... So the changes in Bash 5.1 error reporting does have something to recommend itself in terms of self-consistency, but it is a bit of pain for xfstests, where any changes in output requires extra filter hacking!
