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

131–140 of 197 posts

Re: Use long flags when scripting (2013)

#131

Post by [deleted] »

jfrunyon wrote: post #41
ryanianian wrote: post #32

Earlier quoted context omitted.

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

[deleted]

Re: Use long flags when scripting (2013)

#132

Post by nostoc »

dpcx wrote: post #78
MaxBarraclough wrote: post #49

Earlier quoted context omitted.

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.

As does Python, which drives me crazy. -V is version on Python.

There's so much variation in flags for version, I've taken the habit of always using the long `--version` flag.

Re: Use long flags when scripting (2013)

#133

Post by nostoc »

redisman wrote: post #50
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.

Someone who's tasked with maintaining shell scripts better be familiar with the shell.

Re: Use long flags when scripting (2013)

#134

Post by stjohnswarts »

corpMaverick wrote: post #110
stack_underflow wrote: post #93

Earlier quoted context omitted.

These two commands should fit most of your use cases: tar cf dir.tar dir # mnemonic: 'create file' tar xf dir.tar(.gz|bz2|...) # mnemonic: 'eXtract file' On systems with "modern" versions of tar `-x` is capable of recognizing which compression format is used and doesn't require the explicit `-j/z` flags you usually see.

Exactly, these are the only ones I know and never get confused. Actually I use cvzf and xvzf.

you might want to at -p for preserving permissions in there are well, handy for archiving

Re: Use long flags when scripting (2013)

#135

Post by stjohnswarts »

nick238 wrote: post #5
jwmhjwmh wrote: post #2

If you're trying to stick to the POSIX standard, you have to use short options for standard commands like grep, since the long options are GNU extensions.

I've given up trying to be as pure and standard as possible. I could write all my scripts to use `sh`, but `bash` can make things far easier, and in my docker containers is often required by some other package anyway, so may as well just own it.

I agree, bash vs sh is night and day. Although these days I mostly use python. If I really really need something I can always shell out in python as well.

Re: Use long flags when scripting (2013)

#136

Post by stjohnswarts »

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…

I do 95% of my work on linux so bash it is. I'm not really concerned about other systems. I can always google later. It would take down my productivity quite a bit if I worried if all my scripting needed to be compatible with BSD or other unix varieties. YAGNI is mostly true.

Re: Use long flags when scripting (2013)

#137

Post by stjohnswarts »

saagarjha wrote: post #130
ramses0 wrote: post #83

Earlier quoted context omitted.

It's so unfortunate about Bash + Apple. Bash probably deserves to die out, but Apple has really pulled a bait-and-switch on OSX's *nix/bsd underpinnings over the years.

Die out and be replaced by what?

Powershell? It's available for linux now

Re: Use long flags when scripting (2013)

#138

Post by leoh »

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 disagree. BSD and GNU implementations differ. Because of this, it's easier to discern intent of long flags.

Re: Use long flags when scripting (2013)

#139

Post by stjohnswarts »

watt wrote: post #73
efrecon wrote: post #67

Earlier quoted context omitted.

I think you are right, for all "exotic" tools, long flags are much better and future proof. For regular tools, short flags are so common that they are probably ok.

Your regular tool is not my regular tool. Hell, maybe my regular tool today is not going to be all that regular in 3 years.

He's talking about thing like sed/awk/grep/find/xargs/tar not new_hotness_util_2020
Post reply on HN