|
|

# Shell programming

## Shell programming

Posted Dec 8, 2012 22:44 UTC (Sat) by davidescott (guest, #58580)
In reply to: Shell programming by nix
Parent article: Quotes of the week

> Rather than 'looking up' what xargs -L does, just do 'xargs --help' and it tells you (not that that is much harder than 'man xargs').

In what way is "xargs --help" not "looking it up"?

> Rather than agonizing over what factor does, try 'factor 16' and 'factor 17' (one obvious prime, one obvious non-prime) and it is instantly obvious.

Again I know what factor does (its in the name), what I don't know is that the output format is "INPUT: N1 N2 ... Nk". So I did exactly as you described (except I used 4 and 7).

There is nothing particularly complex about looking things up like this, and I had to look some things up for ruby as well (its been a few years since I have used it heavily). The key difference is that ruby has functions like "numeric.prime?" which (following standard naming convention) is a test if the numeric is prime, and has a standard obvious boolean return value.

The shell variant of this was a rather convoluted test if the output of "factor" was "N: N" which is a rather indirect way of testing if a number is prime. One could reasonably suspect that "factor" 7 would output "7: 1 7" or that factor 8 would output "2^3" or "2,2,2". There is no apriori reason to believe that factor should output the input number followed by the non-unit factors in increasing order (and separated by ":" and " ").

That is one of the advantages of a programming language. Real datatypes make it easier to guess what a function might return (factor() should return an array of prime factors [sorting and the unit are open questions]), and the subsequent manipulation of those objects is usually sufficient to say what kind of object was returned. If my test for primality of x was:
> (x.factor().length()==1)
Then it is clear that factor() returns an array of factors not including 1. In addition the standardized syntax makes it easier to guess what the functions might be.

Now at the expense of portability I could write a program /usr/bin/prime and simplify the shell script. I might even be able to write something like ruby's group_by in shell but it stretches the meaning of "shell" to say that such a script is "standard *nix shell."

Shell programming

Posted Dec 9, 2012 17:44 UTC (Sun) by nix (subscriber, #2304) [Link]

Hm. I hate to point it out, but your 'easy to read' Ruby one-liner was and remains utterly incomprehensible to me, full of thoroughly opaque punctuation, probably just as incomprehensible as the shell equivalent was to you: the presence of the occasional comprehensible word does not help much. The last time I saw that much nested foo().bar().baz().quux() was when building menus using Borland's Turbo Vision library. It is very much not intrinsically easier to follow than pipelines: at least with pipelines you know that what is being transported is text with a print syntax that you can easily examine, rather than some intricate datatype which you have to look up the various functions to figure out.

Your entire argument boils down to 'things that are familiar to me are intrinsically easier to read for everyone than things that are not familiar to me', which is not at all valid.

I'd agree that for larger programs, the shell is hardly ideal: datatyping is worthwhile -- but for quick one-liners to answer quick questions, it's exactly as valid as a bunch of other vaguely-scripty languages. Ruby is not magically better just because you know it better than the shell (and your claim that more people know Ruby than know the shell is unsupported, and to me sounds dubious in the extreme).

Shell programming

Posted Dec 9, 2012 19:01 UTC (Sun) by davidescott (guest, #58580) [Link]

> Ruby is not magically better just because you know it better than the shell

Never wrote that. In fact wrote something much the opposite of that

> (and your claim that more people know Ruby than know the shell is unsupported, and to me sounds dubious in the extreme).

Never wrote that.

> but for quick one-liners to answer quick questions

Not what this discussion was about.

> Your entire argument boils down to 'things that are familiar to me are intrinsically easier to read for everyone than things that are not familiar to me', which is not at all valid.

Your entire argument seems to be based on making up stuff and attributing it to others. There seems little reason to respond.

Shell programming

Posted Dec 9, 2012 23:20 UTC (Sun) by nix (subscriber, #2304) [Link]

No, it's based on not looking upthread to see who wrote what. Feel free to interpret 'you' as 'collective you' if you wish :)

Shell programming

Posted Dec 10, 2012 0:12 UTC (Mon) by Baylink (guest, #755) [Link]

> Your entire argument boils down to 'things that are familiar to me are intrinsically easier to read for everyone than things that are not familiar to me', which is not at all valid.

Exactly.

But the point you make immediately above, which was essentially: debugging is easier because you can merely lop off the end of the pipeline and *look at the data on the terminal*, is the really important one to me.

The best language for anything is very often *the one your programmer understands best*, as that is the one in which s/he'll be most efffective.

Shell programming

Posted Dec 18, 2012 12:25 UTC (Tue) by wookey (subscriber, #5501) [Link]

I think this is the nub of it.

I write stuff in shell because I know how to. After many years I've learned how to deal with many of the horrible things that go wrong, and with a couple of hours of dicking about can usually get what I wanted.

As with others if I know there will be a lot of data manipulation then I'll use perl instead, and know just enough to do that. I avoid writing in python because I don't know how, and worse don't know how to fill in the gaps.

If I'd started writing python 20 years ago things might be different (and I might be more productive - I like shell but I'm not going to claim that it's a _nice_ language)

Shell programming

Posted Dec 10, 2012 0:47 UTC (Mon) by dlang (subscriber, #313) [Link]

the pipe based approach has the wonderful property that it's trivial to truncate the 'program' at any point and see the output at that stage (with normal tools like head/less/wc/etc)

In fact, I normally build up the monster pipe shell programs iteratively this way, one chunk at a time.

Shell programming

Posted Dec 10, 2012 2:17 UTC (Mon) by davidescott (guest, #58580) [Link]

> it's trivial to truncate the 'program' at any point and see the output at that stage

So will interactive ruby (or python for that matter).

> In fact, I normally build up the monster pipe shell programs iteratively this way, one chunk at a time.

Same way I write long ruby chains.

The only difference is that Ruby passes objects and shell passes text.