On Tue, 07 Apr 2009 15:58:34 -0400, grauzone <[email protected]> wrote:
The complete language reference (including index) has 102 pages.
Considering that it's probably more formal than the sh description in
your Nutshell book, it's not that much compared to sh.
The nutshell description is formal and complete for bourne/korn shell (it
does not have any bash extensions), which mostly sufficient for everything.
Regarding the syntax: OK, that's probably about tastes. But I still like
it more than, say, the funny way how you have to use the find program.
It depends on what you want to get used to. I agree it's about tastes.
And regarding using it as an user shell: there's an interactive
command line interpreter.
if you type ls, does it work, or do you have to type __run__("ls") or
whatever?
If you'd go and use python as a shell, you had a ls() function. It would
return an array of names. Instead of text garbage like ls does. How can
you reliably list all files, without getting incorrect results (like
when there's a line break in a file), or falling into the escape trap
(your script, that takes the ls output, interprets part of the filename
as program)?
You can use the shell's filename wildcard feature to get an array of
filenames that are properly delineated.
For example:
for file in *
do
echo filename is: $file
done
Will print out individual files, including ones that have escape sequences
or spaces. echo re-interprets newlines as spaces, so you won't see those
exactly, but the file variable does contain the exact characters.
Prove me wrong, show me a python script that does the same thing, and
we'll see if it's clearer.
Sorry, I'm not going to write a script to prove someone else wrong over
the internet. And my point was anyway to extend a _real_ scripting
language by adding simple functions as substitutes for common UNIX
programs like rm, ln etc.
what happens when you want to run non-standard programs, then do you have
to run them using a python function? I imagine that simply interpreting
any symbol that doesn't match a library function as a command to run might
result in a lot more collisions in python than in sh.
sh scripts aren't very reliable either. I remember that script that
invoked another program. That other program produced some warning, and
the script interpreted it as normal output.
Oh yeah, that *must* have been the scripting language's fault. I have
bugs in my D programs too, must be because D sucks?
Interpreting data as programs are the "buffer overflows" of scripting
languages. Nothing to defend here. The script in question was relatively
large, and probably written by some guru, if that helps.
All I was saying is that bugs can occur in any programming or scripting
language. Blaming the language isn't the answer (although complicated
scripts in any language you are not familiar with certainly can be hard to
debug).
Yeah, or doing something like "rm -rf this/directory /". Or deleting all
hidden directories.
That demonstrates a particularly disgusting issue with the shell: escape
hell.
One time, I unzipped a file, and the files were encoded with some weird
multibyte garbage. How do I delete the files? I had to start a GUI
program to do this. In Python, with an appropriate extension library,
that would have been ls() followed by a rm(ls[1]). How to do this in sh?
I'm assuming you had an issue because those files were intermixed with
files you wanted to keep?
for file in *
do
echo Do you want to remove file $file?
read answer
if [ "$answer" = "y" ]
then
rm "$file"
fi
done
or something like that would have worked.
-Steve
