Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Use Long Options in Scripts

matklad.github.io

Post reply on HN
Print view View original

21–30 of 157 posts

Re: Use Long Options in Scripts

#21

Post by 01HNNWZ0MV43FF »

userbinator wrote: post #16

Strongly, strongly disagree. This is a GNU-ism, and needlessly verbose. What's with people refusing to use the vast amount of memory in their brains and actually learning, instead lazily going for the lowest-common-denominator approach relying on "loanwords" from English?

Programs are read more often than they're written, and on a scale of decades all programmers are novices. So I try to optimize my code to be obvious to novices

What's wrong with GNU? they automatically wrong or something?

Re: Use Long Options in Scripts

#22

Post by paulddraper »

wahern wrote: post #6

Please DO NOT mix string interpolation and command execution, especially when a command is processed through the shell. Whatever your language, use a list-based or array-based execution API that passes arguments straight through to execv(2), execvp(2), etc, bypassing the shell.

Tbf this input does not need escaping.

But at the very least the shell is unnecessary here.

Re: Use Long Options in Scripts

#23

Post by paulddraper »

mplanchard wrote: post #18
saagarjha wrote: post #9

Unfortunately, if you want your scripts to be portable to other POSIX systems you might have to use the short options, as the long ones are not standardized. You have to decide the tradeoff for yourself.

Using nix has really spoiled me on this. Everyone gets the same versions of all the CLI utilities in the dev environment, whether on mac or linux, and those are the same versions that run in CI and any prod systems. It’s really nice being able to use whichever newer bash features or gawk extensions you like, without having to deal with trying to ensuring the mac engineers have brew-installed all the right stuff to ma…

Everyone has to use nix :)

But yes, that is nice.

Re: Use Long Options in Scripts

#25

Post by userbinator »

01HNNWZ0MV43FF wrote: post #21
userbinator wrote: post #16

Strongly, strongly disagree. This is a GNU-ism, and needlessly verbose. What's with people refusing to use the vast amount of memory in their brains and actually learning, instead lazily going for the lowest-common-denominator approach relying on "loanwords" from English?

Programs are read more often than they're written, and on a scale of decades all programmers are novices. So I try to optimize my code to be obvious to novices What's wrong with GNU? they automatically wrong or something?

So I try to optimize my code to be obvious to novices

That's the attitude which is responsible for making software the way it is today: mediocre.

Re: Use Long Options in Scripts

#26

Post by userbinator »

mplanchard wrote: post #17
userbinator wrote: post #16

Strongly, strongly disagree. This is a GNU-ism, and needlessly verbose. What's with people refusing to use the vast amount of memory in their brains and actually learning, instead lazily going for the lowest-common-denominator approach relying on "loanwords" from English?

Because not everyone has 20 or more years of flag memory from using Linux, and they’ve also got to maintain the scripts. If you’re not familiar with every arcane invocation of find or tar or whatever, or even if it’s just been a while, the long options are a godsend when you’re skimming a script trying to figure out what it’s doing.

Because not everyone has 20 or more years of flag memory from using Linux

It's called learning, apparently something that is now being eschewed in favour of quick superficiality (and making developers more replaceable --- with AI or unskilled offshore labour.) No wonder "modern" software is almost always total shit.

"But I don't have the time to learn," you complain, but ask yourself this instead: Why do you never have the time to do it right, but always the time to do it twice (or however many times is necessary to get a barely-working product)?

Re: Use Long Options in Scripts

#27

Post by yjftsjthsd-h »

pcwalton wrote: post #10
saagarjha wrote: post #9

Unfortunately, if you want your scripts to be portable to other POSIX systems you might have to use the short options, as the long ones are not standardized. You have to decide the tradeoff for yourself.

What POSIX systems in actual use (not historical Unixes) don't have the long options? macOS' BSD utilities I guess?

> What POSIX systems in actual use (not historical Unixes) don't have the long options?

All of them except for GNU, AFAICT? (That is, only GNU seems to have long options.) Checking manpages for rm(1) as a simple reference, I can't see long options in any of the 3 major BSDs or illumos, and checking Alpine Linux seems to show busybox also only doing short options (sorry, can't find an online doc for this, though it's easy to check in docker if you don't have a machine running Alpine handy). OpenWRT also uses busybox and has the same (lack of) options.

https://man.netbsd.org/rm.1

https://man.openbsd.org/rm.1

https://man.freebsd.org/cgi/man.cgi?query=rm&apropos=0&sekti...

https://illumos.org/man/1/rm

Re: Use Long Options in Scripts

#28

Post by tannhaeuser »

mplanchard wrote: post #17
userbinator wrote: post #16

Strongly, strongly disagree. This is a GNU-ism, and needlessly verbose. What's with people refusing to use the vast amount of memory in their brains and actually learning, instead lazily going for the lowest-common-denominator approach relying on "loanwords" from English?

Because not everyone has 20 or more years of flag memory from using Linux, and they’ve also got to maintain the scripts. If you’re not familiar with every arcane invocation of find or tar or whatever, or even if it’s just been a while, the long options are a godsend when you’re skimming a script trying to figure out what it’s doing.

No the problem is to overload utilities with hundreds of options and subcommand languages over the course of decades. The starting point was quick command-line usage but GNU-style long options are clearly rooted in Elisp/emacs hyphenated-words-verbosity. You can tell it wasn't meant to be like this when typing somecmd -h results in multiple pages of option output where you can't see the forrest for the trees, and the command's manpage similarly loosing its usefulness due to sheer size, and frequently not even containing an EXAMPLES section. If it has a manpage in the first place, rather than linking to a nonexistant texinfo page like was practice for the longest time. All of which make you none the wiser so you go to the web for example usage.

Re: Use Long Options in Scripts

#29

Post by nine_k »

mplanchard wrote: post #19
dosourcenotcode wrote: post #14

Agree that long options should be used. But there is one caveat to consider: portability. Sadly to this day not all BSD distributions have GNU style long options. And the ones that now do only got them fairly recently. So if you want portability you have to use short options as you weep with a bottle of vodka in hand.

Not trying to spam this thread with praises of nix, because it does have its own problems, but it certainly solves the portability problem. Four years in to using it at work for dev environments across mac (x86 & ARM) and various linuxes and can’t imagine going back. I also always make dev environment definitions for my open source projects, so even if people aren’t using nix, there is at least a record of what tools…

Does nix work well on BSD-derived Unices? In particular, the most widespread of them, macOS?

Re: Use Long Options in Scripts

#30

Post by tasuki »

wahern wrote: post #6

Please DO NOT mix string interpolation and command execution, especially when a command is processed through the shell. Whatever your language, use a list-based or array-based execution API that passes arguments straight through to execv(2), execvp(2), etc, bypassing the shell.

Why not?
Post reply on HN