3 ms·

Wow 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 th

by mzs 6mo ago

Wow 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 ago
for 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 ago
  You'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 ago
    aha! 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!

by mzs 6mo ago

rgrau 6mo ago

for 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 ago
You'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 ago
  aha! 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!