murphy@eric.mpr.ca (Gail Murphy) (01/05/90)
Hi I would like to connect to a VMS machine from an Ultrix workstation and log the session. I know "dlogin -l " will accomplish this but the log file does not seem to be written until the remote session is closed. Is there a way to accomplish this with the log file immediately visible on the Ultrix side? Thanks in advance, Gail Gail Murphy | murphy@joplin.mpr.ca Microtel Pacific Research | ubc-cs!eric!murphy@UUNET.UU.NET 8999 Nelson Way, Burnaby, BC | murphy%joplin.mpr.ca@relay.ubc.ca Canada, V5A 4B5, (604) 293-5462 | ...!ubc-vision!joplin.mpr.ca!murphy
thomas@mipsbx.nac.dec.com (Matt Thomas) (01/05/90)
In article <1995@eric.mpr.ca>, murphy@eric.mpr.ca (Gail Murphy) writes: > I would like to connect to a VMS machine from an Ultrix workstation > and log the session. I know "dlogin -l " will accomplish this > but the log file does not seem to be written until the remote > session is closed. Is there a way to accomplish this with the > log file immediately visible on the Ultrix side? Not currently. I could change dlogin to set the logfile to be unbuffered but that would be at the cost of slowing down dlogin. Or maybe fflush the logfile once dlogin has been idle for 30secs or so. (which would be easy to tie into the select call). And/or when you escape to the dlogin command menu? Any other ideas? -- Matt Thomas Internet: thomas@decwrl.dec.com DECnet-ULTRIX Development UUCP: ...!decwrl!thomas Digital Equipment Corporation Disclaimer: This message reflects my own Littleton, MA warped views, etc.
grr@cbmvax.commodore.com (George Robbins) (01/05/90)
In article <1995@eric.mpr.ca> murphy@eric.mpr.ca (Gail Murphy) writes: > Hi > > I would like to connect to a VMS machine from an Ultrix workstation > and log the session. I know "dlogin -l " will accomplish this > but the log file does not seem to be written until the remote > session is closed. Is there a way to accomplish this with the > log file immediately visible on the Ultrix side? Using the Ultrix "script" command and then invoking dlogin is a reasonably close approach to what you want. The output will still be buffered - i.e. somewhat behind the terminal activity, but it is still available as it goes. Are you sure that dlogin -l doesn't record as it goes, with a similar buffering issue? Note that older versions of Ultrix/VMS acted funny with "script" and you had to use control/V for a line terminator... Don't ask me... -- 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)
grr@cbmvax.commodore.com (George Robbins) (01/06/90)
In article <7225@shlump.nac.dec.com> thomas@decwrl.dec.com writes: > In article <1995@eric.mpr.ca>, murphy@eric.mpr.ca (Gail Murphy) writes: > > I would like to connect to a VMS machine from an Ultrix workstation > > and log the session... > > I could change dlogin to set the logfile to be unbuffered but that > would be at the cost of slowing down dlogin. Or maybe fflush the > logfile once dlogin has been idle for 30secs or so. (which would > be easy to tie into the select call). And/or when you escape to the > dlogin command menu? Any other ideas? Opinion: It seems to me that the -l switch is used so infrequently that setting the log to unbuffered or doing a fflush after each time your see that you have written a line terminator to the terminal output wouldn't really have any serious performance impact. You might try it and see if there's any noticable slow down. 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... -- 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)
thomas@nac.dec.com (Matt Thomas) (01/06/90)
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 but that > > would be at the cost of slowing down dlogin. Or maybe fflush the > > logfile once dlogin has been idle for 30secs or so. (which would > > be easy to tie into the select call). And/or when you escape to the > > dlogin command menu? Any other ideas? > > Opinion: > > It seems to me that the -l switch is used so infrequently that setting the > log to unbuffered or doing a fflush after each time your see that you have > written a line terminator to the terminal output wouldn't really have any > serious performance impact. You might try it and see if there's any noticable > slow down. I'll take a look at it. > 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... dlogin does check stdin to make sure that it's a tty but doesn't reopen stdin/stdout or stderr. This was done in the far distant past before I joined the group. 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. Just checked the sources, dlogin just prints out a misleading error message. It does a itatty(0) but prints "warning - controlling terminal is not a physical terminal". -- Matt Thomas Internet: thomas@decwrl.dec.com DECnet-ULTRIX Development UUCP: ...!decwrl!thomas Digital Equipment Corporation Disclaimer: This message reflects my own Littleton, MA warped views, etc.
grr@cbmvax.commodore.com (George Robbins) (01/10/90)
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)
thomas@mipsbx.nac.dec.com (Matt Thomas) (01/12/90)
In article <9269@cbmvax.commodore.com>, grr@cbmvax.commodore.com (George Robbins) writes: > I guess this is an issue, but opening /dev/tty conveys no obvious advantage > over duping or using stdin/stdout. dlogin does not (repeat that: does not) open /dev/tty. it uses 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... Depending *if* I can warp dlogin to accept a pipe/socket/fifo as input (those pesky tty ioctl's could be a problem), I *might* allow dlogin to read from a pipe/socket/fifo as well as from a tty. No promises and don't count on it. -- Matt Thomas Internet: thomas@decwrl.dec.com DECnet-ULTRIX Development UUCP: ...!decwrl!thomas Digital Equipment Corporation Disclaimer: This message reflects my own Littleton, MA warped views, etc.
grr@cbmvax.commodore.com (George Robbins) (01/12/90)
In article <7403@shlump.nac.dec.com> thomas@decwrl.dec.com writes: > In article <9269@cbmvax.commodore.com>, grr@cbmvax.commodore.com (George > Robbins) writes: > > I guess this is an issue, but opening /dev/tty conveys no obvious advantage > > over duping or using stdin/stdout. > > dlogin does not (repeat that: does not) open /dev/tty. it uses stdin/stdout. Try the following experiment 8-) dlogin >& /tmp/output The only thing that gets written to the file is the "exit" message, the rest somehow escaping to your terminal screen. I dunno exactly what it's doing, but "strings .../dlogin" (3.1 VAX) revealed the constant "/dev/tty" so that was my initial assumption. -- 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)
thomas@mipsbx.nac.dec.com (Matt Thomas) (01/13/90)
In article <9316@cbmvax.commodore.com>, grr@cbmvax.commodore.com (George Robbins) writes: > I dunno exactly what it's doing, but "strings .../dlogin" (3.1 VAX) revealed > the constant "/dev/tty" so that was my initial assumption. Found it. dlogin was doing (ecck!) write(0, ...); Needless to say (but say I will) it's now write(1, ...); -- Matt Thomas Internet: thomas@decwrl.dec.com DECnet-ULTRIX Development UUCP: ...!decwrl!thomas Digital Equipment Corporation Disclaimer: This message reflects my own Littleton, MA warped views, etc.