Scripting problem

Frank Leonhardt (m) frank2 at
Wed Oct 18 07:43:48 UTC 2017

On 12 October 2017 00:01:55 BST, Warren Block <wblock at> wrote:
>On Mon, 9 Oct 2017, Paul Pathiakis wrote:
>>> Quoting is sh's biggest weakness. Well, that and lack of basic data
>>> structures, and the weak logical structures, and so on.
>> ### Well, yes and no. I consider it both a strength and a weakness. I
>find sh to be exactly what I think of a scripting language to be...
>glue. I don't
>> expect to write a fully versed program in sh. I wouldn't be using sh
>for that. I find sh to be that 'tool' to use when I want to call other
>tools and
>> utilities. (sed, awk, tr, etc)
>> ### I think people have gone way too far in creating 'scripting'
>languages that are more programming languages than scripting....
>Personally, I tried
>> learning PERL which tries to be everything to regex. The problem?
>Lack of coherence... "I can do this 5 different ways in PERL" Is that
>supposed to be a
>> good thing when all five seem to execute at different speeds, using
>different resources, etc? (apologies to Larry Wall and the rest)
>The multiple domains that are utterly different are not just in Perl. 
>In sh, you can use sed and awk, which have very little overlap.  In 
>fact, you pretty much have to use sed *and* awk, because each is not 
>quite powerful enough to do particular jobs.  Or use Perl, 
>which is a superset of both.
>The trouble with sh is that it is so weak that it takes a lot of code
>accomplish anything. That comes back to haunt the programmer in the
>term, because simpler, shorter programs that use more powerful 
>constructs are much easier to maintain.
>Perl is much-maligned, but every time I rewrite a shell script in Perl 
>it gets shorter and easier to maintain.  Or longer and more powerful. 
>Python and Ruby are similar.
>>> Someone once said that if a script is longer than twenty lines or
>>> it probably ought to be done in a real scripting langugage. That was
>>> me, but Stephen Bourne has also said it. Yes, that Stephen Bourne.
>> ### I'll go off a little on this with kind of a corollary.... No sh
>script should be more than 20 lines, however, I typically will call
>shell scripts from
>> other scripts. But I do agree, if you want to program, use a
>programming language. (IMHO, C is still the best, most powerful
>language around but, again,
>> read a book, talk to the people who are in the know - My 'C' guru is
>a guy who has written code that utterly shocked me in its elegance,
>execution, and
>> simplicity - and the occasional "You can do something like that in
>C?" thoughts running through my head.)
>The distinction between programming and "scripting" has always been 
>artificial to me.  You write a series of instructions for a computer, 
>that's a program.  Give me powerful tools, I'm not interested in doing 
>it the hard way to build character.  I have enough character. What I 
>want back is the time I spend trying to fix sh scripts.

Interesting debate this. Personally I have always regarded sh as a Job Control Language. Probably showing my age.

As such it's intended for controlling jobs written in 'C' (being Unix). All it had to do is put the data in the right place for input, and arrange for the output to end up where it should. In no way should it be used for implementing an algorithm.

Now people are trying to write programs in it. Why? I suspect its because people haven't invested the time to learn a programming language, as it's quicker to find some cunning way of perverting the JCL one problem at a time.

Do spreadsheet macros count as programming? I've seen complete business management systems written in Excel macros. Unmaintainable and flaky, but I'm in awe that anyone did it.

And if I get too sniffy about the use of structured "proper" languages, I think back to the days of assembler and even machine code. Do the primitive building blocks of assembler count as programming? It's hard to argue otherwise, so therefore the primitive building blocks of sh have to count too.

That said, I was really happy when I could start using 'C' in the early 1980's. The perfect blend of convenience and control of the CPU.

You do need to invest the time to learn a compiled language like 'C'. Friendly interpreted languages are considered cheaper to use  because the staff need less training - or assumed to be. I'm not so sure.


Sent from my phone. Please excuse my brevity.

More information about the freebsd-questions mailing list