🚀 go-pugleaf

In article <299.25C6D7AD@weyr.FIDONET.ORG> Jim.Gilliland@p3.f209.n141.z1.FIDONET.ORG (Jim Gilliland) writes:
	(in response to my request for info on redirecting CMD)
>
>CMD.EXE can be redirected to use a COM port for its STDIN, STDOUT and STDERR,
>but its behavior in this situation may be confusing, especially with respect
>to STDIN.  When CMD.EXE discovers that its STDIN has been redirected, it makes
>a couple of changes in its input handling.  First of all, it does not echo its
>input.  Second, it ignores Carriage Returns (0x0D), and honors only Line Feeds
>(0x0A) as line terminators.  So it may well appear that it is not responding
>to input - since you can't see what you type and when you press Enter, nothing
>happens!  So perhaps you have been successful without realizing it.  It's easy
>to find out - just press Ctrl-J at the end of the line instead of Enter.

	Well, there are still a few "problems":

	1) <bs> doesn't eliminate the characters.
	2) <lf> does indeed terminate lines but does not generate a
	   corresponding <CR> (This is an annoyance more than totally
	   devastating).
	3) There does not appear to be a way to enter <EOF>.  ^Z does
	   not seem to do anything.
	4) There is no way to interrupt a process.  ^C does not have any
	   effect.
	5) Shutdown doesn't shutdown the detached process!!!!!
	6) We tried some simple commands with devastating results.  As an
	   example, putting a disk into the A: drive and typing 
	   diskcopy A: A:
	   generated an infinite number of error messages interleaved with
	   the same number of prompts to insert the disk.  I was never
	   prompted for input though (not even the first time).

So, is it really hopeless to do anything from the COM port or does it just
look that way?

	/\/\ \/\/
-- 
Michael R. Wayne      ---      TMC & Associates      ---      wayne@teemc.uucp
INTERNET: wayne%teemc.uucp@sharkey.cc.umich.edu       uunet!edsews!teemc!wayne 
         Operator of the only 240 Horsepower UNIX machine in Michigan