> From: andrelst <[EMAIL PROTECTED]>
> Subject: Re: [plug] Learning Korn shell (was Re: Getting list of
> regular files (with whitespaces) using ls and AWK)
> To: "Philippine Linux Users' Group (PLUG) Technical Discussion List"
> <[email protected]>
>
> On Fri, Jun 13, 2008 at 1:18 AM, Miguel Paraz <[EMAIL PROTECTED]> wrote:
> > I know we had this debate before...
> >
> > .. .but why not just learn Perl, or Python, or Ruby, and script with
> > that? I think using shell scripting + sed + awk is masochistic
> > nowadays.
>
> Migz,
> As discussed few weeks ago, because:
> * Not all systems have perl, python or ruby. Especial with really
> old UNIX systems.
> * You can't just install these programming languages on a whim on
> some systems as Thad alluded to because of audit and compliance
> reasons. I can also vouch the same reasons.
> * Sane programming across the Linux and UNIX systems, if using ksh.
> ksh scripts will run guaranteed on really old machines to the latest
> ones as long as you stick on the ksh88.
>
> Ludwig,
> Additional tips, if you have:
>
> ksh88 - set -o vi # file or subdir completion can be done
> via ESC + \ or ESC + =
> ksh93 - set -o viraw # This will enable file or subdir
> completion ala bash.
> ksh88 or 93 - ESC + / # The best tip! This the search facility of
> ksh. D you just hate it when you have to press the arrow keys 10 times
> to get your command history, change it and run it again? With this,
> you can search the keyword of the command, retype it and run it in
> less time you press that key 10 times... :) This will also work with
> bash with set -o vi.
>
Thanks for the tip, Andre.
Another probable reason of learning is that there are still applications that
uses shell script
as a "glue language" (although some of the script files are in Perl, but these
are add-ons and not
part of the original design). Rewriting it is risky because:
a) The system is already working.
b) Rewriting it means re-retesting it, and it is hard to setup the test
environment (system
test, regression test, etc)
c) There's no guarantee that the new system will work like the old system
(it takes time).
d) Nobody wants to re-write a thousand plus line of shell scripts scattered
in many machines
with variables scattered everywhere (not just in script file, but in files such
.profile and other
config files).
e) There will always be some sort of downtime when one migrate from one
system to another.
f) The moment you modify it, and if things go wrong you'll probably be
responsible for it even
though the changes that you've just made have nothing to do with the "crash".
g) There are systems that are not-so-well documented that the only way you
can re-write it is
to learn how the system works by studying the code. But to understand the code,
you probably need
to learn shell scripting, awk, and sed too even if your goal is just to
re-write the whole system
=)
h) Some of the stuff are well-written (not just working, but the code is
neat, and they served
as good tutorial are examples of how to write code), and you wonder if the new
system will be
easier to maintain at all.
A case for point (f) is there is a x=`expr x + 1` line in the script (ksh)
, and I have second
thoughts on whether to change it to ((x=x+1)), even though the latter is faster
and adheres to
korn shell way of doing things.
Regards,
Ludwig Lim
_________________________________________________
Philippine Linux Users' Group (PLUG) Mailing List
http://lists.linux.org.ph/mailman/listinfo/plug
Searchable Archives: http://archives.free.net.ph
