See below ...
Joe.
> -----Original Message-----
> From: Clarence Verge [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, 20 February 2001 13:14
> To: [EMAIL PROTECTED]
> Subject: Re: DOS command line redirection (was PPP.LOG redirection
> ...)
>
> da Silva, Joe wrote:
> >
> > So, this unit _does_ (normally) inhibit DOS redirection, which
> > is more of a "File I/O" function than a "Display" function (direct
> > video access, which is also optional, is not responsible for this).
> >
> > Therefore, control of DOS redirection is certainly possible by
> > an application, which is why I did not assume that EPPPD's
> > output was redirected by DOS (COMMAND.COM?) - in theory,
> > a program such as EPPPD could inhibit DOS redirection, and
> > interpret redirection instructions on the command line, itself.
>
> This is PART of what I don't like about high level languages. You are too
> far away from the metal. You can get some "idea" that such and such is
> "DOS"
> behavior when it really isn't.
>
[da Silva, Joe]
Yes, sometimes this is a problem. However, as long as one
is aware of these "tricks", they shouldn't present a problem ...
> While DOS STDIN and STDOUT can be re-directed, nothing else can take over
> this function AS LONG AS YOU USE STDIN AND STDOUT.
> In fact, if EPPPD is loaded by a DOS commandline, any re-direction
> characters
> will be stripped (and used) by DOS before EPPPD can get a LOOK at the
> line.
>
> It may be possible to mine the memory for the original command tail, but
> I've
> had no luck with a little experiment I just performed. I think DOS wipes
> it.
>
[da Silva, Joe]
Yes, even when redirection is inhibited, the command parameters
stored in the PSP do _not_ include anything after any "redirection"
character (ie. '<', '>' or '|'). Which leaves two possibilities :
1. If redirection is inhibited, this might be because the program is
using an alternative file/device handle (or API?) to do it's
console
I/O. In that case, there is probably a function available in the
DOS API, that will convert a "handle" into it's corresponding
device/file name. One could then find the name assigned to the
STDIN or STDOUT handle, and perform normal file I/O to these.
(Indeed, one might be able to use the STDIN/STDOUT handles
directly, without bothering to determine their corresponding file
name(s)). This would effectively re-enable redirection, but under
full control of the application.
2. If redirection is _not_ inhibited (ie. "situation normal"),
perhaps
an application can simply "close" STDIN and/or STDOUT
before "going resident"? If so, then this is all that LSPPP (or
whatever) requires, to prevent problems with redirection .... If
time permits, I'll investigate further ...
> - Clarence Verge
> --
> - Help stamp out FATWARE. As a start visit: http://home.arachne.cz/
> --
