Re: Running 32 bit program on 64 bit system makes bash etc. look bad
On 2019-11-02 at 07:56 +0800, 積丹尼 Dan Jacobson wrote:
> $ mapping/taipower/pole2tm
> bash: mapping/taipower/pole2tm: No such file or directory
>
> Must be a bash bug! Proof:
> $ ls -l mapping/taipower/pole2tm
> -rwxr-xr-x 1 jidanni jidanni 11290 2012-06-19 mapping/taipower/pole2tm
>
> But wait,
> $ strace mapping/taipower/pole2tm
> execve("mapping/taipower/pole2tm", ["mapping/taipower/pole2tm"],
> 0x7ffd53416200 /* 58 vars */) = -1 ENOENT (No such file or directory)
> strace: exec: No such file or directory
> +++ exited with 1 +++
>
> Must also be a strace bug...
>
> Ah,
> $ file mapping/taipower/pole2tm
> mapping/taipower/pole2tm: ELF 32-bit LSB executable...
>
> but we are running it on
> $ arch
> x86_64
That's not exactly the problem, although related.
ELF programs may be static (rare) or dynamic, in which case they include
in their header that they should be run with an interpreter such
as /lib/ld-linux.so
If it is a 32 bit program being run on a 64 bit arch, it is most likely
pointing to a binary that is not present there (you could have a
multi-arch system installed, in which case your pole2tm would run fine)
Running
$ readelf -l mapping/taipower/pole2tm | grep "Requesting program
interpreter:"
will show you the program that it is trying to run, which is likely to
be missing.
[In some cases you may also receive that message when it's one of the
dependencies (libraries) that is missing]
The problem is exactly the same as if you made a shellscript with a
shebang pointing to a missing binary.
In fact, dash does just that:
$ dash -c "./foo"
dash: 1: ./foo: not found
bash manages to provide a slightly more helpful error message:
$ bash -c "./foo"
bash: ./foo: /bin/missing: bad interpreter: No such file or directory
> Anyway, perhaps somebody could submit a kernel bug, telling them to
> somehow make bash, etc. look less bad, by a clearer error message, as I
> suppose bash cannot always catch such cases, to make a better error
> message.
The kernel only returns an error code, jidanni. Which is the right one,
as there is a missing file.
I agree it's confusing, though, as the message provided is the same as
if the program itself was missing, which is obviously not the case.
> In fact maybe bash could catch it (expensive?):
>
> First "stat" the file.
> If it doesn't exist bash should make its own message
> bash: /tmp/abce: No such file or directory
> If it does, then bash should be prepared to catch the kernel's message
> (which is referring to a *different* file, which yes, actually does not
> exist.)
> Whereupon bash could make a better error message.
bash is already stating it after the exec fails (as part of the fallback
code to see if it should manually run a shebang, I think).
You could place a different message there.
I don't think it should be parsing the ELF file just for this cosmetic
point (additionally, it might be in another format, such as PE, the
kernel may support many formats, see what people do with binfmt_misc
https://en.wikipedia.org/wiki/Binfmt_misc )
However, it would be helpful if it changed the to something a bit
different, such as
bash: mapping/taipower/pole2tm: missing file when executing existing
file (bad interpreter?)
The actual message would not be as important as providing a different
error message that is able to point people the right path, rather than
leaving them scratch their head on the seemingly false error provided.
Re: set -e ignored in subshell if part of command list
On 11/13/19 10:59 AM, Shaun Crampton wrote: > But the commands in the subshell execute inside a different shell > execution context so they shouldn't have > their own set -e context (Section 2.12)? > > I don't see where the spec says that the subshell has to inherit the > and/or list-ness of the > parent context. Section 2.12 doesn't mention that as being one of the > things that a subshell inherits > (and unless I'm missing a good use-case, it seems like a pretty > useless thing to inherit in a subshell > or a function that happens to be called on the LHS of an and/or). You're trying to defend the behavior you *want* set -e to have, even though many people rely on set -e having the behavior it does, indeed, have. Why do you require that yet another behavior change be made, so that it is even harder to know what set -e will do across various shells, and across various *versions* of a shell? set -e already has more than enough exceptions to every single rule it ever had. It's a collection of inchoate nonsensical lexical rules. Don't use it, for all the reasons enumerated here: https://mywiki.wooledge.org/BashFAQ/105 Everyone will be much happier if they just don't use set -e, and, instead, implement actual real error handling that a) works, b) does what they expect in their own special snowflake case. -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: set -e ignored in subshell if part of command list
On 11/13/19 10:59 AM, Andrew Church wrote:
"The -e setting shall be ignored when executing the compound list following
the while, until, if, or elif reserved word, a pipeline beginning with the
! reserved word, or any command of an AND-OR list other than the last."
(from
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_25_03)
The subshell inherits this state (being part of an and-or list) from its
parent.
Is that really the intent of the requirement, though?
Yes.
The same section
states: "This requirement applies to the shell environment and each
subshell environment separately", which I read to mean that the rules
should be evaluated without consideration of any parent or subshell
environment other than the one in which the -e option is being applied.
Not quite. It means that the reasons a subshell (for instance) exits may
not be the same ones applied to the parent.
And the example:
set -e; (false; echo one) | cat; echo two
shows rule 1 ("The failure of any individual command in a multi-command
pipeline shall not cause the shell to exit")
OK. The "individual command" in this context is the subshell command. The
subshell command exits with a non-zero status, but that doesn't cause the
shell to exit. The -e setting isn't ignored in the subshell because it's
not in an and-or list.
not being applied within
the subshell, even though the subshell as a whole is an "individual
command in a multi-command pipeline". I don't see any suggestion that
the case of an AND-OR list in rule 2 should be treated differently, and
absent an explicit requirement one way or the other, I think the
expected behavior here would be that the behavior of the subshell is
independent of the subshell's context in the parent shell.
The "-e setting shall be ignored" part? Expectations aside, that's just not
how shells behave, and not the intent of the standard. This was discussed
pretty thoroughly back in 2009, and shell behavior reflects the consensus
from that discussion. As I said in another message, there was a proposal
for some stronger language ("-e is disabled and cannot be re-enabled when
executing...any command of an AND-OR list except the last" is another
version of the proposed language) but that was deemed unnecessary.
The relevant interpretation was http://austingroupbugs.net/view.php?id=52
but there's not much discussion there -- it was all on the mailing list.
--
``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: set -e ignored in subshell if part of command list
On 11/13/19 10:59 AM, Shaun Crampton wrote: But the commands in the subshell execute inside a different shell execution context so they shouldn't have their own set -e context (Section 2.12)? Why? That section says the only thing that changes in the subshell environment is signal dispositions. In fact, the example in the set builtin description explicitly assumes the subshell inherits the errexit setting. The only thing the standard requires here is that setting -e in the subshell doesn't change the parent's setting. But that's not exactly the point. The shell is "executing any command of an AND-OR list other than the last" so errexit is ignored. I don't see where the spec says that the subshell has to inherit the and/or list-ness of the parent context. Section 2.12 doesn't mention that as being one of the things that a subshell inherits (and unless I'm missing a good use-case, it seems like a pretty useless thing to inherit in a subshell or a function that happens to be called on the LHS of an and/or). "A subshell environment shall be created as a duplicate of the shell environment, except that signal traps that are not being ignored shall be set to the default action. " It's an exact duplicate of the shell environment. It's easier to list the exceptions rather than the long list of things it inherits (more than the list earlier in that section). In any event, it's how existing shells behave, and the standard is attempting to match existing practice. In fact, part of the proposed language from 2009, when this was debated at length, was "The -e option is ignored and cannot be enabled by any command run by these lists" but that was considered unnecessary. -- ``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: quote removal issues within character class
Thanks for the explanation. I didn't know any of these
Re: set -e ignored in subshell if part of command list
>"The -e setting shall be ignored when executing the compound list following
>the while, until, if, or elif reserved word, a pipeline beginning with the
>! reserved word, or any command of an AND-OR list other than the last."
>
>(from
>https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_25_03)
>
>The subshell inherits this state (being part of an and-or list) from its
>parent.
Is that really the intent of the requirement, though? The same section
states: "This requirement applies to the shell environment and each
subshell environment separately", which I read to mean that the rules
should be evaluated without consideration of any parent or subshell
environment other than the one in which the -e option is being applied.
And the example:
set -e; (false; echo one) | cat; echo two
shows rule 1 ("The failure of any individual command in a multi-command
pipeline shall not cause the shell to exit") not being applied within
the subshell, even though the subshell as a whole is an "individual
command in a multi-command pipeline". I don't see any suggestion that
the case of an AND-OR list in rule 2 should be treated differently, and
absent an explicit requirement one way or the other, I think the
expected behavior here would be that the behavior of the subshell is
independent of the subshell's context in the parent shell.
--Andrew Church
http://achurch.org/
Re: set -e ignored in subshell if part of command list
But the commands in the subshell execute inside a different shell execution context so they shouldn't have their own set -e context (Section 2.12)? I don't see where the spec says that the subshell has to inherit the and/or list-ness of the parent context. Section 2.12 doesn't mention that as being one of the things that a subshell inherits (and unless I'm missing a good use-case, it seems like a pretty useless thing to inherit in a subshell or a function that happens to be called on the LHS of an and/or). On Wed, Nov 13, 2019 at 3:07 PM Chet Ramey wrote: > > On 11/13/19 5:24 AM, Shaun Crampton wrote: > > > Bash Version: 5.0 > > Patch Level: 3 > > Release Status: release > > > > Description: > > I was trying to get a function to return early if a command > > fails by putting > > the body of the function in a subshell and using set -e inside > > the subshell. > > If I run a subshell on its own, this works, but when I try to > > combine it > > into a larger program, the set -e gets ignored. > > > > Repeat-By: > > Managed to boil it down to this smaller example: > > > > # On its own, subshell behaves as expected: > > $ ( set -ex; false; echo here ) > > + false > > > > # In a list, behaviour changes, "echo here" gets executed: > > $ ( set -ex; false; echo here ) && echo there > > + false > > + echo here > > here > > there > > The subshell command is part of an and-or list, so the -e is ignored for > that command: > > "The -e setting shall be ignored when executing the compound list following > the while, until, if, or elif reserved word, a pipeline beginning with the > ! reserved word, or any command of an AND-OR list other than the last." > > (from > https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_25_03) > > The subshell inherits this state (being part of an and-or list) from its > parent. > > > > > # If the subshell is executed in the background, it works > > $ ( set -e; false; echo here ) & pid=$!; wait $pid && echo there > > In this command, the subshell is not part of an and-or list. > > -- > ``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: set -e ignored in subshell if part of command list
On 11/13/19 5:24 AM, Shaun Crampton wrote: Bash Version: 5.0 Patch Level: 3 Release Status: release Description: I was trying to get a function to return early if a command fails by putting the body of the function in a subshell and using set -e inside the subshell. If I run a subshell on its own, this works, but when I try to combine it into a larger program, the set -e gets ignored. Repeat-By: Managed to boil it down to this smaller example: # On its own, subshell behaves as expected: $ ( set -ex; false; echo here ) + false # In a list, behaviour changes, "echo here" gets executed: $ ( set -ex; false; echo here ) && echo there + false + echo here here there The subshell command is part of an and-or list, so the -e is ignored for that command: "The -e setting shall be ignored when executing the compound list following the while, until, if, or elif reserved word, a pipeline beginning with the ! reserved word, or any command of an AND-OR list other than the last." (from https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_25_03) The subshell inherits this state (being part of an and-or list) from its parent. # If the subshell is executed in the background, it works $ ( set -e; false; echo here ) & pid=$!; wait $pid && echo there In this command, the subshell is not part of an and-or list. -- ``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: quote removal issues within character class
On 11/8/19 4:50 PM, Oğuz wrote:
v=foo
echo ${v#[[:"lower":]]}
should print oo, but it prints foo instead. This is reproducible on bash
4.4
Plus
case foo in (*[![:"lower":]]*) echo bar; esac
prints bar, while
The idea is that at this point in command processing, quote removal hasn't
been performed. According to the abstract model the shell uses for word
expansions, that means the double quotes are still present in the word, and
`"lower"' is not the same as `lower'.
There was a recent extensive discussion of this and other points on the
posix mailing list, and, as kre said, the committee has decided to make
this a special case. I changed this about a month ago, and the chage is
in the devel branch.
case foo in (*[![":lower":]]*) echo bar; esac
doesn't print anything. And this is only reproducible on bash >5.0
This is an invalid character class, since a class has to begin with the
two-character sequence `[:'. The intervening double quote causes that test
to fail (this case is not so special, it seems). The first `]' then
terminates the bracket expression, so th string has to contain at least
a `]' to have a possibility of matching.
--
``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/
set -e ignored in subshell if part of command list
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-LQgi2O/bash-5.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wno-parentheses -Wno-format-security uname output: Linux shauns-laptop 5.1.16-050116-generic #201907031232 SMP Wed Jul 3 12:35:21 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.0 Patch Level: 3 Release Status: release Description: I was trying to get a function to return early if a command fails by putting the body of the function in a subshell and using set -e inside the subshell. If I run a subshell on its own, this works, but when I try to combine it into a larger program, the set -e gets ignored. Repeat-By: Managed to boil it down to this smaller example: # On its own, subshell behaves as expected: $ ( set -ex; false; echo here ) + false # In a list, behaviour changes, "echo here" gets executed: $ ( set -ex; false; echo here ) && echo there + false + echo here here there # If the subshell is executed in the background, it works $ ( set -e; false; echo here ) & pid=$!; wait $pid && echo there [1] 26219 [1]+ Exit 1 ( set -e; false; echo here )
Re: loadable sleep exits immediately
On 11/12/19 9:15 AM, p.debru...@unilogic.nl wrote: Bash Version: 4.4 Patch Level: 23 Release Status: release Description: The loadable sleep function seems to exit almost immediately in some specific cases. It's getting interrupted by SIGCHLD. It's fixed in bash-5.0 by blocking SIGCHLD in the appropriate function, using select or pselect. -- ``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/
