For scripts that are read and executed more often than they're written or changed, the long flags really help ensure you don't fat-finger.

I'm accustomed to typing `rm -rf` when really I just need `rm -r` in a lot of cases, and in PRs it's very easy for your eyes to glaze over when there's more than a single short flag.

    mkdir demodir && touch demodir/{foo,bar} && rm -r demodir

I could've sworn that -I was the default......

I feel it does more harm than good by normalising rm -f when you want to recursively delete a folder, but with CD deployments these days it's less of a deal.

To be fair though they were referring to CD deployment(s), plural, which is a bit redundant and just CD would have done just as well in this case.

    alias rm='rm -i'
    alias cp='cp -i'
    alias mv='mv -i'

So what's your justification to dismiss the idea that this is a common practice?

Thank you for the info, though.

The long flags are less likely to be changed over time. The script will usually fail gracefully and I don't also need to relearn what I was thinking 25 years ago when I first did it. (long flags are like in-command comments too)

And as others have pointed out -v(ersion) or -v(erbose) can happen too.

Many programs use -v as a short flag for --version, but some (such as curl) use it as short for --verbose

Probably something you'd catch pretty quickly, but still.

The default command was to just print the line. Hence the name grep

g/re/p

[1]: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...

Though I would make the list of "allowed" short flags very short. I can't think of many more than the ones you listed:

  mkdir -p
  sh -c
  cp -r
  tar -xaf
  tar -caf

I gave up and added this to my .bashrc:

    function extract()      
  {
     if [ -f $1 ] ; then
         case $1 in
             *.tar.bz2)   tar xvjf $1     ;;
             *.tar.gz)    tar xvzf $1     ;;
             *.bz2)       bunzip2 $1      ;;
             *.rar)       unrar x $1      ;;
             *.gz)        gunzip $1       ;;
             *.tar)       tar xvf $1      ;;
             *.tbz2)      tar xvjf $1     ;;
             *.tgz)       tar xvzf $1     ;;
             *.zip)       unzip $1        ;;
             *.Z)         uncompress $1   ;;
             *.7z)        7z x $1         ;;
             *.zst)       zstd -d $1      ;;
             *.xz)        unxz $1         ;;
             *)           echo "'$1' cannot be extracted via >extract<" ;;
         esac
     else
         echo "'$1' is not a valid file"
     fi
}

Another "recent" (much more recent IIRC) change is that you don't need the dot anymore in find to search in the current directory.

  extract() {
    bsdtar -xf "$1"
  }

Personally, I consciously avoid using the internal decompression features of tar, both out of habit and to avoid unexpected results.

As such, I generally use command lines like: bunzip2 -c <tar.bz2 file> |tar xvf -

instead of relying on tar xvjf

I don't see it as wrong or bad to use tar's decompression features, it's more about my own preferences and experience. Being able to perform similar actions in multiple ways is one of the things I've always appreciated about the shell and the Unix/GNU userland.

Anyway, my advice to you and anyone else having trouble with tar is that "tar caf" and "tar xaf" are the only things most people need to remember about tar, with or without compression.

(In this case, most people means people who use tar, but so rarely that they have trouble remembering how to use it; they probably never use it for anything else other than (un)archiving. Also, xkcd isn't gospel.)

  tar cf dir.tar dir          # mnemonic: 'create file' <tar-file-name> <dir-to-tar>
  tar xf dir.tar(.gz|bz2|...) # mnemonic: 'eXtract file' <tar-file-name>

  $ tar --help

    $ tar --help
    tar: unknown option -- help
    usage: tar [-]{crtux}[-befhjklmopqvwzHJOPSXZ014578] [archive] [blocksize]
               [-C directory] [-T file] [-s replstr] [file ...]
    $

  $ list '#! /bin/sh' 'echo "tar: invalid command" >&2' 'exit 64' >/tmp/tar
  $ chmod a+x /tmp/tar
  $ PATH="/tmp:$PATH"
  $
  $ tar -cf a.tar a/
  tar: invalid command
  $

Fair enough. My point was that there's a category of operating systems where long options (including --help) isn't really a thing. You may of course consider them defective, though I'm not sure everybody agrees.

Even better. :)

Case in point, when I was learning, I'd copy and paste snippets I found online without understanding what some flags did. At first I didn't even know how to look up docs, and googling for the meaning of shorthand isn't always fruitful, especially given the "don't know how to find docs" limitation.

I've even ran into cases where the next person is myself. For example at one point, I "knew" docker flags while it was fresh in my mind, but then forgot what they meant a few months later...

Kids today no longer know the shell. They think just writing some yaml files in ansible is sufficient. Giving them a shell script won't help at all.

Sounds like Kochan and Wood[0] need some love (and royalties).

Or is learning stuff deprecated these days?

[0] https://www.amazon.com/Unix-Shell-Programming-Stephen-Kochan...

What about other people who might read the script?

Also is typing that much of a chore?

Gonna admit that I wouldn't be able to tell what grep -i, sed -e do. (I would've used `sed -e` before, but not enough to remember that). Still, some things are clear from context.

Doubt you'd be printing out a version number in a shell script though.

> Selected lines are those not matching any of the specified patterns.

For the lazy.

Edit: I don't know hackernews formatting and I'm among the lazy, so... Marked as "won't fix".

It's rare that I'd use it in a script. Perhaps I'd use it for a script whose main purpose is creating an archive to be widely distributed. Then the info might be of interest to the script's user.

But your comment brings up a good point about the difficulty of deciding what short flags truly are widely known. I assumed anyone who uses gzip regularly would know "-v", but maybe that isn't true.

But I also don't use gzip much these days. pbzip2 is a drop in replacement that is faster and compresses better.