[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: bash vs. python scripts - which one is better?



On 2007-08-09 23:37:52 -0700, Steve Lamb wrote:
> Vincent Lefevre wrote:
> > On 2007-08-09 09:48:54 -0700, Steve Lamb wrote:
> >>     The same in Python but with far greater functionality:
> 
> > and a security hole!
> 
>     And the one liner stopped this how, exactly?

Because the result of a parameter expansion or filename generation is
not interpreted by the shell (unless explicitly told).

> >>         result = os.system("lame -h -b 160 '%s' '%s'" % (file, mp3))
> 
> > Imagine a filename contains: ' `some command`
> 
>     Ok, I'll imagine that.
> 
> >>> import os
> >>> foo = "' `ls -l`"
> >>> os.system("echo '%s'" % foo)
> sh: -c: line 0: unexpected EOF while looking for matching `''
> sh: -c: line 1: syntax error: unexpected end of file
> 512

Yes, because you get:

  echo '' `ls -l`'

which is not valid. Try with:

  foo = "' `ls -l` '"

so that you get:

  echo '' `ls -l` ''

> > In portable POSIX sh, yes. But with superior shells such as zsh, this
> > is trivial. However, for complex transformations, though this can
> > often be written with few characters, this is completely unreadable!
> > (See for instance, the advanced zsh completion functions.)
> 
>     Which is why I strayed away from Perl into Python land.

This is a very subjective argument. One *can* write readable Perl
scripts. Also remember TIMTOWTDI.

> And while zsh is fairly ubiquitous in Linux/BSD land it is still
> shell with the problems that come with it. BTW, in case you feel I
> am coming from Bash land with my anti-shell sentiments...
> 
> {grey@olethros:~} grep grey /etc/passwd
> grey:x:1000:1007:Steve Lamb:/home/grey:/bin/zsh
> 
>     ...been on zsh for years. I love its far superior completion and
> command history. Won't code in it,

Well, for some kinds of code (e.g. those dealing with a sequence of
external utilities), it is better to write a shell script, otherwise
this would mean a sequence of "system" or equivalent. For instance,
here's my script to update Mutt:

------------------------------------------------------------------------
#!/usr/bin/env zsh

# Usage: update-mutt <cvs or hg update options>

source ~/.zshenv
source ~/.zalias

set -e
set -x

cd ~/software/mutt
rm -rf mutt

if [[ -d mutt-hg ]] then
  if host dev.mutt.org > /dev/null; then
    # To create the mutt-hg directory:
    #   hg clone http://dev.mutt.org/hg/mutt mutt-hg
    pushd mutt-hg
    hg pull
    hg update "$@"
    popd
  else
    # Not necessarily a fatal error since the Mutt source could have
    # been updated previously (e.g., before a PPP deconnection).
    echo "Warning! Mutt source cannot be updated by hg pull." >&2
  fi
  cp -R mutt-hg mutt
else
  if host cvs.mutt.org > /dev/null; then
    pushd mutt-cvs
    cvs update "$@"
    popd
  else
    # Not necessarily a fatal error since the Mutt source could have
    # been updated previously (e.g., before a PPP deconnection).
    echo "Warning! Mutt source cannot be updated by CVS." >&2
  fi
  cp -R mutt-cvs mutt
fi

cd mutt
patch -p1 < ~/wd/src/patches/mutt/mutt.patch
cp ~/wd/fr.po/mutt po/fr.po
prepmutt
make -j2
make install
------------------------------------------------------------------------

You can see most commands that have no native equivalent in non-shell
languages: hg, cvs, patch, prepmutt, make (and probably even cp).

> however, not as long as #!/bin/env python is
> around.  And the joy of it is that if a box has zsh chances are high it'll
> have python, too.  ;)

Nope. The first thing I do when I get an account is to install a recent
version of zsh, so that zsh is always installed, but not necessarily
python! :)

Of course, one could also compile python, but with its different
versions which are not compatible, this is annoying, and it takes
too much space on PDAs (my Zaurus has perl and zsh, but not python).

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)



Reply to: