On 2016-08-22 19:28:58 +0200, Jakub Wilk wrote:
> * Vincent Lefevre <vinc...@vinc17.net>, 2016-02-29, 20:17:
> > $ /bin/dash -c tadd.exe
> > ./tadd.exe: 1: ./tadd.exe: MZ��¸@º´: not found
> > ./tadd.exe: 2: ./tadd.exe: : not found
> > ./tadd.exe: 1: ./tadd.exe: @.bss : not found
> > ./tadd.exe: 1: ./tadd.exe: .textd*,: not found
> > ./tadd.exe: 3: ./tadd.exe: JPL2@�.idata: not found
> > ./tadd.exe: 3: ./tadd.exe: u
> > : not found
> > ./tadd.exe: 4: ./tadd.exe: ~@0�.CRT4�@0�.tls: not found
> > ./tadd.exe: 5: ./tadd.exe: @B/81P: not found
> > ./tadd.exe: 13: ./tadd.exe: Syntax error: Missing '}'
>
> This is standards-compliant behavior. SUSv3[0] reads:
> > If the execve() function fails due to an error equivalent to the
> > [ENOEXEC] error defined in the System Interfaces volume of IEEE Std
> > 1003.1-2001, the shell shall execute a command equivalent to having a
> > shell invoked with the pathname resulting from the search as its first
> > operand, with any remaining arguments passed to the new shell, except
> > that the value of "$0" in the new shell may be set to the command name.
> > If the executable file is not a text file, the shell may bypass this
> > command execution.
This is not because it is a standards-compliant behavior that it is
acceptable for data integrity. Things have evolved. If this were
decided again nowadays, it would probably not just a "may" (I suppose
that the intent was to allow a script working on included binary data,
such as compressed data, but even in such a case, the first word
would not contain non-printable characters). Nowadays one needs to
take into account:
* Executables for other platforms may be more common than in the
past.
* Security is more important (trying to execute binary data as a
shell script might be an attempt to exploit a vulnerability).
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
