os.system()

[Joerg Schuster]

Hello,

code like

os.system(command)

only works for some values of 'command' on my system (Linux). A certain
shell command (that *does* run on the command line) does not work when
called with os.system(). Does anyone know a simple and stable way to
have *any* string executed by the shell?

Jörg Schuster

 

[Diez B. Roggisch]

only works for some values of 'command' on my system (Linux). A certain

shell command (that *does* run on the command line) does not work when
called with os.system(). Does anyone know a simple and stable way to
have *any* string executed by the shell?

Showing us what commands actually fail would certainly help.

 

[Joerg Schuster]

Well, I can give you the string, but that will not help:

transduce abc info_dic comp_dic input_file output_file

For copy right reasons, I am not allowed to give you the program
transduce.

But here are some facts about transduce:

- it is written in C
- it takes an alphabet file (abc) and two automata files (info_dic and
comp_dic) as input and applies the automata files to the input file.

 

[Heiko Wundram]

Showing us what commands actually fail would certainly help.

Actually, this sounds like the subshell isn't getting an alias that the normal
interactive shell has. Maybe because ~/.bashrc isn't read on os.system(), or
something of the like? This depends largely on your default system settings,
and especially on /etc/profile.

You might check whether the command that works in the interactive shell is an
alias by typing

heiko@heiko ~ $ alias
alias ls='ls --color=auto'
heiko@heiko ~ $

This shows all currently set aliases, and at least on Gentoo, the above alias
is set in ~/.bashrc, and thus isn't set when os.system() is called. This
means that the output from running ls in an interactive shell is colorized,
whereas running os.system("ls") from Python is not colorized, although
TERM="xterm" in os.environ, and thusly in the subshell spawned using
os.system, and ls could colorize the output using VT100 escape sequences.

All the above explanations assume that your default shell /bin/sh is the
Bourne Again Shell, but all other "higher shells" such as the (T)C-Shell and
the Korn-Shell support command aliasing too, in some way or another, and will
suffer from the same quirks.

And, btw., it'll help if you read the commented start-up files (at least on
Gentoo and SuSE (IIRC) they are very well commented) and the bash man-page,
they explain pretty clearly which initialization files (~/.bashrc,
~/.bash_profile, /etc/profile, /etc/bash/bashrc, and several others) get
executed when and where, depending on whether a shell is a login shell (your
normal interactive shell), or not (spawned by os.system, for example).

Hope this explanation helps!

--
--- Heiko.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQBCLFZhf0bpgh6uVAMRAuGcAJ4j6O9rC56JRZxyIofNPvqp/NHtjACeJf5q
nySvFSVFx++9iU5XYuzEaT8=
=kWmz
-----END PGP SIGNATURE-----

 

[Heiko Wundram]

Well, I can give you the string, but that will not help:

transduce abc info_dic comp_dic input_file output_file

Several variables like PATH "normally" get reset even when running a non-login
subshell to the standard values from /etc/profile (on Gentoo /etc/env.d/*),
so I guess that you're just having a problem finding the executable for
transduce if that program isn't installed in a path which is always on $PATH.

At least I know this behaviour from some older versions of SuSE; Gentoo with
bash 3.0-r8 and baselayout 1.11.9-r1 does as I would presume and doesn't
reset it (there goes my example). What you might try:

export PATH="/does/not/exist:$PATH"
echo $PATH
--- Path here ---
python--- Path here, different? ---

and check whether they are any different. You could also do this for other
important variables, such as LD_LIBRARY_PATH. But, all of this is stabbing in
the dark, maybe you can just send the actual error message along next time.

HTH!

--
--- Heiko.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQBCLFoTf0bpgh6uVAMRAvMLAJ9+L9B/gaZPriJJNWJAnmesW+Pp0wCfcSLH
Pdsjmd5mL2Z0F1Zi6ZRDGec=
=mmAz
-----END PGP SIGNATURE-----

 

[Joerg Schuster]

Several variables like PATH "normally" get reset even when

running a non-login subshell

It seems that this has been the problem. I guess your tip saved me a
lot of time. Thanks a lot.

Joerg

 

[Joerg Schuster]

Several variables like PATH "normally" get reset even when

running a non-login subshell

It seems that this has been the problem. I guess your tip saved me a
lot of time. Thanks a lot.

Joerg

 

[gene.tani]

mod subprocess, if you're on 2.4:

http://docs.python.org/whatsnew/node8.html

 

[Nick Craig-Wood]

os.system(command)

only works for some values of 'command' on my system (Linux). A certain
shell command (that *does* run on the command line) does not work when
called with os.system(). Does anyone know a simple and stable way to
have *any* string executed by the shell?

The command is exectued through the shell, eg

$ ps axf
5121 ? S 0:00 rxvt
5123 pts/77 Ss 0:00 \_ bash
5126 pts/77 S+ 0:00 \_ python
5149 pts/77 S+ 0:00 \_ sh -c sleep 60 > z
5150 pts/77 S+ 0:00 \_ sleep 60

Things to check
1) quoting, python vs shell
2) PATH - check PATH is set the same in shell / python
3) check the whole of the environment

Also if you are using 2.4 check the subprocess module

 

[Richie Hindle]

[Nick]

$ ps axf
5121 ? S 0:00 rxvt
5123 pts/77 Ss 0:00 \_ bash
5126 pts/77 S+ 0:00 \_ python
5149 pts/77 S+ 0:00 \_ sh -c sleep 60 > z
5150 pts/77 S+ 0:00 \_ sleep 60

Wow, good feature of ps - thanks for the education!

I learn something valuable from comp.lang.python every week, and most of
it has nothing to do with Python.