[Discuss] Scripting languages (was Re: rsync v. cp in data migration)

[richard.pieri at gmail.com (Richard Pieri)]

Derek Martin wrote:
> Typically on those systems, the on-disk echo command behaves as does
> the shell built-in, though some systems may have both versions
> installed in different paths... 

Which I lump under "slight tweak". It's easy enough changing "echo" to
"/usr/bin/echo", and there are indirections that can be used to make a
commonly used Bourne script more easily portable:

ECHO=/usr/bin/echo
$ECHO foo


> We witnessed some of the problems that this causes when Debian
> switched from using bash to dash as its rc script shell.  That switch
> broke many things (though many of those things were caused by scripts
> using bash-isms, not all of them were).  These days, on many Unix

BASH is not Bourne. It, like the Korn Shell, is a superset of Bourne,
and if you use the nonstandard extensions then you lose the portability
that Bourne provides. This is precisely why I avoid BASH for scripting.
I use it interactively but actual scripting is as vanilla as I can get.


> And believe it or not, I have actually come across installed Unix
> systems where the system shell was csh, and there was no

I highly doubt that. No UNIX that I've ever seen -- and I've seen plenty
-- uses anything but /bin/sh as the system shell. Similarly, I've seen
attempts at changing the system shell to CSH. It rendered the system
unbootable. YMMV on this last; it's possible to make it work, mostly.


> Still, these days, it's hard to find a Unix system that doesn't have
> either Perl or Python installed, or at least have them as a
> vendor-provided option.  And of course, if you're the sysadmin, you
> can install them yourself, from sources if need be.

This is true. But it does me no good if the system is in a state that
does not permit installing foreign software.

-- 
Rich P.