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

11–20 of 197 posts

Re: Use long flags when scripting (2013)

#11

Post by 52-6F-62 »

dmurray wrote: post #8
52-6F-62 wrote: post #4

Earlier quoted context omitted.

Wow. I just realized I'm terrible for this. I usually format my programming pretty verbosely to make it future-readable but I'm terrible for not doing that in my scripts. I'll add a comment or something explaining it but now I feel guilty and should probably go back and rewrite a few lines... I mean—for long scripts I'll break them up but I haven't paid much mind to arguments/flags.

I do this if I have to look up the right flag to use. If it's something commonly seen like "grep -o" or "tar -xvzf" I assume whoever is maintaining the script (probably future me) will be more familiar with the abbreviations than the long versions.

Yeah good point. It did strike me, though, because I'd just written several scripts running JMeter commands and sort of breezed over how they're written even though I had to go and look up all the flags.

Re: Use long flags when scripting (2013)

#12

Post by dathinab »

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.

Does anyone care about the standard?

Let's be honest it's outdated, has a bad UX and is with the standards I would hold such a standard against today generally not so good.

Sure systems seen try to somewhat be POSIX compliance but from my experience not because they care about POSIX but because that happen to overlap with the idea to be somewhat compiland with other similar systems so that porting software/scripts is easier.

So if the systems you use support long options for POSIX commands go ahead and use them. Furthermore if the command you can are not in the standard anyway you again can use long options because they are as much standard as the short ones. Let's be honest this leaves very little use-cases where long options are a problem.

Re: Use long flags when scripting (2013)

#13

Post by ori_b »

Analemma_ wrote: post #6
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.

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 others will not. So, even within the Linux ecosystem, you can end up with scripts that behave differently across distros.

Re: Use long flags when scripting (2013)

#14

Post by inshadows »

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

It's nice but you cannot comment individual lines. For that you can go one step further and use arrays:

  cmd=(
    command
    -x -y
    --bar OPTARG
    ARG ARG
  )
  $cmd
This works in Zsh. In Bash that would be ${cmd[@]} I think. I use this with long qemu command lines where I often modify and comment out arguments during testing.

Re: Use long flags when scripting (2013)

#16

Post by inshadows »

No, I'm not going to waste keystrokes and increase noise for lazy people. Convince physicists to write force_gravitational instead of Fg, or functional programmers to give up concepts from abstract algebra, and then I'll reconsider. Until then, RTFM just like you do in other fields. curl is so common you should already know what -s means and if not, well, RTFM.

Re: Use long flags when scripting (2013)

#18

Post by kazinator »

Don't use long flags when scripting, if they have short equivalents, and POSIX only specifies the short equivalents.

Even if the stuff will only ever run on one system, the POSIX flags (1) come from a smaller set of options, since POSIX is fairly conservative in its content this area and (2) are generally well known (often three decades old or older).

Don't make me read a man page to confirm that "grep --fixed-strings" really is the same thing as the POSIX-standard "grep -F", and not something subtly different.

Re: Use long flags when scripting (2013)

#19

Post by adrianmonk »

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 flags just add clutter and don't improve readability.

Re: Use long flags when scripting (2013)

#20

Post by kazinator »

dathinab wrote: post #12
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.

Does anyone care about the standard? Let's be honest it's outdated, has a bad UX and is with the standards I would hold such a standard against today generally not so good. Sure systems seen try to somewhat be POSIX compliance but from my experience not because they care about POSIX but because that happen to overlap with the idea to be somewhat compiland with other similar systems so that porting software/scripts is…

Last published in 2018 (and actively being worked on) is not outdated.

https://pubs.opengroup.org/onlinepubs/9699919799/

> Sure systems seen try to somewhat be POSIX compliance

The mainstream systems you know and use adhere very rigorously to POSIX. GNU Libc, Kernel, Coreutils, ... and their counterparts in BSD Unixes, proprietary Unixes, Cygwin and whatnot all take POSIX seriously.

POSIX is very helpful, and smart coders and sysadmins use it as one of their references for required behavior.

Post reply on HN