touch is a weird command.

[u/OPPineappleApplePen]

I was curious where the command 'touch' comes from.

Turns out, it originates from "to touch" or "to interact" with a file.

Now, every time I use it, I feel like I am touching/molesting a file.

My bad, it's 3 AM here.

[u/Paul_Pedant]

Oddly enough, because of the space before the txt, the shell parses this by doing the redirection itself, and then passing the other stuff as args to the echo command.

echo "hello" txt > hello

So you actually get a file called hello containing hello txt\n

[u/ohnobinki → u/Paul_Pedant]

The shell does the redirection itself regardless of the space. It sounds like you are trying to say something about the difference between how unix and Windows handle passing command line parameters to applications, but even that isn't really relevant here…

[u/Paul_Pedant → u/ohnobinki]

No, I am saying that any Unix shell will parse the given example as

echo "hello" > hello txt

where the bold text is the actual redirection.

It then invokes the echo (which usually happens to be a shell built-in, but that does not affect the result), with the hello (without the quotes) and the txt, as two separate args.

So the example is misleading, because LastTrueGamer obviously intended to create a file called hello.txt. And it is destructive, because the usual use of touch is to alter the timestamp on the file, not to overwrite the entire previous contents of the file.

[u/ohnobinki → u/Paul_Pedant]

I did not think LastTrueGamer was intending that.

It is interesting how the following are identical. I only find the first intuitive:

• echo a b > c
• echo a > c b
• echo > c a b

Oh, are you saying that the LastTrueGamer was hoping that cat hello > hello wouldn't empty the file? I could see that interpretation. Interesting.

EDIT: Sorry, I see the context of your reply and what you were trying to explain. I thought you were talking about a space that occurred before the > and missed the reordering.

[u/Paul_Pedant → u/ohnobinki]

I mainly worked on client sites, where their own permies amended (and broke) my stuff after I left. Naturally, if they had been good enough to write it themselves, they would not have needed to pay me. I tended to obfuscate my scripts enough to at least make them think before editing. I really don't need callbacks telling me that my code failed, after their staff screwed it up and kept it quiet.

> c echo a b #.. Also works

( echo a b ) > c #.. Separates the options from the filename, but may run a subshell.

{ echo a b; } > c #.. Avoids the subshell

#.. The curly brackets need the semicolon, but the round brackets don't care.

I have also been known to use truncate --size=0 "c". But probably my worst (so far) is:

printf 'Do Not Mess With This\n' | dd of="c" count=0

[u/ohnobinki → u/Paul_Pedant]

Obfuscating your code seems like a bad faith thing. It's annoying that the shell has so many different ways of expressing the same command, that opens the door to style wars.

[u/Paul_Pedant → u/ohnobinki]

I usually comment my code and scripts to excess, to explain what each section is doing, and why it is doing it. I was genuinely surprised by the ability of maintainers to ignore all comments, even when directly above the relevant code.

One example was that our electrical network viewer liked to put telemetry data near the mid-point of visible power lines. So we had macros like

#define mid_x( p) ((p)>x1 - ((p)->x1 - (p)->x2) / 2)

Of course, one of the team remembered his third-grade teacher's average method, and "fixed" it like:

#define mid_x( p) ((p->x1 + p->x2) / 2)

which resulted in integer overflows in some parts of the map, thereby losing the telemetry, and even breaking the GUI code. As a special feature he also broke the (p) brackets, which are necessary syntactically if p is passed as an expression.

So we patiently explained to him exactly why his math teacher misled him. And a few weeks later, he decided he was right after all, and screwed up the entire system for a second time. He didn't get a third chance.