Re: Misleading error when attempting to run foreign executable

[Alex fxmbsw7 Ratchev]

the mv a old new looks like it can be achieved by cgroups freeze [i only
have hears so] and ye its not portable

if choosen to somehow freeze it, i dunno, transparently somehow, for
letting changes happen

btw on my secondlast bash.git.devel build it ended up with some binary that
also produced via debian chroot on aarch64 phone on termux no such file
when executing, on ldd the ld linux aarch doesnt show up, in debians ldd it
appears

well devel bugs

On Mon, Oct 11, 2021, 19:49 Robert Elz <kre@munnari.oz.au> wrote:

>     Date:        Mon, 11 Oct 2021 11:00:54 -0400
>     From:        Chet Ramey <chet.ramey@case.edu>
>     Message-ID:  <45ecd950-9e9b-553b-132b-04d1dcfad59a@case.edu>
>
>   | When execve returns this error for what is a clearly invalid reason,
>
> The problem is that sometimes it will probably be an invalid reason
> (that's where the race conditions can matter, that the file was there
> when it was checked doesn't mean it is still there now, so the reason
> might be valid, and I'm not sure it is really worth another stat() to
> find out - and even if the stat() is done and that says the file exists,
> the exec attempt might just have happened in the middle of a
>          mv a a.old; mv a.new a
> sequence).
>
> Other times (like exec of a /path/to/file) you won't have any idea at
> all in advance that the file apparently exists, so the same underlying
> issue would generate different messages in different circumstances if you
> try and handle the case where you believe error to be invalid (unless you
> check after every ENOENT -- even in the /path/to/file case).
>
> Better to get the OS fixed (those kinds of fixes tend to seem less
> urgent when applications work around them instead of simply complaining).
>
> But that said:
>
>   | it's not unreasonable that the shell help.
>
> it isn't unreasonable - as I said (in the postscript) "even if bash
> (or some other process) were to attempt to examine the file after an exec
> failure to generate a nicer message...", kind of indicating that it
> wouldn't be a wrong thing to do, just certainly not required.
>
> kre
>
>
>