Live data from Hacker News

Use long flags when scripting (2013)

changelog.com

151–160 of 197 posts

Re: Use long flags when scripting (2013)

#151

Earlier quoted context omitted.

Very annoying. Java HotSpot uses -version , rather than --version , which is even worse. Don't mess with the standard long-form flag!

I get it wrong every damn time. 16 years and counting.

Same! Somehow I also start confusing this with somewhat related tools like gcc. It's rare enough that I need to query these that it's all blurry in my memory again by next time. "huh I guess gcc was that goofy one with just one dash.." Nope.

Re: Use long flags when scripting (2013)

#152
post #78

Earlier quoted context omitted.

As does Python, which drives me crazy. -V is version on Python.

Very annoying. Java HotSpot uses -version , rather than --version , which is even worse. Don't mess with the standard long-form flag!

Long flags are a GNUism, not a "standard" by any means. The closest that comes to a standard in this space are POSIX utility conventions [1].

[1]: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...

Re: Use long flags when scripting (2013)

#154
post #71

Earlier quoted context omitted.

It's a common thing for IT departments or people making enterprise images to put in because they think it makes it safer. I feel it does more harm than good by normalising rm -f when you want to recursively delete a folder, but with CD deployments these days it's less of a deal.

"CD deployments" - Ha, like an "ATM machine"? At first in thought you were describing deployments on compact discs!

CD, continuous deployment, is used to refer to the process not an individual instance like the term ATM. Simply saying "This deployment failed" doesn't convey that it's a deployment that was made through CD but "This CD failed" is also ambiguous as it doesn't indicate whether the process or the conditions particular to a deployment that caused it to fail. Using them both in combination like "CD deployment" seems perfectly valid to me to resolve both ambiguities.

To be fair though they were referring to CD deployment(s), plural, which is a bit redundant and just CD would have done just as well in this case.

Re: Use long flags when scripting (2013)

#155
post #147

Earlier quoted context omitted.

$ tar --help tar: unknown option -- help usage: tar [-]{crtux}[-befhjklmopqvwzHJOPSXZ014578] [archive] [blocksize] [-C directory] [-T file] [-s replstr] [file ...] $

Okay, so your tar is defective[0], and? I can do that too: $ list '#! /bin/sh' 'echo "tar: invalid command" >&2' 'exit 64' >/tmp/tar $ chmod a+x /tmp/tar $ PATH="/tmp:$PATH" $ $ tar -cf a.tar a/ tar: invalid command $ 0: any program that doesn't support --help is defective, which was rather my point.

> 0: any program that doesn't support --help is defective, which was rather my point.

Fair enough. My point was that there's a category of operating systems where long options (including --help) isn't really a thing. You may of course consider them defective, though I'm not sure everybody agrees.

Re: Use long flags when scripting (2013)

#156
I wonder a bit, that those POSIX comments are so far in the bottom of this discussion. I mean, you are loosing portability by using long flags (because it is not standard compliant) and yet it seems to be just a footnote in this discussion...

Re: Use long flags when scripting (2013)

#157
post #118

Earlier quoted context omitted.

Last published in 2018 (and actively being worked on) is not outdated. https://pubs.opengroup.org/onlinepubs/9699919799/ > Sure systems seen try to somewhat be POSIX compliance The mainstream systems you know and use adhere very rigorously to POSIX. GNU Libc, Kernel, Coreutils, ... and their counterparts in BSD Unixes, proprietary Unixes, Cygwin and whatnot all take POSIX seriously. POSIX is very helpful, and smart c…

Larry Wall said It's easier to port a shell than a shell script in 1998 ... 22 years later I still think that holds. https://news.ycombinator.com/item?id=10104203 Although I would agree that there's a slight hole there: you still need to port stuff like coreutils and all the dependencies, which has been done of course. But I'd be happier if something like busybox was actually portable.

I think it's easier to write a portable shell script today than 30 years ago.

The Autoconf system is predicated on the idea that writing a portable shells script is hard, and so we hide the shell programming behind a mountain of M4 macros.

It's not necessarily easier to port a shell script today than 22 years ago, which was not written with portability in mind. There are more shells with more extensions, and then beyond the language concerns, and the environments have exploded. A shell script can easily depend on all sorts of cruft you've never heard of. Oh, just install these five things from the following github repos ...

Re: Use long flags when scripting (2013)

#158

Don't use long flags when scripting, if they have short equivalents, and POSIX only specifies the short equivalents. Even if the stuff will only ever run on one system, the POSIX flags (1) come from a smaller set of options, since POSIX is fairly conservative in its content this area and (2) are generally well known (often three decades old or older). Don't make me read a man page to confirm that "grep --fixed-string…

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

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

Re: Use long flags when scripting (2013)

#159

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.

I think the dot actually gives you issues on Mac? Or something like that. I remember encountering issues with it.

You have to specify a directory for the find on Mac; it's only a GNUism to omit it.

Re: Use long flags when scripting (2013)

#160
post #83
post #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 an…

It's so unfortunate about Bash + Apple. Bash probably deserves to die out, but Apple has really pulled a bait-and-switch on OSX's *nix/bsd underpinnings over the years.

Aren't Apple helping out here by defaulting it zsh?
Post reply on HN