baffling os.system behavior - differs from command line

[Donn Cave]

In article <604fc0ca.0401141750.4dc57782 at posting.google.com>,
 even at pondie.com (Ben Floyd) wrote:
...
> The command is Slackware's package creation utility, makepkg. It uses
> the
> current working directory as package source and takes a filename as an
> argument to output the newly created package to. Makepkg is
> essentially
> a tarball creator, wrapped in a nice command. Simple stuff. Here is my
> code:
> 
> I have a for loop that reads a file list, like so:
>         pkg_srcdir = '/packages_source'
>         pkg_dir = '/packages_tgzs'
>         ls = os.listdir(pkg_srcdir)
> 
>                 for name in ls:
>                         build_src = pkg_srcdir + '/' + name
>                         new_filename = pkg_dir + '/' + name + '.tgz'
> 
>                         # Valid directory?
>                         if not os.path.isdir(build_src):
>                                 sys.exit("\nInvalid directory \'" + pkg_srcdir + "\'\n")
> 
>                         # Go into the new directory
>                         try:    os.chdir(build_src)
>                         except  os.error, value:
>                                 sys.exit("\nInvalid directory: \'" + build_src + "\': " + value[1])
> 
>                         # I then execute the command on each result, like so:
>                         # new_filename is correctly assembled, which i can verify
>                         # from printing it out on each loop iteration
>                         os.system('/sbin/makepkg --chown n --linkadd y ' + new_filename)

Well, I don't know.  In casual inspection I don't notice
anything obviously wrong, but then for all I know this
isn't the exact code that has the problem anyway.  What
I could suggest is substitute your own shell script for
makepkg, something that prints out its arguments, current
working directory and whatever you think might be interesting.
The object is to find out exactly what you're asking makepkg
to do, since that is evidently a problem.

Actually a Python program might be a little better, because
"print sys.argv" gives you less ambiguous information than
"echo $*", more like "for arg do echo $arg; done" but on
one line.

The two usage points that occur to me are
1. chdir() affects Python module path resolution.  If you
   chdir to a directory with an "os.py", that would be an
   obvious if unlikely problem, but also some installations
   rely on Python's library finding heuristics in a way
   that is kind of fragile.  I may be wrong about that,
   I don't even want to think about wasting time on this
   misguided feature.

2. system() can be replaced with spawnv() for an increase
   in command parameter list reliability.  What if some
   file has spaces?  In spawnv(), you don't care, but in
   system() it's your job to quote it.  This is also a
   security related issue.

   Donn Cave, donn at u.washington.edu