Looks like that’s actually dependent on the shell. Works in bash, but not zsh:
zsh: exec format error: ./true
It should work on any posix-compatible shell.
specifically “Command Search and Execution” § 1.d.i.b:
If the execl() function fails due to an error equivalent to the [ENOEXEC] error defined in the System Interfaces volume of POSIX.1-2008, 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.
If my implementation of “true” doesn’t work in a given shell it is clear that it is only because that shell is not POSIX compatible.
It is arguable that posix conformance here is a good thing though IMO.
zsh is in fact returning an exit code of 126, just as specified in that paragraph. Unless the specification further defines that an empty file should be considered a text file, zsh is compliant, and you can’t depend on an empty file exiting successfully in POSIX.
Check out sbase and ubase for the suckless approach on the core utilities.
Neat! I’ve done non-golfed, but tiny when I was learning C. (I shamelessly ripped the filecopy function from K&R, and reimplemented cat and wc similarly, but not exactly like the book.
Also asmutils for when you really want ls written in bare x86 assembly for some reason.
Nice! I started reimplementing cat in various languages to get me used to them. Great little intro project for a language, makes you go find out about IO, CLI handling, etc. Elixir, Ruby, Golang, Swift, and to check they all behave the same, cat_linter
Maintaining all the behaviour is interesting for sure.