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

Re: Use long flags when scripting (2013)

#191

Post by kazinator » Sun, Sep 20, 2020, 4:55 PM UTC

khalilravanna wrote: post #172

kazinator wrote: post #158

Earlier quoted context omitted.

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.

-F is explicitly spelled out. Proof: I can see it. Explicit is the opposite of implicit, and implicit doesn't mean "abbreviated to a single character that is plainly visible".

You don't necessarily know what a long option means without looking it up, just because it is long. Firstly, if your native language isn't English, you may have to look it up in a dictionary. The ordinary meanings you find there may not reveal what that word means in the context of the program. So, at that point you're off to the documentation anyway.

I know what "hard" and "soft" are. Therefore, is it obvious what "git reset --soft" means? Hardly.

Once you know what it means, "--soft" jogs your memory by association a lot better than some "-X". So that would seem like it is less cognitive work. But when we have long options, it encourages the option vocabulary of a program to keep growing, which adds to the cognitive load.

Re: Use long flags when scripting (2013)

#192

Post by Jowsey » Sun, Sep 20, 2020, 5:31 PM UTC

atum47 wrote: post #126

never thought about that. I usually try to keep my code short to try to impress other programmers, but that's really good advice

I'd say a painless, easy to understand program is more impressive than a short one

Re: Use long flags when scripting (2013)

#193

Post by leoh » Sun, Sep 20, 2020, 8:37 PM UTC

0xdeadb00f wrote: post #143

leoh wrote: post #138

Earlier quoted context omitted.

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.

That's not the point. The point is that you can discern intent if you are writing against the GNU implemention so one can trivially reimplement against BSD.

Re: Use long flags when scripting (2013)

#194

Post by lhoursquentin » Mon, Sep 21, 2020, 10:12 AM UTC

tdons wrote: post #37

inshadows wrote: post #14

Earlier quoted context omitted.

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.

You can comment using a hack; check this out: command `# a comment` \ --longopt1 `# another comment` \ --longopt2 arg \ argument

You should probably note that this hack spawns an additional shell process per comment :)

Re: Use long flags when scripting (2013)

#195

Post by jfrunyon » Tue, Sep 22, 2020, 4:10 AM UTC

Alexendoo wrote: post #98

jfrunyon wrote: post #69

Earlier quoted context omitted.

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

The long form of `-a` would be `--archive`, for the same reason that you write `-a` and not `-dR --preserve=all`

I'm afraid that doesn't fit with the "be as explicit as you can regardless of logic" espoused in the article.

Re: Use long flags when scripting (2013)

#196

Post by jfrunyon » Tue, Sep 22, 2020, 4:12 AM UTC

Macha wrote: post #85

jfrunyon wrote: post #79

Earlier quoted context omitted.

Yeah... no. Also definitely not the case. If I actually am remembering it correctly then it's probably from Fedora circa FC5 or Ubuntu circa 6.06. Back when I was in school and had never touched Linux other than on my own computer.

Go do a fresh install of CentOS/RHEL (or just spin up a new docker container) and what do you see in root's bashrc? alias rm='rm -i' alias cp='cp -i' alias mv='mv -i' I've also encountered one job which adds this to their base ubuntu image, and my current employer uses Macs which have it added to bashrc by their mdm software on initial install. So what's your justification to dismiss the idea that this is a common pr…

I wasn't dismissing the idea that it was common practice, I was dismissing the idea that the common practice applied in my case. I did not have an IT department setting anything on my system when I experienced this.

Thank you for the info, though.

Re: Use long flags when scripting (2013)

#197

Post by jfrunyon » Tue, Sep 22, 2020, 4:17 AM UTC

Hello71 wrote: post #112

ahartmetz wrote: post #106

Earlier quoted context omitted.

Actually close to 12 years, GNU tar 1.21 https://www.gnu.org/software/tar/ Another "recent" (much more recent IIRC) change is that you don't need the dot anymore in find to search in the current directory.

according to https://git.savannah.gnu.org/cgit/findutils.git/commit/find/... , this functionality has been present since findutils was moved under source control in 1996.

I believe that GNU find used to (in some cases?) show a warning if the directory was omitted. Could be wrong.