calling ksh script from python

[ronan_boisard]

hi all,

I'm trying to call ksh script from python.
I have a file (toto.env) with a scirpt looking like:

-- begin ---
#!/bin/ksh
#
export TOTO_ENV=/home/toto
-- end ---

I call it from python like that:
-- begin ---
import commands
commands.getstatusoutput('. toto.env')
-- end ---

but it always return an error saying:
sh: TOTO_ENV=/home/home: is not an identifier

doesn anyone know why ?
no matter what I use (popen,system...) it's always the same error...
if I directly try to do
commands.getstatusoutput('export TOTO_ENV=/home/toto')
it's the same error...
and what about this sh primpt in the error message, can't I use ksh
script ?

thanks for any help

ronan

[Donn Cave]

In article <11*********************@g14g2000cwa.googlegroups. com>,
ro***********@yahoo.com wrote:
....

I call it from python like that:
-- begin ---
import commands
commands.getstatusoutput('. toto.env')
-- end ---

but it always return an error saying:
sh: TOTO_ENV=/home/home: is not an identifier

doesn anyone know why ?
....

and what about this sh primpt in the error message, can't I use ksh
script ?

Yes and no. You can expect system(), popen() et al. to
invoke the standard UNIX shell, "sh", so you must supply
an expression that will be correctly executed by that shell.
That expression can execute a program written in another
language - for example, 'ksh toto.env' or just './toto.env'
if you have made it executable and it starts with #!/bin/ksh.
That's really the best way to invoke a script.

