3 ms·

Totally with you there. "Useless use of cat" is usually good practice, not bad. It's clearer - the structure indicates right at the front what it is going to d

by cannam 4y ago

Totally with you there. "Useless use of cat" is usually good practice, not bad. It's clearer - the structure indicates right at the front what it is going to do, namely read a file and pass it through a pipeline. There is no need to read ahead to find out what the source material is. It's safer - "cat" is a read-only operation, once you've written that command up-front there is no longer a risk of overwriting the original file with a typo in the rest of the pipeline. It's simpler to construct and nicely orthogonal to the rest of the pipeline - you can write the "cat" and then season the rest to taste (as you suggested). I will occasionally remove cat from a very heavily-used loop, but as a default style it's fine.

pmoriarty 4y ago
"It's safer - "cat" is a read-only operation, once you've written that command up-front there is no longer a risk of overwriting the original file with a typo in the rest of the pipeline." With zsh you can prevent such accidents by "setopt NO_CLOBBER" The result is that if you "foo > bar" and "bar" exists, zsh will refuse to overwrite "bar" and give you an error: "zsh: file exists: bar" This makes constructs such "foo < bar > baz" perfectly safe, because accidentally typing "foo > bar > baz" will error out when "bar" (or "baz") already exists. (PS: if you want to force zsh to overwrite the file even when NO_CLOBBER is set you can "foo >| bar")
- lelanthran 4y ago
  That doesn't help with sed -i and similar things. Zsh stops redirection errors, it won't help even if cat is in the front.
  - pmoriarty 4y ago
    "That doesn't help with sed -i and similar things." Can you give an example? I don't know what you mean. "Zsh stops redirection errors" Which is what the post I was answering to was complaining about, wasn't it? "it won't help even if cat is in the front" Why not? "cat > foo" will error out if "foo" exists and NO_CLOBBER is set.
    - lelanthran 4y ago
      >> "That doesn't help with sed -i and similar things." > Can you give an example? I don't know what you mean. Sure. The first line below is dangerous no matter what zsh does to save you from yourself. The second line is safe no matter which shell you are using, and no matter what other commands are in the pipeline: sed $SEDOPTIONS "s/$SEARCHTERM/$REPLACEMENT/g" $FILENAME cat $FILENAME | sed $SEDOPTIONS "s/$SEARCHTERM/$REPLACEMENT/g" >> "Zsh stops redirection errors" > Which is what the post I was answering to was complaining about, wasn't it? That's not how I interpreted "a typo in the rest of the pipeline." Sure, the typo could be a redirection. It could also accidentally set $SEDOPTIONS in the example above to include the '-i' flag. >> "it won't help even if cat is in the front" > Why not? "cat > foo" will error out if "foo" exists and NO_CLOBBER is set. Yes, "cat > foo" will error out, but "cat $FILENAME | sed -i "s/a/b/g" $FILENAME" won't.
      - pmoriarty 4y ago
        Yes, in-place editing with tools like sed is dangerous. But, in your own example you have a useless use of cat: cat $FILENAME | sed $SEDOPTIONS "s/$SEARCHTERM/$REPLACEMENT/g" could be replaced with: sed $SEDOPTIONS "s/$SEARCHTERM/$REPLACEMENT/g" < $FILENAME
        lelanthran 4y ago
        Well, that's the whole point of the useless use of cat - in the non-cat example you gave, making a typo at the end of the command destroys my data. With the useless use of cat, that is no longer possible even if there is a typo in the SEDOPTIONS.
- Beltalowda 4y ago
  > With zsh you can prevent such accidents by "setopt NO_CLOBBER" Don't even need zsh for this; "set -C" will do the same in any POSIX shell. >| is also in POSIX. csh supports it as well.
yrro 4y ago
> It's clearer - the structure indicates right at the front what it is going to do, namely read a file and pass it through a pipeline. There is no need to read ahead to find out what the source material is. I only found this out recently, but this works perfectly fine: $ < /some/file awk ... You're not wrong though, where cat improves readability there's no harm in using it.

by cannam 4y ago

pmoriarty 4y ago

"It's safer - "cat" is a read-only operation, once you've written that command up-front there is no longer a risk of overwriting the original file with a typo in the rest of the pipeline." With zsh you can prevent such accidents by "setopt NO_CLOBBER" The result is that if you "foo > bar" and "bar" exists, zsh will refuse to overwrite "bar" and give you an error: "zsh: file exists: bar" This makes constructs such "foo < bar > baz" perfectly safe, because accidentally typing "foo > bar > baz" will error out when "bar" (or "baz") already exists. (PS: if you want to force zsh to overwrite the file even when NO_CLOBBER is set you can "foo >| bar")

lelanthran 4y ago
That doesn't help with sed -i and similar things. Zsh stops redirection errors, it won't help even if cat is in the front.
- pmoriarty 4y ago
  "That doesn't help with sed -i and similar things." Can you give an example? I don't know what you mean. "Zsh stops redirection errors" Which is what the post I was answering to was complaining about, wasn't it? "it won't help even if cat is in the front" Why not? "cat > foo" will error out if "foo" exists and NO_CLOBBER is set.
  - lelanthran 4y ago
    >> "That doesn't help with sed -i and similar things." > Can you give an example? I don't know what you mean. Sure. The first line below is dangerous no matter what zsh does to save you from yourself. The second line is safe no matter which shell you are using, and no matter what other commands are in the pipeline: sed $SEDOPTIONS "s/$SEARCHTERM/$REPLACEMENT/g" $FILENAME cat $FILENAME | sed $SEDOPTIONS "s/$SEARCHTERM/$REPLACEMENT/g" >> "Zsh stops redirection errors" > Which is what the post I was answering to was complaining about, wasn't it? That's not how I interpreted "a typo in the rest of the pipeline." Sure, the typo could be a redirection. It could also accidentally set $SEDOPTIONS in the example above to include the '-i' flag. >> "it won't help even if cat is in the front" > Why not? "cat > foo" will error out if "foo" exists and NO_CLOBBER is set. Yes, "cat > foo" will error out, but "cat $FILENAME | sed -i "s/a/b/g" $FILENAME" won't.
    - pmoriarty 4y ago
      Yes, in-place editing with tools like sed is dangerous. But, in your own example you have a useless use of cat: cat $FILENAME | sed $SEDOPTIONS "s/$SEARCHTERM/$REPLACEMENT/g" could be replaced with: sed $SEDOPTIONS "s/$SEARCHTERM/$REPLACEMENT/g" < $FILENAME
      - lelanthran 4y ago
        Well, that's the whole point of the useless use of cat - in the non-cat example you gave, making a typo at the end of the command destroys my data. With the useless use of cat, that is no longer possible even if there is a typo in the SEDOPTIONS.
Beltalowda 4y ago
> With zsh you can prevent such accidents by "setopt NO_CLOBBER" Don't even need zsh for this; "set -C" will do the same in any POSIX shell. >| is also in POSIX. csh supports it as well.

yrro 4y ago

> It's clearer - the structure indicates right at the front what it is going to do, namely read a file and pass it through a pipeline. There is no need to read ahead to find out what the source material is. I only found this out recently, but this works perfectly fine: $ < /some/file awk ... You're not wrong though, where cat improves readability there's no harm in using it.