11 ms·
I love this, from a comment on the article: He had in his path a script called `\#` that he used to comment out pipe elements like `mycmd1 | \# mycmd2 | mycm
by tkocmathla 6mo ago
I love this, from a comment on the article:
He had in his path a script called `\#` that he used to comment out pipe elements like `mycmd1 | \# mycmd2 | mycmd3`. This was how the script was written:
```
#!/bin/sh
cat
```
- 000ooo000 6mo agoWhat does it provide over mycmd1 #| mycmd2
- chriswarbo 6mo agoTheirs "turns off" one element of a pipeline; yours turns off everything after a certain point. This will output the stdout of mycmd1: mycmd1 #| mycmd2 | mycmd3 This will output the stdout of mycmd3: mycmd1 | \# mycmd2 | mycmd3
- mkoryak 6mo agoCan you explain to me why either of these is useful? I've somehow gotten by never really needing to pipe any commands in the terminal, probably because I mostly do frontend dev and use the term for starting the server and running prodaccess
- agons 6mo agoI can imagine a pipeline where intermediate stages have been inserted to have some side effect, like debug logging all data passing through.
- chriswarbo 6mo agoPipelines are usually built up step by step: we run some vague, general thing (e.g. a `find` command); the output looks sort of right, but needs to be narrowed down or processed further, so we press Up to get the previous command back, and add a pipe to the end. We run that, then add something else; and so on. Now let's say the output looks wrong; e.g. we get nothing out. Weird, the previous command looked right, and it doesn't seem to be a problem with the filter we just put on the end. Maybe the filter we added part-way-through was discarding too much, so that the things we actually wanted weren't reaching the later stages; we didn't notice, because everything was being drowned-out by irrelevant stuff that that our latest filter has just gotten rid of. Tricks like this `\#` let us turn off that earlier filter, without affecting anything else, so we can see if it was causing the problem as we suspect. As for more general "why use CLI?", that's been debated for decades already; if you care to look it up :-)
- mkoryak 6mo agono no, not asking why use CLI. If I was less lazy, I would use it more often
- 000ooo000 6mo agoAh duh, cheers
- mzs 6mo agoWow I hate* that. I use bracket comments. They're cool cause they are bracket comments, so I use it in scripts to document pipelines. They are annoying cause they are bracket comments, in an interactive shell I have to type more and in TWO places. It's fun to reason-out how it works ;) $ echo foo | tr fo FO | sed 's/FOO/BAR/' BAR $ echo foo | ${IFS# tr fo FO | } sed 's/FOO/BAR/' foo It's nice to have a way to both /* ... */ and // ... in shell scripts though: foo \ | bar ${IFS Do the bar. Do it. } \ | baz * in the best possible way, like it's awful - I hate I didn't think of that
- rgrau 6mo agofor multiline pipes, it's WAY better to format like foo | bar | baz You don't have to use backquotes, AND, it allows you to comment line by line, because there's no backslash messing with the parser. I also use a last `|\ncat` so you can delete any line and you don't have to worry about the last line being a bit different than the rest I created a list of similar tricks in https://github.com/kidd/scripting-field-guide https://github.com/kidd/scripting-field-guide in case anyone wants to take a look
- mzs 6mo agoYou'll probably dislike this too: $ { > echo foo \ > && echo bar \ > || echo baz ; > } foo bar <^P><^A>$<^F>IFS ${IFS# echo foo && echo bar || echo baz ; } $ _ There's good and bad to both approaches. I like how I can use () and {} to bracket things and otherwise every line that end in \ is continued. I line-up on the left with the operator, you with indentation. When you use a # style comment, you have to look up and back and forward to see what the operator is you are continuing over to the next line: $ foo | bar | # ?Do? *the* $bar$ && [do] {it!} baz Which only takes an extra neuron or so, but then history... <^P> $ foo | bar | # ?Do? *the* $bar$ && [do] {it!} baz
- rgrau 6mo agoaha! I see what you mean, it's indeed a nice option, yep. Using brackets like this is something I never thought of, and it's probably why it's hard for me to process it, but I can see it provides nice annotation capabilities, and it's a more self-contained style. Thx for sharing!
- semanticc 6mo agoI think the script would be named as `#` so that it can be called via `\# mycmd` instead of `\\# mycmd`.
- internet_points 6mo agoYes! That one's going in my $PATH. Such a useful use of cat!
- rgrau 6mo agoA similar trick: #!/bin/sh $* that's my `~/bin/noglob` file, so when I call a zsh script from bash that uses `noglob`, it doesn't blow up.