On Monday 07 March 2005 14:10, Diez B. Roggisch wrote: > 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
[EMAIL PROTECTED] ~ $ alias
alias ls='ls --color=auto'
[EMAIL PROTECTED] ~ $
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.
pgpEIm4nKNAgd.pgp
Description: PGP signature
-- http://mail.python.org/mailman/listinfo/python-list
