On Wed, May 09, 2007 at 05:08:33PM -0700, Bob McGowan wrote:
> Douglas Allan Tutty wrote:
> >No wonder I can never figure out what a shell script is trying to do,
> >either way it looks like a cat on a keyboard. Give me python and
> >fortran77 any day.
> >
>
> As I don't use python, I have no direct experience here. I do use Perl,
> however. It is also 'easier' than the shell, assuming you put the
> script in a file.
>
> So, a question: Can python 'run' code directly from the command line,
> as Perl does with the -e option?
>
> perl -e 'while(<>){print}'
Yes, to some extent. Python uses the indentation of the program to
indicate flow. Therefore, if your command is just a string of commands
to run, it works. However, if it involves looping or decision it won't
since python (by design I think) will not do the perlish and bashish
one-liners.
So:
python -c "a=5; print a; b=10/5; print b; print a * b"
works.
>
> for example. If so, you'd have the same quoting issues you have with a
> shell script, since you would need to protect the python part of the
> input from shell interpretation.
>
Yes, understandable, but since such use is literally throw-away code,
there is no future maintenance to consider.
On the other hand, there's no reason to submit to the limits of a
one-liner when you can just as easily type:
python
and enter the python shell where you can do anything you want in python,
indents, import modules, whatever. If you really want, you can operate
the whole system from within the python shell as you would the bash
shell. To make that easier, issue
from os import *
from os.path import *
So that, to run a program, you issue a system call:
system('lynx')
The joy of python is that absolutly nothing is cryptic unless you
want it to be.
> Since the shell is both a command interpreter (runs other applications)
> and a programming language, it gets very complicated when it is working
> with another program that also uses wild cards or regex or simply
> general programming language constructs like parens or braces.
I think that the only such program I use is ls. I don't do sed, awk,
etc, for the same reason I don't program in bash or perl. Its too
cryptic. There is no doubt that regex is very powerful but I just can't
remember it long enough for any code that contains it to be meaningful
and therefore maintainable.
On the other hand, in my __Python_2.1_Bible__ is an example: rgrep.py
that implements the full rgrep utility in 22 lines of python code (plus
comments and doc strings). That code itself is clear and easy to
follow. The user of the program can use regrex if appopriate.
>
> Putting things in a file makes things even easier, assuming the program
> in question will read files (as Perl, python, awk, C, Fortran, Pascal
> ..., do). Unfortunately, this doesn't help a lot with the shell, the
> same problems exist in the shell script file as exist on the command line.
>
The only thing that sh has going for it as a scripting language (other
than its ubiquitousness) is that it is smaller than python. That was
and is a good thing in some situations. However, the difference isn't
that great. /bin/bash is 770k vs python's 1.2m. Python brings in the
pthread library, in addition to those brought in by bash, but that is
once for as many instances as you like. If I were wanting to create my
own NIX distribution, I'd have sh available for compatibility, but all
system scripts would be done in python.
The other nice thing about python is that it is great for prototyping.
My python code looks very similar to Fortran since for reminders I list
(in comments) all the variables I use, its a simple matter to turn them
into declarations. Then its just undoing the indentation, changing
comments, and final touchups.
Doug.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
