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

Use long flags when scripting

thechangelog.com

Post reply on HN
Print view View original

91–100 of 133 posts

Re: Use long flags when scripting

#91

Post by peatfreak »

dasil003 wrote: post #85
karl_gluck wrote: post #70

Earlier quoted context omitted.

I completely agree. I use various flavors of Unix every day at work, and I can only identify half of the flags mentioned at the root comment. This reminds me of the whole "replace" debacle [1] a couple weeks back, where the power nerds jumped all someone who wrote a bit of code to simplify common tasks. It's hard to understand how some people think flexing their arcane knowledge in everyone's face makes them look goo…

I'm all for being nice, but I think you are missing the point. It's not about flexing knowledge for ego's sake, that's entirely beside the point. No, the source of Unix nerd's retort is the realization that a small set of simple, standardized and very sharp tools performs better over time than an ever-increasing set of intuitive tools to suit a narrow use case. This is not to disparage anyone for writing something li…

> a small set of simple, standardized and very sharp tools

This may have been true(r) twenty or thirty years ago, but in a contemporary Unix installation, it is not true at all.

The set of tools is often NOT small (there are thousands of them); they are NOT simple (two examples: 1. the ls man page and the huge number of options it takes; 2. shell quoting rules); they are NOT standardized (I regularly run into incompatibilities between BSD-derived and GNU tools, for example, the -E option for grep); and they are NOT sharp.

In summary, the whole "small tools that one thing only, but that do that one thing well" thing is a stupid, outdated mantra that may have made more sense many years ago, but not anymore. For some reason, people keep on blindly believing it even though it bears no relation to the reality of modern Unix programming.

Re: Use long flags when scripting

#92

Post by Someone »

qu4z-2 wrote: post #86
jhdevos wrote: post #84

Earlier quoted context omitted.

Or even better: # Get my IP address by checking dyndns.org curl -s checkip.dyndns.org | grep -Eo '[0-9\.]+' When reading the script, you want to know what it does, not what each character in it does. Using long flags actually hinders that by adding clutter; you have to parse a much longer line to know what it does. Adding a functional commend and then using the clean short flags is IMHO a much better way.

Or, even better: # Get my IP address by checking ifconfig.me curl -s ifconfig.me The less work you have to do, the better :) NOTE: If you visit ifconfig.me with your browser you get an html page full of text, but with the curl useragent it just returns the ip-address

That also introduces a dependency on ifconfig.me.

If your script contains four or five such 'less work you have to do', I bet it breaks within a year.

Re: Use long flags when scripting

#93

Post by stouset »

Someone wrote: post #92
qu4z-2 wrote: post #86

Earlier quoted context omitted.

Or, even better: # Get my IP address by checking ifconfig.me curl -s ifconfig.me The less work you have to do, the better :) NOTE: If you visit ifconfig.me with your browser you get an html page full of text, but with the curl useragent it just returns the ip-address

That also introduces a dependency on ifconfig.me. If your script contains four or five such 'less work you have to do', I bet it breaks within a year.

All of the above scripts had external dependencies.

Re: Use long flags when scripting

#94

Post by qu4z-2 »

Someone wrote: post #92
qu4z-2 wrote: post #86

Earlier quoted context omitted.

Or, even better: # Get my IP address by checking ifconfig.me curl -s ifconfig.me The less work you have to do, the better :) NOTE: If you visit ifconfig.me with your browser you get an html page full of text, but with the curl useragent it just returns the ip-address

That also introduces a dependency on ifconfig.me. If your script contains four or five such 'less work you have to do', I bet it breaks within a year.

Obviously that's a consideration, but this script has removed a dependency on checkip.dyndns.org. You could make the case that that's more likely to stay up, which is a valid decision.

Alternatively, you could create a "whereami" that returns the ip, and use that in your scripts. If ifconfig.me goes down for good, you have to change the url in one place. I'm sure you'll cope.

Re: Use long flags when scripting

#95

Post by YokoZar »

rlpb wrote: post #67
sirclueless wrote: post #66

Earlier quoted context omitted.

I'm a 4th year student in a well-respected CS program, I have used linux off and on for over three years now, and I would consider myself perfectly capable of maintaining a shell script using any of the utilities you mention. However, without checking the man pages I could not tell you the behavior of the -n flag for sed, the -dc flags for tr, the -f flag for awk, or the -tr flags for ls, and I only have a guess as t…

> This is not the bread and butter of programming... This is, however, the bread and butter of shell programming. > ... "tr --delete --complement"... And, likewise, I'm not sure of the meaning of --delete and --complement, but I do understand "tr -dc". I'd have to look up --delete and --complement to work out what they're the equivalent of.

These days I think it's clear that the dominant use case for shell scripts is not a full time responsibility but rather edge work for deploying/installing code written in other languages. Most people looking at shell code aren't going to be shell masters, they're going to be engineers of more modern things that have to look at the shell script for some reason.

Re: Use long flags when scripting

#96

Post by ralph »

spc476 wrote: post #90
ralph wrote: post #71

