That's very cool!

To take advantage of the "leading space" one, I have this, to mark some commands that I never want to record:

       unhist () {
         alias $1=" $1"
       }
       unhist unhist
       unhist fzf
       unhist rghist     #custom command that greps .zhistory,...

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 in case anyone wants to take a look

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

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!

A 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.

I use a variant with ssh and some compression:

    docker save $image | bzip2 | ssh "$host" 'bunzip2 | docker load'

If you are happy with bzip2-level compression, you could also use `ssh -C` to enable automatic gzip compression.

You can also nest those, so this way you can get a value from an argument, or an env var, and if none is set, error.

    echo "${1:-${env_var:?I need a value for that!}}"

Ooh, I didn't know you could nest 'em! ChatGPT never told me that! Now we're getting somewhere! :)

    echo "${1:-${env_var:?I need a value for that!}}"

That is awesome! :)

Like massively concise construct. I don't know what other language can compete:

  console.log(process.argv[2] || process.env.VAR || console.error("I need a value for that"));

I personally prefer the bash v

It blows my mind how big a deal argument parsing is in legacy scripting languages (including python).

That snippet is concise, but relies on the user supplying arguments in the order you demand. AFAICS, non-trivial scripts require you to loop over arguments, testing against long and short forms of parameters, and shifting if the parameter expects an argument.

In Powershell, you define your parameter and apply constraints. Voila:

    [Parameter(Mandatory)]
    [ValidateRange(1, 20)]
    [int]$foo

That's it, the entire thing, done.

Thanks for that. I'm currently migrating a set of bash scripts to PS1 for win compatibility. This is gonna help me! Undeniably a good feature. Sure there's the case / getopts idiom for parsing args in bash as you say, but I'd say this is a place PS excels them in. I totally agree that arg parsing should be standardized and simple like this. A nice CLI is just such a joy to use. Ideally something that includes usage info and (like the PS example seemingly) optionality.

Syntactically I'd even prefer a single line, like

  [Pram(musthave):In(1, 20)/"Foos excessive or inadequate":int/$foo:"Foo count"/"Please supply how many foos you want."]

If you call python a legacy scripting language, i'll call Windows (where powershell runs on) a legacy operating system.

Sure, Windows doesn't have "legacy" like VMS or Unix etc, but it's been in use by every day people longer than any other current OS except for MacOS, which really isn't the same OS it launched as, whereas Windows has maintained backwards compatibility (for better for for worse) for decades. So.. Legacy? Why not.

This is the most civilized flame war I have ever seen. :)

I didn't mean to describe python as "legacy"; it is a great choice for scripting in the year 2023. It's second only to pwsh for that.

I use pwsh on Linux every day.

Anything that isn't a lisp machine is a legacy OS ;-)

I realise I've given offense, for which I'm sorry, but I'm driven not so much to denigrate bash as to advocate for a world where shells are semantic.

Here's a solution in k, that uses a similar array oriented approach:

    &2=+/~x!/:\:x:!100

I wrote a little explanation of it, in case anyone is curious about how it works: https://github.com/kidd/arraylangs-index/blob/master/noteboo...

I couldn't find a way to have more than one callback per signal, and created a system to have an array of callbacks:

https://github.com/kidd/scripting-field-guide/blob/master/bo...

A nice bonus is that it also keeps the return value of the last non-callback function, so your script behaves better when called from other scripts.

I have 2 use cases for cf), but I don't use it a lot in the end:

One is when inside a parenthesis, and wanting to really delete till the closing parenthesis. But that would leave an unbalanced open paren. So in this case, I use ct) most of the times.

The other is when the cursor is before the opening parenthesis, and I want to delete the whole block. In that case, I found c% to be easier to me. The advantage being that it works with other delimiters ({[]}) handles nesting better, and it's multiline friendly.

If instead of c%, we speak about d%, another plus is that dot (.) will repeat the generic command, so

    if (is_foo()) {

      return 1;
    }

can be cleared with `d%.` from the beginning of the first line.

ca( and ci( might be what you’re looking for.

Yep, good point. They are useful when you want to change the whole text inside the delimiters (and IME, it's most of the times), but they do different things than cf( because they also change/delete text behind the cursor.

The % approach works only on one direction.

`c])` is also pretty handy when you're within a bunch of parentheses. For instance,

    if funca(funcb(red, green), funcc(blue, yellow)) {
                                ^

If you are where the arrow is, `c])` will change the second argument. If you were on the comma before it, `d])` will remove all but the first argument.

Another advantage of pipes at the end is that you can comment lines and the full pipeline still works.

Some time ago I wrote a bunch of tips to make more ergonomic bash scripts: https://raimonster.com/scripting-field-guide/index.html

Also, Perl's diamond operator does the DWIM thing with files/stdin, and it's used directly as a line iterator. It handles multiple files (or none) in a row, which is a nice plus :) https://perlmaven.com/the-diamond-operator

Here's where he explains how he did it: https://www.youtube.com/watch?v=ORjyXcLDd9M