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

141–150 of 197 posts

Re: Use long flags when scripting (2013)

#141

Post by mandelbrotwurst »

Macha wrote: post #71
jfrunyon wrote: post #64

Earlier quoted context omitted.

... huh. No, no alias, I just misread the manpage. I could've sworn that -I was the default......

It's a common thing for IT departments or people making enterprise images to put in because they think it makes it safer. 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.

"CD deployments" - Ha, like an "ATM machine"? At first in thought you were describing deployments on compact discs!

Re: Use long flags when scripting (2013)

#142

Post by Arnavion »

ziml77 wrote: post #123
Arnavion wrote: post #68

Earlier quoted context omitted.

PS has another reason to use full names of parameters in long-lived scripts. If you use short names like `-Ver` expecting it to match `-Verbose`, a future version of the commandlet can add `-Version` and now `-Ver` is ambiguous. On the other hand, I've seen some people eschew `%` and `?` in favor of writing `ForEach-Object` and `Where-Object`, which in my opinion is too extreme in the other direction. BTW, in: if (-n…

To me this isn't just another reason, it's THE reason to not use the short form in scripts. Although unlikely, the worst case of this could be pretty nasty. It's possible for someone to remove a flag that was deemed useless and add another flag that matches the same prefix and has a very different effect. I don't know how to feel about % and ?. The thought with not using them is that they are just aliases and could b…

Yes, exactly. If your script is running in an environment that has redefined % and ?, it's either because they want your script to use their definitions, or it's busted beyond repair and you shouldn't worry about supporting it.

Re: Use long flags when scripting (2013)

#143

Post by 0xdeadb00f »

leoh wrote: post #138
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.

Also, some BSD equivalents of GNU commands don't even have long flags.

Re: Use long flags when scripting (2013)

#144

Post by a1369209993 »

lukeschlather wrote: post #82
nemetroid wrote: post #58

Earlier quoted context omitted.

I agree. To me, "sed -e" is an expression as a whole, and replacing -e with --expression is on the same level as aliasing "sed" to "stream-editor". 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

tar is one of the worst. I think I know what those do without looking it up but I think most people look at that with bewilderment. Randall Munroe is always helpful in these matters and has this to say: https://xkcd.com/1168/

> To disarm the bomb, simply enter a valid tar command on your first try. No Googling. You have ten seconds.

  $ tar --help
Obviously. :)

Re: Use long flags when scripting (2013)

#145

Post by EE84M3i »

MaxBarraclough wrote: post #49
gkop wrote: post #21

Earlier quoted context omitted.

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.

Wow, that's funny, I normally expect '-v' to be verbose, but maybe I just use a lot of `tar` and `curl`!

Re: Use long flags when scripting (2013)

#146

Post by a1369209993 »

ridiculous_fish wrote: post #129
dathinab wrote: post #12

Earlier quoted context omitted.

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…

fish shell has been burned in the few places it strictly implements POSIX. The most vivid example is test, aka /bin/[. POSIX specifies that, if test is invoked with one argument, you must "Exit true (0) if $1 is not null; otherwise, exit false" [1]. This means that `test --help` is forbidden from printing any help. It means that `test -d $argv` expands to `test -d` if $argv is empty, which then must "succeed" because…

> It means that `test -d $argv` expands to `test -d` if $argv is empty, which then must "succeed" because "-d" is not null. It bites users over and over again [2].

To be fair, while the POSIX behaviour is obviously wrong, using `$argv` on a bourne-style shell[0] is also wrong; that should be either `test -d "$argv"` or (if I recall the syntax correctly) `test -d "${argv[@]}"` if you actually intended argv to be a list rather than a single directory ("argv" suggests the former, but `test -d X` only accepts a single argument).

0: more specifically, a shell that does word splitting at the wrong place (after parameter expansion)

Re: Use long flags when scripting (2013)

#147

Post by scbrg »

a1369209993 wrote: post #144
lukeschlather wrote: post #82

Earlier quoted context omitted.

tar is one of the worst. I think I know what those do without looking it up but I think most people look at that with bewilderment. Randall Munroe is always helpful in these matters and has this to say: https://xkcd.com/1168/

> To disarm the bomb, simply enter a valid tar command on your first try. No Googling. You have ten seconds. $ tar --help Obviously. :)

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

Re: Use long flags when scripting (2013)

#148

Post by scbrg »

leoh wrote: post #138
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.

I assume the intent to discern, then, is that the script isn't supposed to run on BSD :-)

Re: Use long flags when scripting (2013)

#149

Post by samtheprogram »

saagarjha wrote: post #128
samtheprogram wrote: post #22

Earlier quoted context omitted.

Yes, if you care about portability. Anything that's not Linux likely won't have GNU grep installed by default. This includes macOS and the BSDs. If this is your own dotfiles or utilities, sure, but if I'm working on something collaborative, yes, I care about the standard.

I stick to POSIX in my dotfiles precisely because I carry it around on many different systems and that’s the only thing that can keep it sane.

Same here — I felt it would detract from the point I was trying to make so I didn’t mention it, especially since I don’t think most people run multiple OS’s :) At the least though, I would assume people regularly have collaborators that run different OS’s.

Re: Use long flags when scripting (2013)

#150

Post by a1369209993 »

scbrg wrote: post #147
a1369209993 wrote: post #144

Earlier quoted context omitted.

> To disarm the bomb, simply enter a valid tar command on your first try. No Googling. You have ten seconds. $ tar --help Obviously. :)

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

Okay, so your tar is defective[0], and? I can do that too:

  $ 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
  $
0: any program that doesn't support --help is defective, which was rather my point.
Post reply on HN