rgrau

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!

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 

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

A similar trick:

    #!/bin/sh
    $*

I use a variant with ssh and some compression:

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

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!}}"

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

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

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.

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.

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;
    }

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

Oh, I hadn't noticed that links are not highlighted as such (unless already visited).

Fixed, thanks!

Fixed, thanks!

If appropriate, change to the script’s directory close to the start of the script.

And it’s usually always appropriate.

I wouldn't think so. You don't know where your script will be called from, and many times the parameters to the script are file paths, which are relative to the caller's path. So you usually don't want to do it.

I collected many tips&tricks from my experience with shell scripts that you may also find useful: https://raimonster.com/scripting-field-guide/

Oh!

I didn't know that one could build an arbitrary string like that inside a map.

Thanks a lot for that, I agree it looks better!

A very useful function in jq is "join", which I use a lot to cook the final shape of the data (many times used with fzf/dmenu)

Here's a simple way to list and browse github issues of a given user/repo:

    #!/usr/bin/env sh

    browse_url() {
      firefox http://github.com/$1/issues/$2
    }

    issue=$(curl https://api.github.com/repos/$1/issues |
          jq -r 'map([(.number|tostring), .title] | join(" | ")) | join("\n")' |
          dmenu -i -l 10 |
          awk "{print \$1}")

    browse_url $1 $issue

    map([(.number|tostring), .title] | join(" | "))[]

Even funnier when you realize bash and zsh do different things (by default) there.

   foo="ls -las"
   $foo
   "$foo"

Yep, sorry about that, I meant in general. This particular case is fine, and I am grateful for that.

yes! that looks super useful indeed. Thanks!

What I miss most about those collections is that they are browser based, and when I'm programming, if I need the music to stop, or I get a call, or something, I have to go find the tab and manually stop it.

I'm trying to maintain a list of radios in .pls/.m3u format [1], so I can choose how I play them (emacs+mplayer).

- Don't like the current song? m-x kill-radio RET

- Want to store the current name of the song? m-x hit RET

Making the interface as painless as possible is part of what makes music for programming more relaxing to me. I find strange there are not more of those kinds of repos around (I haven't found them)

1. https://github.com/kidd/radios

thanks so much! I'll fix all those right away :+1:

wow, that's a great one!

Part of the mystery of the infamous shell fork bomb is that it picks a weird name like ':' for the function name.

    :(){ :|:& };:

    bomb() {
      bomb | bomb &
    }
    bomb

Several ways (overkill answer, but leaving all options I know because why not):

You can try evaluating this in the scratch buffer

    (if (member 'nativecomp features)
        (message "yay")
      (message "nay"))

Or open help for an elisp function (next-line, for example):

    c-h f next-line RET

    next-line is an interactive native compiled Lisp function in ‘simple.el’.

Or maybe, you'd have the same dollar a million times... you never know...

Most of my scripts start with that template on 4.20.1. That's the baseline. But soon enough they have 4.22 and 4.25.

I never liked those "bare minimum templates" that are 100 lines, because usually the scripts I write start being just a couple dozen lines. If they grow, I add things on a need basis, but the ratio of logic/template has to be >0 always.

wrt completions, doing smart completions is hard, and the zsh ones are not very intuitive to me. I try to make my scripts work with "compdef _gnu_generic ". It goes a long way, and it's an incentive to write proper --help

Thanks for giving it a read. Glad it was useful!

For fast iteration with pipes, using only basic unix tools, and arguably less risky to fat-fingering, I write it in a file, and use watch -n1. Easy to modify, temporarily comment parts of it, etc...

Also, I wrote this plog function (for pipe-log, or something):

    plog() {
      local msg=${1:-plog}
      tee >(sed -e "s/^/[$msg] /" | cat 1>&2 )
    } 

I ended up compiling a list of tricks like that in https://raimonster.com/scripting-field-guide/ , in case anyone is interested (and feedback is appreciated)

Yep, https://github.com/sshaw/git-link and it's available in melpa