71–80 of 113 posts
Earlier quoted context omitted.
If I saw It would give me pause. If I saw cat file | grep ... I would understand it instantly, as would any other Unix user. Therefore the latter is better code.
Or just use grep file?
Earlier quoted context omitted.
If I saw It would give me pause. If I saw cat file | grep ... I would understand it instantly, as would any other Unix user. Therefore the latter is better code.
The problem is that according to this argument `cat` should never be used for the thing it was designed for, because if you use it with more than one argument, it would give most Unix users pause, but if you saw it with only one argument they would understand it instantly. The whole point of the "never use cat" Unix advice is a war between instrumentalism and design purism. Should things be known mostly for what they…
Does anyone take the "don't use cat" stuff seriously?
It’s a hump curve with virtue signalling in the middle, like a thousand other things in life. Noob+naive : use cat because don’t know better. Experienced+smart ass : use shell direction to distinguish oneself from noobs. Older+wiser : use cat again because it flows left to right, isn’t bash specific like “ …but mostly because it doesn’t make one come across as a nit picking asshole to the expensive noobs you’ve just…
Earlier quoted context omitted.
If I saw It would give me pause. If I saw cat file | grep ... I would understand it instantly, as would any other Unix user. Therefore the latter is better code.
` idiomatic , but when I see it I think it makes perfect sense. It puts the pipeline "in order", starting with redirection from the input (and presumably ending with redirection to the output, if not stdout).
`at least visually gives off the impression that it's sending the command's output to the left (changing the prompt, perhaps?)
Earlier quoted context omitted.
If I saw It would give me pause. If I saw cat file | grep ... I would understand it instantly, as would any other Unix user. Therefore the latter is better code.
The problem is that according to this argument `cat` should never be used for the thing it was designed for, because if you use it with more than one argument, it would give most Unix users pause, but if you saw it with only one argument they would understand it instantly. The whole point of the "never use cat" Unix advice is a war between instrumentalism and design purism. Should things be known mostly for what they…
if you prefer to use cat just to read your pipeline from left to right, you can just start your command with file redirection. It doesn't have to be at the end of the command. this works in bash too, but if you're using zsh, there're a couple of nice shortcuts on it's own works as more file and > file ... ... ^D allows you to put something into the file quickly without firing up the editor. Though > file will give yo…
It’s shell specific though, just like using FOO=bar cmd prefixing to make environment changes. Better to use env(1) and keep everything rooted in Unix processes rather than shell syntax, imho. # bashisms
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
So is FOO=bar cmd.
(I guess it is shell-specific if you include csh in the game, but then what isn't...)
Does anyone take the "don't use cat" stuff seriously?
It's more of a symptom of someone who doesn't understand what's actually going on, i.e. cargo cult scripting. Specifically, it indicates some combination of: 1. isn't aware of processes/pipes 2. isn't aware of cat's "primary" functionality 3. isn't aware of shell input redirection 4. isn't aware that shell input redirection can be put before the command
Earlier quoted context omitted.
The problem is that according to this argument `cat` should never be used for the thing it was designed for, because if you use it with more than one argument, it would give most Unix users pause, but if you saw it with only one argument they would understand it instantly. The whole point of the "never use cat" Unix advice is a war between instrumentalism and design purism. Should things be known mostly for what they…
So `abc | ` would write the stdout of `abc` to the file? Meaning that if you forgot to mark your script as executable, you’ve now lost all your work? I think `abc > ` works perfectly fine and pipes don’t need to substitute this behavior.
For an instance where there are thousands of bash scripts out there that work around a case where `abc >file` does not work, consider the times when you want to write to a file which you don't have write permissions to, with sudo. my favorite way to do this is with `tee` but I have also seen others: but `>file` is not one of them! Because it's emphatically not part of the algebra of the rest of the shell; the rest of the shell is written in pipes, this one command says "I'm going to make your pipeline terminate, this step will be un-pipeable."
For another example where the algebra doesn't consistently handle the whole system, consider that in a normal language you would consider writing a function which returns a value and also prints debug logs to the process's stdout. Bash can't do this on its own, you have to figure out which /dev/tty is attached to the process and then write your debug log to that TTY, and then your script probably fails in interesting ways when it itself is redirected to a file and there is no TTY that it is attached to anymore...
Does anyone take the "don't use cat" stuff seriously?
If by that you mean religiously avoiding cat at all cost, no. If by that you mean thinking about what you are actually doing on your commandline I say I do. Which makes me realize that yes, cat is more often than not redundant unless you are actually outputting the concatenation of multiple files.
if you prefer to use cat just to read your pipeline from left to right, you can just start your command with file redirection. It doesn't have to be at the end of the command. this works in bash too, but if you're using zsh, there're a couple of nice shortcuts on it's own works as more file and > file ... ... ^D allows you to put something into the file quickly without firing up the editor. Though > file will give yo…
It’s shell specific though, just like using FOO=bar cmd prefixing to make environment changes. Better to use env(1) and keep everything rooted in Unix processes rather than shell syntax, imho. # bashisms
I find myself googling "OpenGroup shell command language" pretty often to check this sort of thing.