Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Use long flags when scripting (2013)

changelog.com

Post reply on HN
Print view View original

41–50 of 197 posts

Re: Use long flags when scripting (2013)

#41

Post by jfrunyon »

ryanianian wrote: post #32
adrianmonk wrote: post #19

Great suggestion, but I'd go for a middle ground: use long flags for the long tail, but short flags are fine for stuff that's very commonly used. I think I'll continue to write these: grep -i rm -rf ln -s gzip -v sed -e instead of: grep --ignore-case rm --recursive --force ln --symbolic gzip --verbose sed --expression If you're working on shell scripts, you probably know certain short flags well enough that long flag…

The short flags are really there for when you're doing things interactively. 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.

You literally always need -f with -r in a script (unless you want rm to prompt the user), though...

Re: Use long flags when scripting (2013)

#42

Post by jfrunyon »

frenchy wrote: post #40
zbuf wrote: post #34

Earlier quoted context omitted.

Personally a fan of '--verbose' to be honest. It's clear. "grep -v" anyone?

Particularly in this case, because `-v` sometimes means "print out the version number".

That's why they mentioned `grep -v`. Go look it up. It doesn't mean verbose OR version.

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

Re: Use long flags when scripting (2013)

#45

Post by adrianmonk »

OskarS wrote: post #31
adrianmonk wrote: post #19

Great suggestion, but I'd go for a middle ground: use long flags for the long tail, but short flags are fine for stuff that's very commonly used. I think I'll continue to write these: grep -i rm -rf ln -s gzip -v sed -e instead of: grep --ignore-case rm --recursive --force ln --symbolic gzip --verbose sed --expression If you're working on shell scripts, you probably know certain short flags well enough that long flag…

How often do you use gzip verbose? I don't think I've ever used it. What's it good for?

It shows you the percentage reduction in size.

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.

Re: Use long flags when scripting (2013)

#46

Post by jfrunyon »

ori_b wrote: post #13
Analemma_ wrote: post #6

Earlier quoted context omitted.

Unless you count things like Makefiles, I don't think I've ever written or encountered a "script" that was intended for use on multiple *nix flavors. This strikes me as a YAGNI situation: do it if it comes up, but not before.

This attitude is definitely something that makes my life harder. My OS is usually OpenBSD, and I constantly need to fix other people's scripts. It's not difficult to do, but it is annoying. I don't blame people for ignorance, but it'd be nice if people thought about portability. Non-portable scripts can also bite you on Linux, where Debian, for example, will swap out the shell from bash to dash for performance. but o…

Sounds to me like your choice of OS is what makes your life harder...

Re: Use long flags when scripting (2013)

#47

Post by InvaderFizz »

viseztrance wrote: post #7
m463 wrote: post #3

In scripts, I usually do stuff like this command \ --longopt1 \ --longopt2 arg \ argument or command | \ command 2 | \ command 3 \ --opt1 \ --opt2 \ arg

If you have a very long command you can run ctrl x e (hold control press x, than e) and edit it in your $EDITOR.

I wish I had known this 20 years ago. Thanks!

Re: Use long flags when scripting (2013)

#48

Post by entire-name »

As the saying goes, code is typically written once and read thousands of times. It takes you less than a second to write the full flag name (add a few seconds if you need to look it up), but it will likely save at least a few hundred readings the time to look up the flag if they do not already know it. In addition, full flag names contributes "self-documentation" in many cases, and also potentially makes searching easier in certain cases.

Re: Use long flags when scripting (2013)

#49

Post by MaxBarraclough »

gkop wrote: post #21
adrianmonk wrote: post #19

Great suggestion, but I'd go for a middle ground: use long flags for the long tail, but short flags are fine for stuff that's very commonly used. I think I'll continue to write these: grep -i rm -rf ln -s gzip -v sed -e instead of: grep --ignore-case rm --recursive --force ln --symbolic gzip --verbose sed --expression If you're working on shell scripts, you probably know certain short flags well enough that long flag…

Long flags aren’t just for readability, they also add entropy which contributes defensiveness against typos.

Related to this, they're less likely to do something unexpected.

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.

Re: Use long flags when scripting (2013)

#50

Post by redisman »

adrianmonk wrote: post #19

Great suggestion, but I'd go for a middle ground: use long flags for the long tail, but short flags are fine for stuff that's very commonly used. I think I'll continue to write these: grep -i rm -rf ln -s gzip -v sed -e instead of: grep --ignore-case rm --recursive --force ln --symbolic gzip --verbose sed --expression If you're working on shell scripts, you probably know certain short flags well enough that long flag…

I think you're assuming a level of Unix knowledge that less and less new people in the field are going to have.
Post reply on HN