no habla bash muy bien...
John Chambers
jc at trillian.mit.edu
Thu Jan 29 13:35:04 EST 2004
miah mutters:
| http://www.tldp.org/LDP/abs/html/
| Advanced Bash Scripting Guide
|
| GNU AWK users guide
| http://www.gnu.org/software/gawk/manual/gawk.html
|
| Agreed though that you can tie yourself in knots with bash(or sh).. Though its often handy for little things. As well, you'll never see initscripts written in Perl or Python, or atleast you shouldnt =)
Why not? If you can rely on your customers' systems having perl or
python (perhaps because they came with the CD that you had them
install), then there's no reason not to use them.
A couple years ago, a friend who worked at a software firm (which one
isn't really relevant) told about this happening there. The software
guys decided to quietly include perl in their distribution. The only
thing the installer did was check for perl, and if not, install it.
Then it exec'd the real install script, which was written in perl.
He said that you could practically hear the sighs of relief as one
engineer after another realized that they'd never have to write
another shell script.
He also said that after a while, they added code to the the installer
to do the same installation of tcl and python. This produced a bit
more debate, but it meant that they could pick up tools in those
popular languages and include them easily. And soon after that, all
the programmers were finding excuses to use all three languages, so
they could get them on their resumes. Eventually the debate settled
down on the relative merits and demerits of each language. The
general concensus was that, since none was best at everything, the
right approach was to continue to use all three. And I'd bet that by
now, php is also on the list.
The unix "Bourne" shell was originally intended as a rather simple
tool for packaging frequently-used sets of commands. It wasn't
intended as a real programming language. It was also a demo that a
command language didn't have to be hard-wired into the OS, and this
was a radical idea in the early 70's. The idea was that, by moving
all user interaction out into an executable program, people would be
encouraged to experiment and come up with good languages. There was
no reason at all to have just one, of course, and with time we would
expect a number of different command and scripting language to
develop, for different classes of users and tasks. This is pretty
much what has happened.
More information about the Discuss
mailing list