tl;dr: echo this is a >correct command redirects output “this is a command” to file correct.

Few days ago, I saw a command about using tr for random text/password generation:

< /dev/urandom tr -dc A-Za-z0-9

At first glance, I thought there must be something wrong with the position of that redirection < /dev/uransom, but no, it’s a syntactically correct Bash Simple Command.

According to Simple Commands, you can put redirections anywhere within Simple Command:

A simple command is the kind of command encountered most often. It’s just a sequence of words separated by blanks, terminated by one of the shell’s control operators.

Also, a little more in plain English from Redirections:

The following redirection operators may precede or appear anywhere within a simple command or may follow a command.

If I hadn’t skimmed over that post — I didn’t interest in its content — then I would never know about this. I may have open bash(1) for more than one hundred times, but I hadn’t noticed such syntax.

I also believe that I am not the only one who didn’t know about this, there is no syntactical representation in the bash(1), you have to read the text to know about it. Moreover, that blog post is the only one I have ever seen putting redirection before a command. That being said, 100% of commands I had ever seen, they all put redirection at the end of a Simple Command.

We are accustomed to that convention and have never thought out-of-the-box, somehow programmed ourselves to think that’s the only valid syntax for using redirection. At least, I was one of them.

I could actually see myself using this in future — putting redirection at beginning, not in the middle — it might be helpful when you need to change command’s last argument to test out something which also accepts an input redirection.

echo "what's funky?"
echo this is >funky really funky
cat <funky -

what's funky?
this is really funky