I'm surprised that file> command isn't the preferred idiom. Does that mean something else?

Yes, that would write to a file called "command". So the correct way to write that would be:

    command > file

https://www.gnu.org/software/bash/manual/html_node/Redirecti...

That would execute the command `file` and put the output into the file `command`.

Oh, now I re-read it - of course! Hah.

Is `<file` shorthand for `cat file`, or is that only true when used in a sub-shell?

I guess it's equivalent to `: <file` i.e. hooking up the stdin of the no-op command.

Doesn't seem to be the case. For example, `< file cat` shows the file, whereas `: < file cat` or `: < file | cat` does nothing.

Not sure what's surprising you in those snippets. `:` itself is a command and it does nothing with its arguments or stdin.

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...

I know. The only thing surprising me is your previous claim that `< file` is equivalent to `: < file`.

My interpretation of sgarland's question was that he meant `<file` being the entirety of the statement, i.e. typing only that at a shell prompt and pressing return.

Ah. Now I understand where the misunderstanding was. It confused me that we were talking about redirection as a replacement for useless use of cat.

Yep I can appreciate the misunderstanding. For completeness of the discussion, I think where sgarland mentioned a sub-shell, he was possibly referencing the Bashism `$(<` detailed on this page https://www.gnu.org/software/bash/manual/html_node/Command-S... in addition to what I called a "statement" above.

Correct, that’s what I had in mind.

No, `< file command` is completely equivalent to `command < file`.

In that fun way that shells are, for bare redirection it depends.

In bash/ksh, it matches frou_dh's explanation. In zsh, it depends on how you've set the various *NULLCMD options and parameters. In csh, it is an error.

Even in zsh, when configured to behave like `cat file` it still doesn't quite do that as it won't concatenate files as it only passes the first shell word following the `<` to `cat`(or whatever you've set NULLCMD to). Guess that means you could be evil by making a wrapper that allows weird Unicode separators to pass multiple files in one word ;)

Because I hate myself I guess, I use zsh as my interactive shell, but generally write scripts for bash. The latter is mostly for portability (although with Macs stuck on 3.2 unless updated manually, that’s less true over time), and also because shellcheck doesn’t work on zsh.

This means I get to remember an increasingly unfortunate amount of differences. I’ll add this one to the pile, thanks.

I've mentioned this in previous posts here, but I write zsh scripts utilising all the extras that zsh gives(alternate form syntax, extensive extended globbing, zsh module support for extra functionality). It sounds stupid but it makes it really obvious that what you're writing isn't a generic shell script, and you can forgo having to think too much about whether something will work in modern bash, or MacOS pre-GPL3 bash, or {b,d,k,z}ash as /bin/sh symlink.

I definitely get the argument about shellcheck though, it would be nice if it supported zsh.

That’s fair. I wrote a script at work recently for zsh that relied on some of its niceties, like glob qualifiers. The reason for using zsh was we only use Macs, so it was reasonable to assume everyone would have a decently modern version of zsh available.

It definitely looks foreign, but then, so does parameter substitution in bash or zsh. There are shell scripts, and then there are those that make you break out the man pages to figure out what they’re doing.

I'll often commit 'useless use of cat' there for three reasons:

1) Muscle memory

2) Often when I don't I end up needing two files later

3) It annoys merlyn (Randal Schwartz)