Use long flags when scripting (2013) • Hacker News Board

Re: Use long flags when scripting (2013)

#171

Post by nobody9999 » Sat, Sep 19, 2020, 1:36 PM UTC

UI_at_80x24 wrote: post #89

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/

I remember 90% of the time which flag I want to use, but the other 10% sends me into a rage! =) I gave up and added this to my .bashrc: function extract() { if [ -f $1 ] ; then case $1 in *.tar.bz2) tar xvjf $1 ;; *.tar.gz) tar xvzf $1 ;; *.bz2) bunzip2 $1 ;; *.rar) unrar x $1 ;; *.gz) gunzip $1 ;; *.tar) tar xvf $1 ;; *.tbz2) tar xvjf $1 ;; *.tgz) tar xvzf $1 ;; *.zip) unzip $1 ;; *.Z) uncompress $1 ;; *.7z) 7z x $1…

I can certainly understand the impulse to something like this, but as other posters pointed out, your case statement is incomplete, and will continue to become more so as new tools become available.

Personally, I consciously avoid using the internal decompression features of tar, both out of habit and to avoid unexpected results.

As such, I generally use command lines like: bunzip2 -c |tar xvf -

instead of relying on tar xvjf

I don't see it as wrong or bad to use tar's decompression features, it's more about my own preferences and experience. Being able to perform similar actions in multiple ways is one of the things I've always appreciated about the shell and the Unix/GNU userland.

Re: Use long flags when scripting (2013)

#172

Post by khalilravanna » Sat, Sep 19, 2020, 1:40 PM UTC

kazinator wrote: post #158

maxioatic wrote: post #104

Earlier quoted context omitted.

Why not just "man grep | grep -- --fixed-strings" real quick?

These real quick moments add up to wasted time real quick.

Wasted time for someone who has all of these memorized. How about all the future wasted time of people having to look up the flags cause they’re not explicitly spelled out? I’m in favor of explicitness because it saves time for future people and gatekeeps less.

Re: Use long flags when scripting (2013)

#173

Post by nobody9999 » Sat, Sep 19, 2020, 1:49 PM UTC

stjohnswarts wrote: post #137

saagarjha wrote: post #130

Earlier quoted context omitted.

Die out and be replaced by what?

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

Re: Use long flags when scripting (2013)

#174

Post by hanselot » Sat, Sep 19, 2020, 2:25 PM UTC

[dead]

Re: Use long flags when scripting (2013)

#175

Post by nojvek » Sat, Sep 19, 2020, 2:29 PM UTC

Great advice. Except a whole bunch of popular cli utils doesn’t have long versions.

Like kubectl -f. In apply, it means file, in logs it means follow. Drive me nuts how they overload short flags with different means but no long version.

Or gsutil/gcloud.

I get google folks, don’t really care much about always having a long readable version of short flag.

Re: Use long flags when scripting (2013)

#176

Post by lhorie » Sat, Sep 19, 2020, 2:36 PM UTC

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 dunno. I may know them but the next person may not. Where I work, there are plenty of people who primarily work w/ other langs and only dabble in bash once in a blue moon.

Case in point, when I was learning, I'd copy and paste snippets I found online without understanding what some flags did. At first I didn't even know how to look up docs, and googling for the meaning of shorthand isn't always fruitful, especially given the "don't know how to find docs" limitation.

I've even ran into cases where the next person is myself. For example at one point, I "knew" docker flags while it was fresh in my mind, but then forgot what they meant a few months later...

Re: Use long flags when scripting (2013)

#177

Post by annoyingnoob » Sat, Sep 19, 2020, 2:49 PM UTC

jolux wrote: 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.

Re: Use long flags when scripting (2013)

#178

Post by mattkrause » Sat, Sep 19, 2020, 3:22 PM UTC

zbuf wrote: post #34

OskarS wrote: post #31

Earlier quoted context omitted.

How often do you use gzip verbose? I don't think I've ever used it. What's it good for?

Personally a fan of '--verbose' to be honest. It's clear. "grep -v" anyone?

Of all the options, it is so fitting and proper to use the long form for —-verbose.

Re: Use long flags when scripting (2013)

#179

Post by ori_b » Sat, Sep 19, 2020, 3:48 PM UTC

rascul wrote: post #115

ori_b wrote: post #13

Earlier quoted context omitted.

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…

> 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. From the bash man page, "If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, whi…

> From the bash man page, "If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well."

From what I remember, it doesn't do a particularly good job.

Re: Use long flags when scripting (2013)

#180

Post by rgoulter » Sat, Sep 19, 2020, 4:00 PM UTC

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…

Yes. Suggestions are good. Following suggestions with purpose is better. Or, rather, blindly following suggestions without understanding the benefits (and costs to) the suggestions doesn't seem ideal to me. -- It respects the great answer of "it depends".

Gonna admit that I wouldn't be able to tell what grep -i, sed -e do. (I would've used `sed -e` before, but not enough to remember that). Still, some things are clear from context.