cd.exe
Dave Yeo
advice on howto cd from within python). Anyone know of one? I tried
various rexx cmds from Hobbes without success. Bonus if it is
indifferent to path separators, eg / or \
Dave
Steven Levine
at 05:07 AM, Dave Yeo <dave....@gmail.com> said:
Hi,
>I need a cd program that is not the builtin cmd.exe version (or perhaps
>advice on howto cd from within python).
From within python, it's os.chdir() that you are looking for. Since
python is an app and not a shell, this change is only going to persist
until you exit python.
Invoking some other app with os.system() is not going to help you because
python has no way to know what the app did the to current directory.
What exactly are you trying to accomplish?
Steven
--
--------------------------------------------------------------------------------------------
Steven Levine <ste...@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
--------------------------------------------------------------------------------------------
Dave Yeo
> In<0E9Ll.26518$PH1.1720@edtnps82>, on 05/03/2009
> at 05:07 AM, Dave Yeo<dave....@gmail.com> said:
>
> Hi,
>
>> I need a cd program that is not the builtin cmd.exe version (or perhaps
>> advice on howto cd from within python).
>
> From within python, it's os.chdir() that you are looking for. Since
> python is an app and not a shell, this change is only going to persist
> until you exit python.
>
> Invoking some other app with os.system() is not going to help you because
> python has no way to know what the app did the to current directory.
>
> What exactly are you trying to accomplish?
>
> Steven
>
Run a script (located at http://fate.multimedia.cx/running.html) that
has a line like (before some OS/2 mods)
"rm -rf $BUILD_PATH && mkdir $BUILD_PATH && cd $BUILD_PATH &&
$SOURCE_PATH/configure --disable-debug --enable-gpl --enable-postproc
--enable-avfilter --enable-avfilter-lavf --enable-shared
--enable-swscale --prefix=$BUILD_PATH/install-directory && make && make
install",
I needed to change $BUILD_PATH to %BUILD_PATH%, replace mkdir with
mkdir.exe and have now worked around the CD problem by breaking it into
multiple CD commands with no directory separators. I can use ash to run
configure but it fails to build. (k)sh.exe doesn't work for some reason
when invoked from the script though works fine from the command line.
Unluckily stderr and stdout are not displayed.
Dave
Steven Levine
at 01:16 AM, Dave Yeo <dave....@gmail.com> said:
Hi,
>Run a script (located at http://fate.multimedia.cx/running.html) that
>has a line like (before some OS/2 mods)
>"rm -rf $BUILD_PATH && mkdir $BUILD_PATH && cd $BUILD_PATH &&
>$SOURCE_PATH/configure --disable-debug --enable-gpl --enable-postproc
>--enable-avfilter --enable-avfilter-lavf --enable-shared
>--enable-swscale --prefix=$BUILD_PATH/install-directory && make && make
>install",
Depending on python's implementation of Popen, this should just work and
hopefully will use the value of SHELL to invode the command.
>I needed to change $BUILD_PATH to %BUILD_PATH%, replace mkdir with
>mkdir.exe and have now worked around the CD problem by breaking it into
>multiple CD commands with no directory separators.
FWIW, I usually find it less work to do what it takes to keep the build
scripts running under a *nix shell. Typically, I have a 4OS2 script that
sets up the build environment and invokes bash. The script translates
slashes in environment variables when it matters.
>I can use ash to run
>configure but it fails to build. (k)sh.exe doesn't work for some reason
>when invoked from the script though works fine from the command line.
>Unluckily stderr and stdout are not displayed.
Which version of python are you running? Paul's or Andrew's. My python
setup is not quite up to building fate. It may be missing some modules.
However, I hacked the script to the point where it would attempt to invoke
process = Popen(command, shell=True, stdout=PIPE, stderr=PIPE)
Unfortunately this seems to fail for any command I supply. I'll revisit
this later today.
Regards,
Dave Yeo
> In<ylrLl.25483$Db2.15152@edtnps83>, on 05/04/2009
> at 01:16 AM, Dave Yeo<dave....@gmail.com> said:
>
> Hi,
>
>> Run a script (located at http://fate.multimedia.cx/running.html) that
>> has a line like (before some OS/2 mods)
>> "rm -rf $BUILD_PATH&& mkdir $BUILD_PATH&& cd $BUILD_PATH&&
>> $SOURCE_PATH/configure --disable-debug --enable-gpl --enable-postproc
>> --enable-avfilter --enable-avfilter-lavf --enable-shared
>> --enable-swscale --prefix=$BUILD_PATH/install-directory&& make&& make
>> install",
Actually the --enable-swscale needs to be removed from above as swscale
has been depreciated.
>
> Depending on python's implementation of Popen, this should just work and
> hopefully will use the value of SHELL to invode the command.
That's what I hoped but it exits within seconds and never does the rm -f
$BUILD or anything else.
Quickly looking at the source of Python 2.5.2 it seems to use %COMSPEC%
to load a shell (Modules\posixmodule.c)
>
>> I needed to change $BUILD_PATH to %BUILD_PATH%, replace mkdir with
>> mkdir.exe and have now worked around the CD problem by breaking it into
>> multiple CD commands with no directory separators.
>
> FWIW, I usually find it less work to do what it takes to keep the build
> scripts running under a *nix shell. Typically, I have a 4OS2 script that
> sets up the build environment and invokes bash. The script translates
> slashes in environment variables when it matters.
I tried running it under ash and ksh, didn't seem to make much difference.
>
>> I can use ash to run
>> configure but it fails to build. (k)sh.exe doesn't work for some reason
>> when invoked from the script though works fine from the command line.
>> Unluckily stderr and stdout are not displayed.
>
> Which version of python are you running? Paul's or Andrew's.
Paul's newest seems to support most things, We went over some of the
failures and he fixed them (same fixes were needed for Mercurial)
> My python
> setup is not quite up to building fate. It may be missing some modules.
> However, I hacked the script to the point where it would attempt to invoke
>
> process = Popen(command, shell=True, stdout=PIPE, stderr=PIPE)
>
> Unfortunately this seems to fail for any command I supply. I'll revisit
> this later today.
It works for me if the full path is specified and is not a built in
command eg /bin/rm -rf %BUILD %% /bin/mkdir %BUiLD% work. I added some
touch commands for debugging and even cd works if there are no path
separators. I'm possibly missing some quoting.
>
> Regards,
>
> Steven
>
Dave
Steven Levine
at 11:51 PM, Dave Yeo <dave....@gmail.com> said:
Hi,
>Actually the --enable-swscale needs to be removed from above as swscale
>has been depreciated.
OK.
>Quickly looking at the source of Python 2.5.2 it seems to use %COMSPEC%
>to load a shell (Modules\posixmodule.c)
You should be able to override COMSPEC at the command line to force ash or
sh or whatever.
>I tried running it under ash and ksh, didn't seem to make much
>difference.
Logically, the shell should not matter if you get the quoting right. It's
just that cmd.exe is so brain dead, almost any moderately complex command
line is sure to confuse it.
>> Which version of python are you running? Paul's or Andrew's.
>Paul's newest seems to support most things, We went over some of the
>failures and he fixed them (same fixes were needed for Mercurial)
Perhaps, that's my problem. I was testing with Andrew's build. I noticed
something in Paul's readme about fixes for Popen and perhaps Andrew's
build does not have these.
>It works for me if the full path is specified and is not a built in
>command eg /bin/rm -rf %BUILD %% /bin/mkdir %BUiLD% work.
I suspect once I install Paul's build, I will get the same results. You
might check if the shell=TRUE argument is really being honored. That would
explain the issues with paths and built in commands.
What I did to test was
CONFIGURATION_LIST = {
-1: "d:/usr/bin/4os2.exe",
}
This should have invoked a 4os2 session that I could see, unless the
stdin/stdout redirects caused it to die before I could see it.
>I added some
>touch commands for debugging and even cd works if there are no path
>separators. I'm possibly missing some quoting.
You really should not need any, but you might try using ^ to escape the &.
Perhaps, cmd.exe is not stripping quotes as expected.
FWIW, it will be good to get fate running. I tried the current mplayer
build on a couple of the video files and some trapped.
Dave Yeo
> In<6cLLl.25629$Db2.18649@edtnps83>, on 05/04/2009
> at 11:51 PM, Dave Yeo<dave....@gmail.com> said:
>
> Hi,
>
>> Actually the --enable-swscale needs to be removed from above as swscale
>> has been depreciated.
>
> OK.
>
>> Quickly looking at the source of Python 2.5.2 it seems to use %COMSPEC%
>> to load a shell (Modules\posixmodule.c)
>
> You should be able to override COMSPEC at the command line to force ash or
> sh or whatever.
>
>> I tried running it under ash and ksh, didn't seem to make much
>> difference.
>
> Logically, the shell should not matter if you get the quoting right. It's
> just that cmd.exe is so brain dead, almost any moderately complex command
> line is sure to confuse it.
>
>>> Which version of python are you running? Paul's or Andrew's.
>
>> Paul's newest seems to support most things, We went over some of the
>> failures and he fixed them (same fixes were needed for Mercurial)
>
> Perhaps, that's my problem. I was testing with Andrew's build. I noticed
> something in Paul's readme about fixes for Popen and perhaps Andrew's
> build does not have these.
Besides Andrews builds not having sqlite3 support they also have this
problem (quoting Paul)
fwiw - the default EMX code uses DosCreatePipe for Posix_Pipe() - libc
select()
definitely doesn't work on this socket - it seems neither does EMX select()
For libc Python, my fix is to use socketpair() for posix_pipe()
>
>> It works for me if the full path is specified and is not a built in
>> command eg /bin/rm -rf %BUILD %% /bin/mkdir %BUiLD% work.
>
> I suspect once I install Paul's build, I will get the same results. You
> might check if the shell=TRUE argument is really being honored. That would
> explain the issues with paths and built in commands.
>
> What I did to test was
>
> CONFIGURATION_LIST = {
> -1: "d:/usr/bin/4os2.exe",
> }
>
> This should have invoked a 4os2 session that I could see, unless the
> stdin/stdout redirects caused it to die before I could see it.
I just tried this, something in Python is eating CPU, see below. I saw a
brief flash as the VIO window title changed from python to 4os2 and
back. After a couple of minutes I used Watchcat to look at the processes
and there was 2 instances of python, then 2 instances of sh.exe then 1
instance of 4os2 listed with consecutive PID numbers.
Exiting watchcat took over a minute to redraw the desktop so I killed
python.
At least it does look like it is honouring the SHELL environment variable.
Earlier I used this line in fateconfig.py
-1: "/bin/rm -rf %BUILD_PATH% && /bin/mkdir %BUILD_PATH% && cd fate &&
cd build && sh /fate/fate/source/configure && make",
and configure actually ran (at least most all the makefiles directory
structure etc were created in build. make didn't run. This took 45
minutes of 100% CPU compared to a couple of minutes from a command line
with 90-100% CPU.
I tried to do the same a few times and it never worked again.
I also used sqlitebrowser to look in fate-sqlite-database and stdout and
stderr were empty, at that the only entry was the command line.
I'd like to know how to see stdout and stderr.
>
>> I added some
>> touch commands for debugging and even cd works if there are no path
>> separators. I'm possibly missing some quoting.
>
> You really should not need any, but you might try using ^ to escape the&.
>
> Perhaps, cmd.exe is not stripping quotes as expected.
>
> FWIW, it will be good to get fate running. I tried the current mplayer
> build on a couple of the video files and some trapped.
Some of the traps may of been caused by GCC 4.3.3. Running make test on
FFmpeg I saw at least one sigsegv with 4.3.3 which is gone now with 4.4.
Also some other errors which I believe were rounding errors are also
gone with GCC 4.4.
I'd imagine KO will be doing another release with GCC 4.4
Fate would also be nice to catch build errors, the last couple of
patches I sent have been simple #include <sys/time.h> as we need it for
struct timeval. We have also had problems with the ever changing build
system.
I think FFmpeg and MPlayer are very important now for OS/2 to have.
>
> Steven
>
Dave
Dave Yeo
> Earlier I used this line in fateconfig.py
> -1: "/bin/rm -rf %BUILD_PATH% && /bin/mkdir %BUILD_PATH% && cd fate &&
> cd build && sh /fate/fate/source/configure && make",
Setting SHELL=ash.exe allows the original line to run.
Unluckily ash doesn't set $PWD so the build will eventually break.
Also the BASE_PATH in fateconfig.py needs a drive letter or else lxlite
will error out with unknown command when passed a pathname starting with /
Dave
Dave Yeo
> Setting SHELL=ash.exe allows the original line to run.
Well it ran once but didn't pass configure any options. Since it also
fails right away :(
Dave
Steven Levine
at 04:40 AM, Dave Yeo <dave....@gmail.com> said:
Hi,
>I just tried this, something in Python is eating CPU, see below.
It's probably the code that trying to read/write the pipes.
>Earlier I used this line in fateconfig.py
>-1: "/bin/rm -rf %BUILD_PATH% && /bin/mkdir %BUILD_PATH% && cd fate &&
>cd build && sh /fate/fate/source/configure && make",
>and configure actually ran (at least most all the makefiles directory
>structure etc were created in build. make didn't run. This took 45
>minutes of 100% CPU compared to a couple of minutes from a command line
>with 90-100% CPU.
This is another indication that the pipe logic probably needs some tuning.
Perhaps a DosSleep if the peek says there's no data.
>I'd like to know how to see stdout and stderr.
You could try changing
process = Popen(command, shell=True, stdout=PIPE, stderr=PIPE)
to dump stdout and stderr to files. You also change the command stream
tail to be
sh /fate/fate/source/configure >stdout.txt 2>stderr.txt && make
>patches I sent have been simple #include <sys/time.h> as we need it for
>struct timeval. We have also had problems with the ever changing build
>system.
This is always going to be an issue. The only real solution I can see is
to try to keep the toolchain up to date.
Steven Levine
at 05:43 AM, Dave Yeo <dave....@gmail.com> said:
>Setting SHELL=ash.exe allows the original line to run.
>Unluckily ash doesn't set $PWD so the build will eventually break.
Can you use ksh instead?
>Also
>the BASE_PATH in fateconfig.py needs a drive letter or else lxlite will
>error out with unknown command when passed a pathname starting with /
Hmmm. What if you quote the path? This might prevent lxlite for thinking
it has a switch to process.
Dave Yeo
> In<KlQLl.26855$PH1.11352@edtnps82>, on 05/05/2009
> at 05:43 AM, Dave Yeo<dave....@gmail.com> said:
>
>> Setting SHELL=ash.exe allows the original line to run.
>> Unluckily ash doesn't set $PWD so the build will eventually break.
>
> Can you use ksh instead?
Yes once the 100% CPU issue is taken care of, using (k)sh is the best
solution. Just right now ash works better presumably due to it being
lighter.
>
>> Also
>> the BASE_PATH in fateconfig.py needs a drive letter or else lxlite will
>> error out with unknown command when passed a pathname starting with /
>
> Hmmm. What if you quote the path? This might prevent lxlite for thinking
> it has a switch to process.
Yes quoting the path will work, just right now trying to get it to run,
then see if Python rejects /" or if using single quotes for the whole
command line will work
>
> Steven
>
Dave
Dave