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

61–70 of 133 posts

Re: Use long flags when scripting

#61

Post by natefinch »

This is very good advice. You may not be maintaining your script later on, maybe someone who is new to unix will be asked to go change it. Having the intention much more obvious will save them some hassle. Hell, even someone who uses unix a lot may not know every flag of every command you use. With no other context, it's pretty hard to know if -r is recursive or reverse sort, or something else entirely.

And god forbid you think you know which one it is and end up being wrong... you might not realize until it hits production (scripts not always being the best tested things in the world).

Yes, they might not be supported on BSD.. they're also not supported on Windows, what's your point? It's a lot more likely you'll have to read and/or change the script 6 months down the line when you've forgotten everything about what's in it, then you'll all of a sudden need to run your script on BSD when you've never had to in the past (obviously if portability is a requirement from te beginning, then that changes how you write the script from the start).

Re: Use long flags when scripting

#62

Post by jsaxton86 »

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\.]+'

Re: Use long flags when scripting

#63

Post by [deleted] »

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\.]+'

[deleted]

Re: Use long flags when scripting

#64

Post by Firehed »

logn wrote: post #43
eli wrote: post #40

Earlier quoted context omitted.

I think the goal should be clarity, not conservation of characters. And I think the escaped dot is clearer (the author's intent is obviously to include a dot in the range). I do think it's funny that you said "There isn't and shouldn't be any hard fast rule for this" and then one comment later said my approach is "wrong" :) (EDIT: oops, that wasn't you -- Sorry!)

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 that's not the point. I'm talking about real-world code, not idealistic academic nonsense)

Re: Use long flags when scripting

#65

Post by fusiongyro »

skrebbel wrote: post #51
ralph wrote: post #42

This is very bad advice. I won't thank you for making me check GNU grep's --ignore-case is precisely the same as the very well-known, POSIX'd, -i. And ditto for all the other verbiage that clutter and obfuscate the script's intent. Short options should be used where they're the more typically known and standardised. Long options are for the unusual. grep -iv sed -n tr -dc awk -f ls -tr comm -23 tail -n

The difference is that with long flags, even someone without 10 years of POSIX experience knows what's going on. The long example on the OP's article makes a lot of sense to me, even though I'm primarily a Windows user. At the same time, for instance, I've no idea what the -tr flag to ls does, even though I use ls often enough.

There's something to be said for the automatic recognition that something like "tar zxvf foo.tar.gz" has, versus the verbose "tar --gzip --extract --verbose --file foo.tar.gz." It feels terribly ponderous to do the latter. That said, when I see a command I don't recognize immediately ('sed -n' comes to mind for some reason) I would benefit from seeing the long option. The other side of the coin is that once I go look up 'sed -n' I'll probably remember it for next time.

Re: Use long flags when scripting

#66

Post by sirclueless »

ralph wrote: post #42

This is very bad advice. I won't thank you for making me check GNU grep's --ignore-case is precisely the same as the very well-known, POSIX'd, -i. And ditto for all the other verbiage that clutter and obfuscate the script's intent. Short options should be used where they're the more typically known and standardised. Long options are for the unusual. grep -iv sed -n tr -dc awk -f ls -tr comm -23 tail -n

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 to what comm -23 does.

This is not the bread and butter of programming, where everyone worth a damn should be able to decipher "int i = 10;" even if it's not their brand of syntax. There are people who are perfectly capable of understanding and maintaining a piece of software that uses "tr --delete --complement" but would be dumbfounded when confronted with "tr -dc" until they looked it up.

Re: Use long flags when scripting

#67

Post by rlpb »

sirclueless wrote: post #66
ralph wrote: post #42

This is very bad advice. I won't thank you for making me check GNU grep's --ignore-case is precisely the same as the very well-known, POSIX'd, -i. And ditto for all the other verbiage that clutter and obfuscate the script's intent. Short options should be used where they're the more typically known and standardised. Long options are for the unusual. grep -iv sed -n tr -dc awk -f ls -tr comm -23 tail -n

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.

Re: Use long flags when scripting

#68

Post by rohit6223 »

I write a lot of shell scripts as part of my daily Sys Admin work. In my opinion, the author gave us choice to write less codes & readable code by using short flags for most of the command functionalities.

Consider something like this: $ rsync -qaogtHr example.com:/opt/data/ /home/backup/

1. Elaborating all the short flags into long ones will increase readability by explaining this statement but at the cost of more lines of code.

2. All UNIX commands have options to combine short flags. For eg: ls -l -t -r ./ can be written as: ls -ltr ./ This also helps in reducing code. Writing less code helps in managing it more easily.

Long options may help beginners, but once they get comfortable, Short flags may seem more readable!!

Re: Use long flags when scripting

#69

Post by sabraham »

fusiongyro wrote: post #65
skrebbel wrote: post #51

Earlier quoted context omitted.

The difference is that with long flags, even someone without 10 years of POSIX experience knows what's going on. The long example on the OP's article makes a lot of sense to me, even though I'm primarily a Windows user. At the same time, for instance, I've no idea what the -tr flag to ls does, even though I use ls often enough.

There's something to be said for the automatic recognition that something like "tar zxvf foo.tar.gz" has, versus the verbose "tar --gzip --extract --verbose --file foo.tar.gz." It feels terribly ponderous to do the latter. That said, when I see a command I don't recognize immediately ('sed -n' comes to mind for some reason) I would benefit from seeing the long option. The other side of the coin is that once I go look…

http://xkcd.com/1168/

Re: Use long flags when scripting

#70

Post by karl_gluck »

saint-loup wrote: post #57
ralph wrote: post #53

Earlier quoted context omitted.

You are not a Unix user. You don't know Unix's commands and their common options. If the article is aimed at you and people like you that read your scripts then it's fine but it's akin to commenting "dir /w" in a DOS batch file to explain its purpose. 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. BTW, a month of using…

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 good. They trash efforts to make software more accessible and maintainable so they can pretend to be king of a tiny hill.

[1] http://news.ycombinator.com/item?id=5106767

Post reply on HN