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

51–60 of 133 posts

Re: Use long flags when scripting

#51

Post by skrebbel »

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.

Re: Use long flags when scripting

#52

Post by ralph »

pacala wrote: post #25

Add auto-complete to the command line and everyone will start using long form without the need to beg. Imperfectly remembering the flag spelling is a rather large annoyance, short flags avoid this problem at the cost of crypticism, autocomplete actually solves it.

This is silly. I can type grep's "-iv" before your auto-complete has enough info entered to complete the first option alone; "--i" would beep, needing a "g" to continue.

Re: Use long flags when scripting

#53

Post by ralph »

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.

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 Unix should have a Unix user knowing what ls's -t and -r flags do, along with -a and -l they're some of its most commonly used.

Re: Use long flags when scripting

#54

Post by dfox »

Wilya wrote: post #48
njharman wrote: post #39

Earlier quoted context omitted.

No a lot of stuff broke because people depended on implicit rather than being explicit. #!/bin/bash

wilya@home $ /bin/bash zsh: no such file or directory: /bin/bash wilya@home $ which bash /usr/local/bin/bash (Yes, I'm annoyed when I see #!/bin/bash, especially on scripts which are otherwise basic enough to be portable everywhere)

It is still better to write #!/bin/bash for bashism using scripts than #!/bin/sh. I recently had to run sed -i (well, another GNUism) 1s%/sh%/bash% on bunch of customer's scripts to make them work on debian. At least when script wants /bin/bash it is going to fail cleanly (and not in the middle after modifying random things) and with mostly meaningful error.

Re: Use long flags when scripting

#55

Post by npsimons »

webreac wrote: post #46
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:…

I think you fail on two software engineering principles: * http://en.wikipedia.org/wiki/KISS_principle * you should adapt the way you think about programming to the language you are using. This is shell, not Ada.

Unfortunately, taken as a whole (eg, not just blithely ignoring POSIX, or systems that don't support it, or systems that don't support long options), portable shell is a big mess. Keeping it simple would be nice, but may not be possible, depending on your goals ("make everything as simple as possible, but no simpler").

So you want to write some script that will only ever run on systems with GNU utilities installed, and you never ever plan on porting it? Fine. Just do the world (and yourself) a favor and be aware of and admit that fact upfront. And if you're going to break POSIX compatibility anyway, it would be nice if you use the long options for better readability.

Re: Use long flags when scripting

#56

Post by ralph »

6ren wrote: post #44
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 seems that statement wasn't a hard and fast rule. ba dum tish I think everyone should do what they want, including telling others what to do, hypocritically. I prefer not to escape dots in char classes, because escapes make it less readable for me. I know this involves a more complex rule, for where one need not escape, but somehow my mind easily treats character classes as a special case region.

It's not necessarily your choice. [\.] in sed is a two-character character class.

Re: Use long flags when scripting

#57

Post by saint-loup »

ralph wrote: post #53
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.

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 .txt". The obscurity of flags don't help.

Re: Use long flags when scripting

#58

Post by skrebbel »

ralph wrote: post #53
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.

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…

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 there's a few things here and there that could've been better? You seem to imply that a culture that prefers short options is one of the reasons that Unix became a success. I'm not so sure.

In fact, if `dir /w` had a long version of the option, i would've indeed used it. I think it's a shame that most native Windows commands, unlike their Unix counterparts, don't have long versions of switches. But I doubt that that's contributed much to Windows' success.

Re: Use long flags when scripting

#59

Post by skrebbel »

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:…

It really depends on what you're making of course, but for a large set of situations, isn't supporting recent bash on recent Linux/BSD good enough? This way, you got all modern Linux installations, OSX, and Windows through msys(git) covered.

I'm thinking of shared dotfiles, build scripts, deploy scripts. The article you link to mentions SunOS and OSF/1. How bad are the incompatibilities on modern POSIXes only? (note: I really do not know and wouldn't know how to find out)

To compare, how many people would write a web page that supports IE5? Some would, but would you generally advice methods to make IE5-compatible pages in 2013?

Maybe we need a http://caniuse.com for Unixes.

Re: Use long flags when scripting

#60

Post by [deleted] »

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.

[deleted]
Post reply on HN