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

81–90 of 133 posts

Re: Use long flags when scripting

#81

Post by hkolek »

Firehed wrote: post #64
logn wrote: post #43

Earlier quoted context omitted.

It's only clear for people who don't really understand regexes. For people with knowledge of them, it's more ambiguous as to whether a slash is being matched or used to escape. It reminds me of commenting the end of your for loops, } //end for ... it's clear for people who come from Python and don't know Java but that's not who we should be helping.

Are you writing this for yourself or to share? If the latter, optimize readability for people who don't understand regexes. As for commenting the end of loops - that too just improves readability, especially in long functions. If your editor doesn't show invisible characters, it can be easy to lose track if some indent is part of the 'i' loop or the 'j' loop, for example (yes, that can indicate a bigger problem, but…

Why? So my grandma can read my code? That's not the way to enlightenment if you program in a professional setting.

Re: Use long flags when scripting

#82

Post by nwatson »

npsimons wrote: post #41

While it is generally a good idea to write readable code, it is also true that long flags are not universally supported, and the short flags don't always have the same meanings (or even exist!) across different systems. This is an interesting conundrum. As has been pointed out, POSIX specifies standard options (which are all short): http://news.ycombinator.com/item?id=5165058 But these are not universally supported:…

Make sure you have GNU versions installed and in your PATH. Write to those.

Re: Use long flags when scripting

#83

Post by bobbydavid »

jsaxton86 wrote: post #62
npsimons wrote: post #41

While it is generally a good idea to write readable code, it is also true that long flags are not universally supported, and the short flags don't always have the same meanings (or even exist!) across different systems. This is an interesting conundrum. As has been pointed out, POSIX specifies standard options (which are all short): http://news.ycombinator.com/item?id=5165058 But these are not universally supported:…

A much simpler solution is to comment your code: # Invoke curl in silent mode (-s), pipe the output to grep # and use an extended regex (-E) to only show the resulting # digits (-o: only print matching text, not the whole line): curl -s checkip.dyndns.org | grep -Eo '[0-9\.]+'

I agree with ralph that these comments are annoying because I have to waste time reading them (what if they contain something important?) but they offer me nothing (I already know these flags).

If you still prefer putting these hints in comments, I would rephrase your comments in a way that they are easily identifiable as useless, so I can stop reading them right away. For example:

# -s flag: puts curl in silent mode.

# -E flag: puts grep in extended regex mode.

# -o flag: prints only matching text.

curl -s thingy.thing | grep -Eo '[0-9.]+'

An additional win: comments are slightly more future proof. When the comments inevitably become outdated, you'll now see:

# -E flag: puts grep in extendex regex mode.

curl -s thingy.thing | egrep -o '[0-9.]+'

which is better because the comment is now merely irrelevant instead of actively wrong.

Re: Use long flags when scripting

#84

Post by jhdevos »

jsaxton86 wrote: post #62
npsimons wrote: post #41

While it is generally a good idea to write readable code, it is also true that long flags are not universally supported, and the short flags don't always have the same meanings (or even exist!) across different systems. This is an interesting conundrum. As has been pointed out, POSIX specifies standard options (which are all short): http://news.ycombinator.com/item?id=5165058 But these are not universally supported:…

A much simpler solution is to comment your code: # Invoke curl in silent mode (-s), pipe the output to grep # and use an extended regex (-E) to only show the resulting # digits (-o: only print matching text, not the whole line): curl -s checkip.dyndns.org | grep -Eo '[0-9\.]+'

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.

Re: Use long flags when scripting

#85

Post by dasil003 »

karl_gluck wrote: post #70
saint-loup wrote: post #57

Earlier quoted context omitted.

I'm sorry, but this is terribly pedantic. The world isn't divided between deep experts of a technology and everyone else. Case in point: me, a moderately tech-savvy person. My main computer is a Mac and I'm a casual user of bash. I struggle to get things done every time I have to do something more complicated than "show me the files of this folder, even the hidden ones, even in the subfolders, then dump them in a .tx…

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 like that replace project. You certainly don't deserve scorn for that, and if that tool finds a healthy place in your utility belt then all the better.

However if you do a lot of work with text files on unix then I think inevitably you will reach a tipping point where it is in fact easier to learn and remember a limited set of commands and flags than it is to remember the ideal mountain of simpler commands that do all the things you regularly do in a more beginner-friendly fashion. If you want to argue against "arcane" unix tools being better you have to confront this argument head-on without assuming the proponent is an insecure, anti-social neckbeard out to prove his own superiority.

Re: Use long flags when scripting

#86

Post by qu4z-2 »

jhdevos wrote: post #84
jsaxton86 wrote: post #62

Earlier quoted context omitted.

A much simpler solution is to comment your code: # Invoke curl in silent mode (-s), pipe the output to grep # and use an extended regex (-E) to only show the resulting # digits (-o: only print matching text, not the whole line): curl -s checkip.dyndns.org | grep -Eo '[0-9\.]+'

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

Re: Use long flags when scripting

#87

Post by marklit »

npsimons wrote: post #41

While it is generally a good idea to write readable code, it is also true that long flags are not universally supported, and the short flags don't always have the same meanings (or even exist!) across different systems. This is an interesting conundrum. As has been pointed out, POSIX specifies standard options (which are all short): http://news.ycombinator.com/item?id=5165058 But these are not universally supported:…

# define all the 'magic letters here' (perhaps some if statements for various platforms):

CURL_FLAG_SILENT=s

# Then call them here:

curl -$CURL_FLAG_SILENT ifconfig.me

Re: Use long flags when scripting

#88

Post by Flimm »

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.

Re: Use long flags when scripting

#89

Post by Zancarius »

ralph wrote: post #75
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…

Is that a signed integer or unsigned? How many bits? What's the lifetime of i? One needs to know more than is inferred by a few characters. Seeing the long options just makes you think you understand what it's doing without knowing what it does. The latter comes from study; there's no short-cut. Fortunately, Unix is worthy of study unlike for example the Windows API.

I can't help but agree with this sentiment. Generally, if the operator doesn't understand what a command line option does and isn't willing to read the man page, they're open to a whole slew of unpleasant surprises (although I think this applies to many things, not just userland utilities). Long options simply provide a false sense of security and may not always do what someone thinks they're supposed to do. Worse, they may not always be available as others have pointed out insofar as the BSD flavors of specific tools provide.

I like what you said about "study." There truly is no shortcut for reading documentation available with the system, and assuming by inference what a command is supposed to do based on its options when neither the command nor options are understood just seems to be horribly, horribly bad practice in my mind.

Re: Use long flags when scripting

#90

Post by spc476 »

ralph wrote: post #71
skrebbel wrote: post #58

Earlier quoted context omitted.

You have a point about the -t and -r flags, but, > Unix users should not following the article's advice, they should be embracing Unix's style and ethos; it's part of what's made it such a success. I always wonder why this is taken so religiously? You're not the first person to write a comment like this, so please don't take it too personally. But is it not possible that the Unix style and ethos is mostly great, but…

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).

Post reply on HN