Earlier quoted context omitted.

Unix is in no way perfect, for that look to Plan 9. ;-) But just as one should try and understand the idioms and style of a programming language rather than write Pascal in it regardless, so one should try and embrace Unix then suffer and learn from its warts rather than write VMS DCL in it. And yes, brevity is pretty fundamental to its early culture. Unix was created by mathematicians and scientists that were using…

Unix was developed on a system with a 110 baud teletype. On such a system, brevity was the path to sanity (seriously, imagine programming on a manual typewriter that only supported 10 characters per second). VMS was written later, with a faster interface. Also, you didn't need to specify the entire long option, you only needed to type enough to disambiguate between "/all" and "/almostall" (for instance).

The constraints of the time shouldn't be confused with their recognition of the power of notation.

Also, based on the poor advice of this thread's subject, surely one should always write /almostall in one's DCL script for clarity and to lessen the chance of ambiguity as the command evolves? grep's -i is only ever going to mean -i.

VMS died, DCL was often ridiculed, its over-verbose style was a part of that. Its lack of power played a larger part.

Re: Use long flags when scripting

#97

Post by danielvinson »

rlpb wrote: post #67
sirclueless wrote: post #66

Earlier quoted context omitted.

I'm a 4th year student in a well-respected CS program, I have used linux off and on for over three years now, and I would consider myself perfectly capable of maintaining a shell script using any of the utilities you mention. However, without checking the man pages I could not tell you the behavior of the -n flag for sed, the -dc flags for tr, the -f flag for awk, or the -tr flags for ls, and I only have a guess as t…

> This is not the bread and butter of programming... This is, however, the bread and butter of shell programming. > ... "tr --delete --complement"... And, likewise, I'm not sure of the meaning of --delete and --complement, but I do understand "tr -dc". I'd have to look up --delete and --complement to work out what they're the equivalent of.

"This is, however, the bread and butter of shell programming."

This is really old-fashioned thinking. The people who have been in this industry for 10+ years all grew up without computers - and thus had to memorize all of the flags, obscure shell commands, and weird regular expression. What was taught in school back then was to do things perfectly the first time, because CPU cycles were expensive, and bugs were time consuming.

The generation that graduated from college about 2 years ago is the first one that had universal access to a search engine since they knew how to use a computer. This generation (and all future ones for the rest of time) sees memorizing things like this as more of a waste of mental space. What is taught in Universities now is problem solving, research, and larger concepts. There is very little straight memorization, and almost zero programming by hand/whiteboard programming. No current college grad will be able to write a shell script without reference material, but every college grab should be able to write any simple script in less than 5 minutes with Google.

Re: Use long flags when scripting

#98

Post by nathanstitt »

Flimm wrote: post #88
nathanstitt wrote: post #24

A secondary benefit not mentioned in the article is immutability. Long flags on a command line utility should never change. Short flags may be modified between major versions of a utility, which would break scripts. Of course this is just a convention, and I'm sure it's not followed 100%. I'll take whatever protection I can get though.

Neither long flags or short flags should change meaning. I'm not sure where you got the idea that short flags do.

You now, I'm really not sure where I picked that up. It's always been my understanding that it was acceptable to change the short flags on a utility as part of a new major version. Not that you should change 'em capriciously, but that it wasn't the end of the world if you did.

Of course, I can't find any references to back me up on that, so you may very well be correct.

Re: Use long flags when scripting

#99

Post by ralph »

danielvinson wrote: post #97
rlpb wrote: post #67

Earlier quoted context omitted.

> This is not the bread and butter of programming... This is, however, the bread and butter of shell programming. > ... "tr --delete --complement"... And, likewise, I'm not sure of the meaning of --delete and --complement, but I do understand "tr -dc". I'd have to look up --delete and --complement to work out what they're the equivalent of.

"This is, however, the bread and butter of shell programming." This is really old-fashioned thinking. The people who have been in this industry for 10+ years all grew up without computers - and thus had to memorize all of the flags, obscure shell commands, and weird regular expression. What was taught in school back then was to do things perfectly the first time, because CPU cycles were expensive, and bugs were time…

They probably think they invented sex too. ;-)

Memorisation isn't the issue. Knowing the tools available and their options is. That comes with study. Unix command line is a boon for problem solving and experimentation, just go and read Jon Bentley's _Programming Pearls_. One can't Google for what one doesn't realise can be done.

Re: Use long flags when scripting

#100

Post by zxtang »

nathanstitt wrote: post #98
Flimm wrote: post #88

Earlier quoted context omitted.

Neither long flags or short flags should change meaning. I'm not sure where you got the idea that short flags do.

You now, I'm really not sure where I picked that up. It's always been my understanding that it was acceptable to change the short flags on a utility as part of a new major version. Not that you should change 'em capriciously, but that it wasn't the end of the world if you did. Of course, I can't find any references to back me up on that, so you may very well be correct.

"GNU grep 2.12 changes behavior of recursion options, breaks existing scripts": http://news.ycombinator.com/item?id=4295681
Post reply on HN