Indeed there are 4! But have been using ShellPkg for several months now.
So you are suggesting that I set the CWD variable in my current program
before calling ShellExecute()? Clearly I can't use
gEfiShellProtocol->SetEnv(EnvKey, EnvVal, Volatile) because this would set
the *shell's* current working directory? (why does this function exist?
Shouldn't it be taboo for a child program to affect the parent's
environment?)
Now there is an Env argument for ShellExecute where a separate copy of the
environment could be built by the popen code from prg2's env for prg3,
which would not mutilate the envronments for prg1 or prg2 - but I can't get
it to work as of yet...
here's a picture:
(prg1) Shell2.efi (shell starts python via a command line)
(prg2) Python.efi (python's os.popen() - which I'm attempting to
implement - builds the Env for prg3
and
replaces the cwd value with a new
value
to run a new shell command lets say
'dir')
(prg3) Shell2.efi (second shell executing 'dir > tmpfile')
If python uses gEfiShellProtocol->SetEnv() it will change (prg1)'s cwd, no?
This is the only thing that makes sense - but I'm having to mess with the
StdLib a lot to support the POSIX idea of an individual cwd per program.
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
