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

71–80 of 133 posts

Re: Use long flags when scripting

#71

Post by ralph »

skrebbel wrote: post #58
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…

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 it every work day to get stuff down and they recognised and extolled in their writings the power of notation. Imagine maths without superscripts, Σ, etc. So it is with Unix. More wordy notations existed in other OSes at the time, and more noisy commands, e.g. VMS would tell you that "dir/size/owner/prot foo." completed normally, even though that's hopefully the norm. It gets very annoying. :-)

Re: Use long flags when scripting

#72

Post by ralph »

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…

Then you don't use Unix, you merely enter a few canned commands to perform a limited set of actions. You are not making it work for you.

Re: Use long flags when scripting

#73

Post by btilly »

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

We had a very similar discussion over the weekend at http://news.ycombinator.com/item?id=5157215 but with the domain expertise being with non-programmers.

My opinion remains the same as it was there. If you've already gone through the effort of learning the short options, there is no reason not to continue amortizing that effort by making use of them. On the other hand if you have not really learned the short options, it is only worthwhile doing so if you plan to use them enough in the future that it will pay off.

Of course if you are writing code that you expect to be maintained by someone else, aim it at the fluency that you expect to be able to demand at them. Aiming it lower than that will just make things more painful for you. Aiming it higher will make things more painful for them (and the vast majority of the cost of software development is in maintenance, so they matter more than you do in the long run).

Re: Use long flags when scripting

#74

Post by papsosouid »

jerf wrote: post #23
kps wrote: post #9

No. Use standard POSIX flags to invoke standard POSIX functionality, so your scripts don't break when run on a different system.

It's always a cost/benefits analysis. I think for a lot of us, the cost/benefit goes something like this: "Will I ever have to read and modify this script again? Effectively-100% likely. Will this script ever run anywhere that I don't have the GNU toolchain? Effectively-0% likely." It's a no-brainer at that point. If you can't say that second part honestly, reconsider, but a lot of us can.

>Will this script ever run anywhere that I don't have the GNU toolchain? Effectively-0% likely.

That's not the case for most people though. I can't even remember the last time I saw even a tiny project assume the world is all "whatever gnu/linux distro I happen to use". Tons of people use linux distros that aren't ubuntu, tons of people use OSX, tons of people use a BSD.

Re: Use long flags when scripting

#75

Post by ralph »

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…

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.

Re: Use long flags when scripting

#76

Post by npsimons »

skrebbel wrote: post #59
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'll admit, I haven't had to touch OSF/1 in a long time, and I really would prefer to avoid it, but it's not always possible. Even modern systems aren't entirely consistent. As a real world example, I like to setup persistent SSH sessions on my laptop at home and personal smartphone. autossh is a nice solution to this, but it isn't available on my smartphone. To create one command across all environments that will create a persistent SSH connection, I do some OS and hostname detection to determine what I've got to work with, then create an appropriate function (either using autossh, or a more crude version using while). Then my dotfiles work across all platforms and I can keep them synchronized with git. Something like:

  if [ -n `command -v autossh` ]; then
      function ssh_persist {
          autossh -C -o "CompressionLevel 9" $@
      }
  else
      function ssh_persist {
          while true; do
              ssh -C -o "CompressionLevel 9" $@
              sleep 60
          done
      }
  fi
Edit: well, as long as I'm doing this much editing, I might as well make it better. To be sure, this isn't exactly what I actually run :) But it's a fair approximation and it gets my point across.

Re: Use long flags when scripting

#77

Post by ralph »

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

The comment is needless noise that the reader must check for correctness and then determine whether it or the code is the intended behaviour when they differ. The same is unfortunately true of many comments.

BTW, you've probably a bug in your regexp because you like to needlessly and wrongly escape a dot without knowing the regexp syntax you're using. Assuming you don't intend

    $ grep -Eo '[\.]'
that is. :-)

(curl's -s should be accompanied by -S IMHO, and it's brain-damaged in not having that behaviour under the one option.)

Re: Use long flags when scripting

#78

Post by npsimons »

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 don't like commenting the how and what; that's what the code is for. Comments are for "why".

Re: Use long flags when scripting

#79

Post by ralph »

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…

Aside,

    sed -n /re/p
is grep. sed's default is to print every line at the end of the script, -n says not to. Larry Wall rightly had perl(1) inherit -n along with perl's -p.

Re: Use long flags when scripting

#80

Post by james-manning »

At least for scripts that are on github, it seems like this could be potentially tackled by creating a robot that submits pull requests for such scripts, changing the options passed from short to long. For people fine with the change, they could just merge the PR, and for those that don't like it, people still have a long-option version of the script they can check out in the PR.

I've not written a github robot, though, this is just based on my vague understanding from the robots already out there (whitespace, .gitignore, etc), so please correct me if this isn't actually feasible. :)

Post reply on HN