why Unix?

[Steven Schveighoffer]

On Tue, 07 Apr 2009 15:58:34 -0400, grauzone <none at example.net> 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