Hello All,

I am helping someone write a python script to run their DOS application
through an SSH terminal. It seems that this program wants to access a
DOS shell and send output there. If running remotely, this causes a
problem because it locks up the program. The program seems (to me) to be
looking for some non-existant DOS shell to send its output to. How might
I emulate this shell (or whatever it is) with python? I have tried
several flavors of python (Enthought, ActiveState, etc.). I have tried
win32pipe.popen[1-4], and many other things that I can't even remember
now. My answer in the past has been to erase the hard drive and install
linux, but it seems that this person is insistent on using
windows/cygwin. Since I'm married to her, I'm afraid I'm reduced to
begging for assistance. BTW, I've googled a lot and read many threads,
most point to win32pipe. If I missed an obvious answer or search term,
please forgive me. I'm not really a windows guru.

The program in question, in case anyone doesn't understand this problem,
is lem:

http://spitswww.uvt.nl/web/fsw/mto/lem/lemdos.zip

Try running it locally via an xwindows started by cygwin & look to the
main cygwin window for output (what is special about this window?). Then
try sshing to your cygwin box and running. It locks up.

Thanks in advance,

James

James Stroud wrote:[color=blue]
> I am helping someone write a python script to run their DOS application
> through an SSH terminal. It seems that this program wants to access a
> DOS shell and send output there. If running remotely, this causes a
> problem because it locks up the program. The program seems (to me) to be
> looking for some non-existant DOS shell to send its output to. How might
> I emulate this shell (or whatever it is) with python? I have tried
> several flavors of python (Enthought, ActiveState, etc.). I have tried
> win32pipe.popen[1-4], and many other things that I can't even remember
> now.[/color]

What makes you think there's any DOS "shell" involved? Many DOS
programs didn't write to stdout, but drew directly into screen memory
with BIOS calls and such. Are you sure this is a more generic command
line program that just writes to "stdout" or the console?

-Peter

Peter Hansen wrote:[color=blue]
> James Stroud wrote:
>[color=green]
>> I am helping someone write a python script to run their DOS
>> application through an SSH terminal. It seems that this program wants
>> to access a DOS shell and send output there. If running remotely, this
>> causes a problem because it locks up the program. The program seems
>> (to me) to be looking for some non-existant DOS shell to send its
>> output to. How might I emulate this shell (or whatever it is) with
>> python? I have tried several flavors of python (Enthought,
>> ActiveState, etc.). I have tried win32pipe.popen[1-4], and many other
>> things that I can't even remember now.[/color]
>
>
> What makes you think there's any DOS "shell" involved? Many DOS
> programs didn't write to stdout, but drew directly into screen memory
> with BIOS calls and such. Are you sure this is a more generic command
> line program that just writes to "stdout" or the console?
>
> -Peter
>[/color]

I honestly have no idea what this program is trying to do or whether a
DOS shell is involved. I'm just assuming based on the behavior. The
behavior is that if I start x-windows from the main cygwin terminal, and
then I run the program from xterm in x-windows, the output goes to the
main cygwin terminal from which I started x-windows. The output does not
go to the x-terminal. I assume that this bizarre behavior has something
to do with the fact that it freezes when running over SSH.

Also, FWIW, I believe the program was written in pascal and compiled
with turbo-pascal. The source is not available, though.

This is yet another reason why all thing microsoft suck!

James

James Stroud wrote:[color=blue]
> The program in question, in case anyone doesn't understand this problem,
> is lem:
>
> http://spitswww.uvt.nl/web/fsw/mto/lem/lemdos.zip[/color]

Well, LEM.EXE calls RTM.EXE and RTM.exe contains signs of not being a
pure DOS program. It contains references to USER.EXE and KERNEL.EXE
(probably some old Windows 95 thing? ... LEM dates from 1997), and the
following string:
'''
You have attempted to run Windows in enhanced mode while
running in a shell under a protected mode program. This
is not a compatible configuration. Run Windows in standard
mode instead (win /S).
'''

Possibly what you are trying to do is not going to be feasible...

-Peter