Use long flags when scripting • Hacker News Board

Re: Use long flags when scripting

#131

Post by PeterisP » Tue, Feb 05, 2013, 8:55 PM UTC

ralph wrote: post #72

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…

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.

Well, but maybe that's the point of the original post - it is talking about maintenance of shell scripts; so that implies the following:

1) It is not a command that someone "uses", it's a script written by a programmer to be run for a business task or an end user quite likely may not "use Unix" (by your definition) ever.

2) The script goal most likely is not to make Unix work for you - it was originally written to make Unix do task X for you; but the goal/question in the OP is how to make that program more maintainable. Maintainability is an important goal, and to achieve that it's definitely acceptable to mutilate the way you usually do one-off tasks manualy.

3) The shell script is written for non-shell-script users - it's quite likely some glue for a system where 99.9% is in other languages, and the maintenance guys will specialize in those languages, and may not "use Unix" in their daily tasks at all. It's very common and reasonable to write all your code on a Win or Mac computer and then have it deployed to some linux server; and most companies currently do have separate ops teams (which would "use Unix" every day) and developer teams, which might "use Unix" once a month or less, even if the end binaries run on Unix.

Re: Use long flags when scripting

#132

Post by aidenn0 » Wed, Feb 06, 2013, 7:18 AM UTC

rlpb wrote: post #125

YokoZar wrote: post #95

Earlier quoted context omitted.

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.

> ...they're going to be engineers of more modern things... Have you read TAOUP? The entire Unix philosophy hinges around the shell, since the shell is the tool that lets you glue different pieces together. The shell is not outdated. If you live entirely within one language ecosystem, then you may be tempted to consider the shell an afterthought, and make all services available via API calls instead. But this is inef…

But a lot of the defaults in the bourne shell and various posix utilities are wrong. One example: space as a field separator is clearly the wrong default, since it's nearly impossible to not find file-names with spaces in them these days.

Re: Use long flags when scripting

#133

Post by ralph » Wed, Feb 06, 2013, 10:38 AM UTC

PeterisP wrote: post #131

ralph wrote: post #72

Earlier quoted context omitted.

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.

Well, but maybe that's the point of the original post - it is talking about maintenance of shell scripts; so that implies the following: 1) It is not a command that someone "uses", it's a script written by a programmer to be run for a business task or an end user quite likely may not " use Unix" (by your definition) ever. 2) The script goal most likely is not to make Unix work for you - it was originally written to m…

The OP says to use long-options at all times when not at the command prompt. All this other stuff is a scenario you're placing around it to try and justify it.