4 ms·

My coworker said the same thing. But now that you know, will it give you pause? Shell has tricky and arcane corners that are best to avoid, but you still do be

My coworker said the same thing. But now that you know, will it give you pause? Shell has tricky and arcane corners that are best to avoid, but you still do better to know about them, lest they bite you (shellcheck helps). I don't think that "I/O redirection can precede the command name" is particularly tricky or arcane. What bothers me is that it doesn't work with loops: <input.txt while read -r line; do thing; done # error while read -r line; do thing; done <input.txt # fine The shell's grammar is quite a thing.

cellularmitosis 2y ago
“Subsetting” a language is a useful practice. Consider the set of language features someone has to know in order to understand your code. If you can make that set smaller (without unreasonably sacrificing functionality), you lower the barrier to entry. More people can read your code. The typical retort I hear is “but it’s just this one feature, how hard is it to learn just one feature?” But you’re only considering your favorite feature. To the casual code reader, it isn’t just that one feature, it’s everyone else’s favorite obscure feature as well. Using cat makes your code readable to a wider audience. Using cat has real upside with no downside. Forcing your readers to learn more shell syntax has real downside with no practical upside.
- MathMonkeyMan 2y ago
  You make good points. The only part I disagree with is "forcing your readers to learn more shell syntax." Who am I to say what the reader does or doesn't know about the shell? I don't even know what I don't know about the shell. The language is a minefield. I always have to look up the rules for how prefix/suffix substitution works, or the finer points of heredocs, or just when exactly something should be quoted, or the precedence of boolean operators, or the difference between "[" and "test", or ... Yes, let's be considerate and not use these features. But then we must agree on the specifics of the subset. If we're going to do that, then let's just learn the language proper instead. Or, avoid shell scripts entirely. Maybe there's an analogy with writing prose. I _could_ use rare words and uncommon syntax, but the modern style is a better approach. Is "abstruse" a rare word? Will a reader be frustrated to necessarily learn about split infinitives? What about I/O redirection at the beginning of a command?
- Brian_K_White 2y ago
  Readability is a concern, but it is only one concern among a bag of conflicting concerns, and it is meaningless to make decsions based on it before deciding the priority of all concerns. Sometimes the readability is the most important feature and all other concerns can be compromised or sacrificed to readability. But for me, usually not. As far as I'm concerned that is limited to training materials and showing your work in math exams. The rest of the time it's merely a goal after all other goals, ie you don't want things to be actually obfuscated, all else being equal.

cellularmitosis 2y ago

“Subsetting” a language is a useful practice. Consider the set of language features someone has to know in order to understand your code. If you can make that set smaller (without unreasonably sacrificing functionality), you lower the barrier to entry. More people can read your code. The typical retort I hear is “but it’s just this one feature, how hard is it to learn just one feature?” But you’re only considering your favorite feature. To the casual code reader, it isn’t just that one feature, it’s everyone else’s favorite obscure feature as well. Using cat makes your code readable to a wider audience. Using cat has real upside with no downside. Forcing your readers to learn more shell syntax has real downside with no practical upside.

MathMonkeyMan 2y ago
You make good points. The only part I disagree with is "forcing your readers to learn more shell syntax." Who am I to say what the reader does or doesn't know about the shell? I don't even know what I don't know about the shell. The language is a minefield. I always have to look up the rules for how prefix/suffix substitution works, or the finer points of heredocs, or just when exactly something should be quoted, or the precedence of boolean operators, or the difference between "[" and "test", or ... Yes, let's be considerate and not use these features. But then we must agree on the specifics of the subset. If we're going to do that, then let's just learn the language proper instead. Or, avoid shell scripts entirely. Maybe there's an analogy with writing prose. I _could_ use rare words and uncommon syntax, but the modern style is a better approach. Is "abstruse" a rare word? Will a reader be frustrated to necessarily learn about split infinitives? What about I/O redirection at the beginning of a command?
Brian_K_White 2y ago
Readability is a concern, but it is only one concern among a bag of conflicting concerns, and it is meaningless to make decsions based on it before deciding the priority of all concerns. Sometimes the readability is the most important feature and all other concerns can be compromised or sacrificed to readability. But for me, usually not. As far as I'm concerned that is limited to training materials and showing your work in math exams. The rest of the time it's merely a goal after all other goals, ie you don't want things to be actually obfuscated, all else being equal.