Live data from Hacker News

Use long flags when scripting (2013)

changelog.com

61–70 of 197 posts

Re: Use long flags when scripting (2013)

#61

Earlier quoted context omitted.

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

You must have an alias rm='rm -i' lying around. rm doesn't prompt by default (unless you're the owner of the dir, but not its contents). mkdir demodir && touch demodir/{foo,bar} && rm -r demodir

[deleted]

Re: Use long flags when scripting (2013)

#63
I have been following this advice for about five years with my scripts and the best result has been compliments from co-workers and others who have picked up the scripts and felt like they had a much better understanding of what the scripts were doing.

Combined with use of shellcheck and shfmt working in shell scripting has come a long way in the last couple years. I still feel like BASH is a dead end--the quoting and whitespace issues combined with the bifurcation caused by Apple not shipping Bash 4.0+ make moving to Python probably the better course in 2020.

Re: Use long flags when scripting (2013)

#64

Earlier quoted context omitted.

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

You must have an alias rm='rm -i' lying around. rm doesn't prompt by default (unless you're the owner of the dir, but not its contents). mkdir demodir && touch demodir/{foo,bar} && rm -r demodir

... huh. No, no alias, I just misread the manpage.

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

Re: Use long flags when scripting (2013)

#65
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 usually test my POSIX scripts in an Alpine docker container. It has busybox by default, which only have a few flags and mostly short ones.

Re: Use long flags when scripting (2013)

#66
post #51

Earlier quoted context omitted.

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

It makes my life easier in most ways. This is one of the costs. And, again, this still bites whenever using different linux distros.

I never said that wasn't the case. That doesn't mean anyone else's attitude is the cause of problems caused by your own choices.

#!/bin/bash

Re: Use long flags when scripting (2013)

#67

When writing scripts (CI especially) you'll rarely use, please always use long-flags. It'll save so much headache for the next dev who isn't as up to date with the latest short-hand for az-cli or whatever. When live scripting, feel free to use short.

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.

Re: Use long flags when scripting (2013)

#68

This is how I write PowerShell scripts. I use full cmdlet names, full argument switch names, and I even specify argument switches to positional arguments. I also do my best to honor common flags like `-WhatIf`, `-Verbose`, and `-ErrorAction`. So I end up with scripts like this: if (-not $(Test-Path -Path "$Path" -PathType Container)) { Write-Error -Message "Path ($Path) does not exist or is not a directory." -Categor…

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 (-not $(Test-Path -Path "$Path" -PathType Container)) {
... you don't need the `$`, and if $Path is already a string you don't need the `""` either.

Re: Use long flags when scripting (2013)

#69

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 ea…

You're assuming the long version is more well known than the short version. That's a wildly and provably false assumption.

Do you know, without referring to the manpage, exactly what `cp --no-dereference --preserve=links --recursive --preserve=all` does? I don't. I can take some guesses based on the names of the options, but those guesses could very easily miss an important corner case.

Do you know what `cp -a` does? I do.

Re: Use long flags when scripting (2013)

#70
post #21

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.

But also contributes to the heat death of the universe.
Post reply on HN