Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!rutgers!bpa!cbmvax!grr
From: grr@cbmvax.commodore.com (George Robbins)
Newsgroups: comp.unix.ultrix
Subject: Re: Logging dlogin session to VMS
Message-ID: <9269@cbmvax.commodore.com>
Date: 9 Jan 90 22:00:02 GMT
References: <9225@cbmvax.commodore.com> <1995@eric.mpr.ca> <7225@shlump.nac.dec.com> <7256@shlump.nac.dec.com>
Reply-To: grr@cbmvax.commodore.com (George Robbins)
Organization: Commodore, West Chester, PA
Lines: 31

In article <7256@shlump.nac.dec.com> thomas@decwrl.dec.com writes:
> In article <9225@cbmvax.commodore.com>, grr@cbmvax.commodore.com (George
> Robbins) writes:
>> In article <7225@shlump.nac.dec.com>, I wrote writes:
>>> I could change dlogin to set the logfile to be unbuffered...
> 
>> BTW, you might want to think about what dlogin is doing for input and output.
>> It appears to at least look at stdin for input but opens /dev/tty for output.
>> This makes it inordinatly difficult to drive from a script or pipe the output
>> to something else as compared to copying the stdin/stdout descriptors...
> 
> My guess for the reason for this is that there is no way to synchronize
> the input
> to the requests from the remote node (what does flush typeahead do?
> which is the
> first thing VMS does) and that a using pty would be best.  I don't
> strong feelings
> either way but it does seem to be a reasonable argument.

I guess this is an issue, but opening /dev/tty conveys no obvious advantage
over duping or using stdin/stdout.  Even with the flow control/input purge
problem, it would still be possible to "talk" to a VMS system from the
shell using standard pipe techniques, which is the kind of capability you
want to preserve as far as possible in the unix environment...



-- 
George Robbins - now working for,	uucp: {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr@uunet.uu.net
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)