Zsh – Difference Between /usr/bin and /bin Locations

In the 21st century, especially if you're targeting machines that are likely to have bash or zsh, you can count on type being available. (It didn't exist in extremely old unices, as in, from the 1970s or early 1980s.) You can't count on its output meaning anything, but you can count on its returning 0 if there is a command by that name and nonzero otherwise.

which isn't standard and is unreliable in practice. type is the recommended alternative. whereis suffers from the same problems as which and is less common. whence is specific to ksh and zsh.

When that's possible, it would be more reliable to test the existence of a command and test whether its behavior looks reasonable. For example, test the presence of a suitable version of bash by running bash -c 'somecommand', e.g.

# Test for the `-v` operator (which appeared in bash 4.2)
if bash -c 'test -v HOME' 2>/dev/null; then …

Today you can count on almost everything in the Singe UNIX specification version 2 (except for exotic stuff like Fortran and SCCS, which are optional anyway). You can count on most of version 3, too, but this isn't completely implemented everywhere yet. Version 4 support is sketchier. If you're going to read these specs, I recommend reading version 3, which is a lot more readable and less ambiguous than version 2.

For examples as to how to detect system specificities, look at autoconf and at configure scripts of various software.

See also Resources for portable shell programming for more tips.

It's a feature, not a bug. ?

As it says in Zsh's manual, section "Errors":

Certain errors are treated as fatal by the shell: in an interactive shell, they cause control to return to the command line, and in a non-interactive shell they cause the shell to be aborted. […]

Fatal errors found in non-interactive shells include:

• […]
• File generation errors where not caught by the option BAD_PATTERN
• […]
• File generation failures where not caused by NO_MATCH or similar options.

As for the reasoning behind it, I found this email exchange in the Zsh mailing list archives:

In other shells this is implemented in a very simple way, if the wildcard can be expanded, then it is expanded, otherwise an asterisk is sent as an argument to the application.

Yes, other shells do it that way, but that has its downsides. For instance, if you run "touch *,c" it's better to get "no match" rather than creating a useless *,c file. Or if you type a command like this: "rsync -avP *.html *.shmtl *.php host:/dest/" (note the misspelling), it is better to get a "no match" error right away than to get a single open-error embedded in all the output that you then have to figure out at the end of the transfer. I much prefer to simply put single quotes around any wild-carded file names that should not be expanded rather than to configure the shell to include a wildcard that didn't match anything. YMMV, of course, but if you give it a try, you may find that you come to prefer it as well.