Live data from Hacker News

Use long flags when scripting (2013)

changelog.com

181–190 of 197 posts

Re: Use long flags when scripting (2013)

#181
post #73

Earlier quoted context omitted.

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

I was. Thank you.

Re: Use long flags when scripting (2013)

#182
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 I'm splitting across lines, I prefer to put the pipe _after_ the newline. Otherwise, I like the cut of your jib, and will likely do this with arguments in scripts from now on.

sometimes I do something like this:

  foo \
    --group1 \
    \
    --group 2 \
    --more-stuff 2 \
    | \
   bar \
    --bar-stuff
using a line with a single backlash or breaking out the pipe can make grouping stuff clear. well, I mean as clear as having to use backslashes which to me is a little inelegant. Personally python and its indenting strategy has grown on me especially since editor support makes it painless to use and visually excellent.

Re: Use long flags when scripting (2013)

#183
post #43

I wanted to say that Microsoft explicitly says to use the full argument label and not omit them when writing PowerShell scripts but I can't find the doc.

I was thinking that the author would really like PowerShell. PowerShell is the most verbose thing I've ever used. I don't really like to type that much for simple things. I say just learn the flags or look them up, it shouldn't be hard or time consuming. When reading scripts, many times you can infer what the flags mean by understanding the inputs and desired outputs.

Sometimes, but well-written PowerShell scripts can be surprisingly readable, particularly in comparison to bash.

Re: Use long flags when scripting (2013)

#184

Earlier quoted context omitted.

Powershell? It's available for linux now

> Powershell? It's available for linux now I'd rather have my tonsils extracted through my ears. I went the other way[0] decades ago and never looked back. [0] https://www.cygwin.com

I was mostly joking. The verbosity of powershell just makes me throw up in my mouth a little time every time I have to deal with it.

Re: Use long flags when scripting (2013)

#185

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 (-n…

OK I admit to still using % and ? in pipelines. And yes, I tend to prefer keeping "unnecessary" syntax like you pointed out sometimes. Helps me parse and read the scripts easier.

Re: Use long flags when scripting (2013)

#186
post #97

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.

The worst (well known) offender is grep -v meaning grep --invert-match just for the sheer bafflement of "verbose" now hiding what you were looking for.

That actually comes from ed and vi. The g command would search for a line that matches a given regular expression and run the following command on that line. The v command was the inverse (search for lines that don't match the given regular expression).

The default command was to just print the line. Hence the name grep

g/re/p

Re: Use long flags when scripting (2013)

#187

Earlier quoted context omitted.

> Powershell? It's available for linux now I'd rather have my tonsils extracted through my ears. I went the other way[0] decades ago and never looked back. [0] https://www.cygwin.com

I was mostly joking. The verbosity of powershell just makes me throw up in my mouth a little time every time I have to deal with it.

Oh noes! I've been Poe'd![0]

But I really would recommend Cygwin[1] for anyone who needs to use Windows.

Having a real shell makes a big difference.

[0] https://en.wikipedia.org/wiki/Poe's_law

[1] https://cygwin.com

Re: Use long flags when scripting (2013)

#188

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

Even better. :)

Re: Use long flags when scripting (2013)

#189

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…

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.

If I would create something which needs that degree of portability I would never use a shell script.

It's just way too easy to run into a unexpected gotcha on some platform/configuration.

Post reply on HN