5 ms·
Was this behavior inherited from Unixes past? It seems like it'd be better if shells just returned the error back to the user.
by nerdponx 5y ago
Was this behavior inherited from Unixes past? It seems like it'd be better if shells just returned the error back to the user.
- deleted 5y ago[deleted]
- fuzzybear3965 5y agoShells return exit codes, not typed error values. What kind of output would you expect from the shell, exactly?
- nerdponx 5y agoStatus 129 or something else outside the usual range, plus a message that the file was not a valid ELF and also has no shebang, therefore cannot be executed.
- fuzzybear3965 5y agoI always thought that 128+ are for (shell-spawned) processes and 0-127 are for shell. But, apparently POSIX requires this behavior for empty files - we need to amend the standard, first (or fail to comply, muahahaha).
- deathanatos 5y agoI'd expect the same as any other failure from execv(2). Something like, zsh: Exec format error: empty-file (last command returned 127.) (127 is the exit status for other failures, so I've used it here. The second line is intended to be part of my PS1, the first zsh's normal reporting. The string used here is what I get from perror() for that code.)
- fuzzybear3965 5y agoOkay, yeah. That could be useful. Seems POSIX forces the behavior described in the blog post. Time to change the standard!
- kragen 5y agoYeah, it predates the addition of shebang support in BSD.
- gnarula 5y agoFrom POSIX [1][2]: > If the execl() function fails due to an error equivalent to the [ENOEXEC] error defined in the System Interfaces volume of POSIX.1-2017, 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. In this case, it shall write an error message, and shall return an exit status of 126. [1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01 https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V... [2] https://unix.stackexchange.com/a/373229 https://unix.stackexchange.com/a/373229
- nerdponx 5y agoThanks! Does POSIX define what a "text file" is?
- aidenn0 5y agoIf it does, I never found it.
- michaelhoffman 5y ago> A file that contains characters organized into zero or more lines. The lines do not contain NUL characters and none can exceed {LINE_MAX} bytes in length, including the <newline> character. Although POSIX.1-2017 does not distinguish between text files and binary files (see the ISO C standard), many utilities only produce predictable or meaningful output when operating on text files. The standard utilities that have such restrictions always specify "text files" in their STDIN or INPUT FILES sections. https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...
- macintux 5y agoDoes an empty file contain characters? That first sentence seems like it contradicts itself.