Meanwhile, it might be worthwhile to reconsider the use
of ksh here, if you have any choice in the matter. Ksh
is fine for interactive use, but has some unfortunate
flaws as a programming shell, and due to proprietary issues
one commonly encounters an alternative implementation that's
even worse. On most modern platforms, sh will have a pretty
good programming feature set, and will be more reliable
(especially if it isn't just ksh by another name.)

Donn Cave, do**@u.washington.edu

[Cameron Laird]

In article <do************************@gnus01.u.washington.ed u>,
Donn Cave <do**@u.washington.edu> wrote:

[Paul McNett]

Cameron Laird wrote:

Infidel. While I sure feel that way about csh(1), it
surprises me you'd criticize ksh(1) so. 'Fact, 'mong
all the *sh-s, I *recommend* ksh for programming. May-
be the two of us see things differently.

I keep wondering how difficult it would be to make a Python shell that
exposes all of Python but also includes some builtin commands such as
cd, mkdir, etc., that are just names bound to os.chdir, os.mkdir..., and
is smart enough to take a given command from the user and try to do a
os.system() on it based on the path. IOW, I'd love to have all of Python
available as my unix shell, while still doing shell-type stuff such as
traversing directories, launching applications, etc.

There's likely a project that does this already that I'm just unaware of.

--
Paul McNett
http://paulmcnett.com

[Fernando Perez]

Paul McNett wrote:

Cameron Laird wrote:

Infidel. While I sure feel that way about csh(1), it
surprises me you'd criticize ksh(1) so. 'Fact, 'mong
all the *sh-s, I *recommend* ksh for programming. May-
be the two of us see things differently.

I keep wondering how difficult it would be to make a Python shell that
exposes all of Python but also includes some builtin commands such as
cd, mkdir, etc., that are just names bound to os.chdir, os.mkdir..., and
is smart enough to take a given command from the user and try to do a
os.system() on it based on the path. IOW, I'd love to have all of Python
available as my unix shell, while still doing shell-type stuff such as
traversing directories, launching applications, etc.

There's likely a project that does this already that I'm just unaware of.

yes, there is:

planck[~]> ipython -p pysh
Welcome to pysh, a set of extensions to IPython for shell usage.
help(pysh) -> help on the installed shell extensions and syntax.

Python 2.3.4 (#1, Feb 2 2005, 12:11:53)
Type "copyright", "credits" or "license" for more information.

IPython 0.6.15 -- An enhanced Interactive Python.
? -> Introduction to IPython's features.
%magic -> Information about IPython's 'magic' % functions.
help -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.

IPython profile: pysh
fperez@planck[~]|1> cd test
fperez@planck[~/test]|2> ls
argv.py* cf.py div.py exit.py* lcomp.py sanner.py* times.sh*
ast.tcl* data error.py* foo.old pplot2.py* scopes.py* t.py
avg.py* die.py err.py foo.py pplot.py* splot.py vars.py
bar.py div.c err.pyc inspectbug.py pylabug.py strings.py visex.py
bar.pyc div.f exit2.py* inter.py ramptest.py* tgp.py xplot.py*
fperez@planck[~/test]|3> $$a=ls e*py
fperez@planck[~/test]|4> a
<4> ['error.py', 'err.py', 'exit2.py', 'exit.py']
fperez@planck[~/test]|5> for f in a:
|.> if len(f)>6:
|.> wc -l $f
|.>
64 error.py
2 exit2.py
10 exit.py
fperez@planck[~/test]|6> Exit
Cheers,

f

[Cameron Laird]

In article <ma**************************************@python.o rg>,
Paul McNett <[e-mail]> wrote:

[Donn Cave]

In article <ob************@lairds.us>, cl****@lairds.us (Cameron Laird)
wrote:

In article <do************************@gnus01.u.washington.ed u>,
Donn Cave <do**@u.washington.edu> wrote:
.
.
.

Meanwhile, it might be worthwhile to reconsider the use
of ksh here, if you have any choice in the matter. Ksh
is fine for interactive use, but has some unfortunate
flaws as a programming shell, and due to proprietary issues
one commonly encounters an alternative implementation that's
even worse. On most modern platforms, sh will have a pretty
good programming feature set, and will be more reliable
(especially if it isn't just ksh by another name.)

.
.
.
Infidel. While I sure feel that way about csh(1), it
surprises me you'd criticize ksh(1) so. 'Fact, 'mong
all the *sh-s, I *recommend* ksh for programming. May-
be the two of us see things differently.

----* Portability
"ksh" means
* -* ksh88 * *(AIX 5.2, ...)
* -* ksh93 * *(MacOS X 10.4, ...)
* -* pdksh * *(Redhat Linux, NetBSD 2.0, ...)
* -* (nothing) (Older BSDs, ...)
* Plus, I have seen differences that evidently come from
* build options that can be exercised by the platform vendor.
* For example, the effect of ksh -p varies, and "echo" seems
* to mimic the behavior of sh on its host platform.

----* Reliability
Interactive ksh users depend on ENV=$HOME/.kshrc for
per-shell transient customization, like aliases, but unlike
bash or even csh, this file isn't loaded for an interactive
shell startup, but any shell startup.* So if I write a program
in ksh, and you run it, my script is exposed to your aliases.

----* Feature over-saturation
The Bourne shell is pretty fair for UNIX programming, all
things considered, but it's a miserable programming language
in a more general context, I mean you can hardly do worse
(except, as you mention, csh.)* The Korn shell does nothing
to really improve the language, yet it adds myriad features
as if catering to some kind of full time ksh programmer.* And
that's ksh88, I understand 93 takes it to a whole new level.

Modern shells - ash, bash, etc. - implement*a*POSIX/XPG4
shell specification that has plenty of these*features.* That's
the obvious target for shell scripts written today. Programs
that can't get by with that should probably be written in some
other language - Python comes to mind, for example, though I
usually try awk first for simplicity of deployment.

** *Donn Cave,*do**@u.washington.edu

[ronan_boisard]

thanks for your input...
well I just find out that modifying environment through ksh call is not
possible (can't get the new evironment back to python). I think the
best thing to do is to translate all my ksh to pure python... I thought
that I could re-use some stufff, but I guest I'm going to translate
everything...

[Thorsten Kampe]

* Cameron Laird (2005-06-02 18:08 +0100)

In article <do************************@gnus01.u.washington.ed u>,
Donn Cave <do**@u.washington.edu> wrote:

Meanwhile, it might be worthwhile to reconsider the use
of ksh here, if you have any choice in the matter. Ksh
is fine for interactive use, but has some unfortunate
flaws as a programming shell, and due to proprietary issues
one commonly encounters an alternative implementation that's
even worse. On most modern platforms, sh will have a pretty
good programming feature set, and will be more reliable
(especially if it isn't just ksh by another name.)

.
Infidel. While I sure feel that way about csh(1), it
surprises me you'd criticize ksh(1) so. 'Fact, 'mong
all the *sh-s, I *recommend* ksh for programming. May-
be the two of us see things differently.

http://groups-beta.google.com/group/...578e8d95137a3c

[Donn Cave]

In article <8l*****************************@40tude.net>,
Thorsten Kampe <th******@thorstenkampe.de> wrote:

* Cameron Laird (2005-06-02 18:08 +0100)

In article <do************************@gnus01.u.washington.ed u>,
Donn Cave <do**@u.washington.edu> wrote:

Meanwhile, it might be worthwhile to reconsider the use
of ksh here, if you have any choice in the matter. Ksh
is fine for interactive use, but has some unfortunate
flaws as a programming shell, and due to proprietary issues
one commonly encounters an alternative implementation that's
even worse. On most modern platforms, sh will have a pretty
good programming feature set, and will be more reliable
(especially if it isn't just ksh by another name.)

.
Infidel. While I sure feel that way about csh(1), it
surprises me you'd criticize ksh(1) so. 'Fact, 'mong
all the *sh-s, I *recommend* ksh for programming. May-
be the two of us see things differently.

http://groups-beta.google.com/group/...578e8d95137a3c

Well, that certainly must just about say it all.

It's nice to see that the author knows rc and es, which
are indeed a couple of very much better designed shells.

I am not sure I agree with him so much on shell programming
in general, but it depends on what his point really may be.
For sure, it's good to be aware of those things, at any rate.

Donn Cave, do**@u.washington.edu

[Donn Cave]

In article <11*********************@z14g2000cwz.googlegroups. com>,
ro***********@yahoo.com wrote:

thanks for your input...
well I just find out that modifying environment through ksh call is not
possible (can't get the new evironment back to python). I think the
best thing to do is to translate all my ksh to pure python... I thought
that I could re-use some stufff, but I guest I'm going to translate
everything...

Right, that's true - more generally, no process can modify
another's environment.

Donn Cave, do**@u.washington.edu

[Magnus Lycka]

ro***********@yahoo.com wrote:

thanks for your input...
well I just find out that modifying environment through ksh call is not
possible (can't get the new evironment back to python).

I thought about this a few days ago. Can't you copy it like this:

import os

env_rows = os.popen('. some.script > /dev/null; env).readlines()
for row in env_rows:
var, val = row.split('=',1)
os.environ[var]=val