Hacker News Reader

Comment by nerdponx | Hacker News Reader

Was this behavior inherited from Unixes past? It seems like it'd be better if shells just returned the error back to the user.

View on HN

From 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/V... [2] https://unix.stackexchange.com/a/373229

Thanks!

Does POSIX define what a "text file" is?

If it does, I never found it.

> 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...

Does an empty file contain characters? That first sentence seems like it contradicts itself.

I think the implication is that empty files are considered text files.

Yes. It contains zero characters.

An empty file actually contains zero of everything in the universe.

The idea behind the definition is that it defines set of files that will not trigger various bugs in traditional unix text tools implementations (ie. various variants of not checking the fgets() return value).

Shells return exit codes, not typed error values. What kind of output would you expect from the shell, exactly?

Status 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.

I 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).

I'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.)

Okay, yeah. That could be useful. Seems POSIX forces the behavior described in the blog post. Time to change the standard!

Yeah, it predates the addition of shebang support in BSD.

Reply on news.ycombinator.com