markw@hpdmd48.boi.hp.com (Mark Wolfe) (05/10/91)
I realize that this is not a wizard level question, but I posted it in
comp.unix.questions and got no responses in more than a week. I got a request
from one of my users for a screen printing utility. I want a program that will
send the cursor to the top of terminal memory and copy all text to a disk file
of pipe it directly into lp. It seems to me that I've seen a program like this
mentioned in documentation somewhere, but I can't seem to find it now. It looks
like this would be a fairly simple program to write based on what I read in the
curses and terminfo man pages, but we are preparing for a security audit right
now so I don't have the time to write it.
The machines I want this for are HP series 800's running HP-UX 7.0. If you
know of something reasonably priced (freebee), please post or email me.
Thanks,
Mark
markw@hpbs1529.boi.hp.com
"Always remember -
No matter where you go...there you are."
-Buckaroo Bonzaimarkw@hpdmd48.boi.hp.com (Mark Wolfe) (05/24/91)
Well, I have my answer, and I was very surprised at the responses I got. Most of the "wizards" said this was impossible to do in most cases and difficult at best. I guess terminals with their own memory are rare outside HP (hah!). It turns out all you need to do is issue 'lp' so it's reading from stdin and use the cursor control keys to send the cursor to the point on the screen you want to copy and hit enter until you've printed what you need, then control D to stop. All this is obviously very standard stuff. The whole thing is so simple I don't know why I didn't think of it before. I think some of you should go back to wizard school. Mark
mouse@thunder.mcrcim.mcgill.edu (der Mouse) (05/30/91)
In article <15710006@hpdmd48.boi.hp.com>, markw@hpdmd48.boi.hp.com (Mark Wolfe) writes: > Well, I have my answer, and I was very surprised at the responses I > got. Most of the "wizards" said this was impossible to do in most > cases and difficult at best. I guess terminals with their own memory > are rare outside HP (hah!). No, terminals with their own memory are not rare; every terminal must have somewhere to store the stuff displayed on the screen, and most use ordinary RAM for this. What *is* comparatively rare is terminals that provide any way for the computer on the other end of the serial line to get at this data. And of those that do, the required actions vary widely. > It turns out all you need to do is issue 'lp' so it's reading from > stdin and use the cursor control keys to send the cursor to the point > on the screen you want to copy and hit enter until you've printed > what you need, then control D to stop. All this is obviously very > standard stuff. Not at all. There is not a single terminal in use here where attempting what you describe will do anything useful. Some of the terminals don't have cursor keys; on those that do the above will generally result in printing a copy of the sequences generated by the cursor keys (with interspersed newlines); on the rest, I believe it will result in printing nothing but newlines. One of the terminals we use does have the capability to do what you want, but it requires magic escape sequences (not useful for anything else) and a program on the host to make sense of the mishmash generated by the terminal. > I think some of you should go back to wizard school. This is undoubtedly true, but you've brought no arguments to bear to support it. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
bill@bilver.uucp (Bill Vermillion) (05/30/91)
In article <1991May30.083643.25468@thunder.mcrcim.mcgill.edu> mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes: >In article <15710006@hpdmd48.boi.hp.com>, markw@hpdmd48.boi.hp.com (Mark Wolfe) writes: >> Well, I have my answer, and I was very surprised at the responses I >> got. Most of the "wizards" said this was impossible to do in most >> cases and difficult at best. I guess terminals with their own memory >> are rare outside HP (hah!). >No, terminals with their own memory are not rare; every terminal must >have somewhere to store the stuff displayed on the screen, and most use >ordinary RAM for this. >What *is* comparatively rare is terminals that provide any way for the >computer on the other end of the serial line to get at this data. And >of those that do, the required actions vary widely. Just saw a new terminal last week that is nearly in release. It's the MC6 from Link. It is the first terminal I have seen that knows what to do (to a limited extent) with the memory it has in it (64k ram I seem to recall). One of it's "neat" features is a cut&paste mode. You can cut&paste in the same window, or between two different windows (split screen that connects to different hosts simultaneously). To cut you press a key sequence, highlight the material, press another key. To paste you go to the position you wish to paste and press a key. The ram is dumped to screen and to the host. With one of these and short command sequence or pipe to lp, a screen dump should be easy. Whole sequence could be programmed to a function key - which if I remember correctly takes up to at least 64 bytes per key.. I will probably be getting one of these for testing and evaluation later this summer. Disclaimer - I am not an employee or related to Link in any way. I was just blown away by the capabilities of this terminal on my initial exposure to it. And it was being demoed for me by the person who wrote the programming for it - so he knew all the tricks - and showed me a few he hadn't announced. P.S. - I just cross-posted this to comp.terminals so edit your followups appropriately - particularly for non-wizard answer/question. -- Bill Vermillion - UUCP: ...!tarpit!bilver!bill : bill@bilver.UUCP
les@chinet.chi.il.us (Leslie Mikesell) (05/31/91)
In article <1991May30.152823.25779@bilver.uucp> bill@bilver.uucp (Bill Vermillion) writes: >Just saw a new terminal last week that is nearly in release. It's the MC6 >from Link. >One of it's "neat" features is a cut&paste mode. I've been doing this for a little while now by running several copies of MSDOS kermit 3.10 under Windows 3.0 on a 386. I'm connecting over a starlan network to several unix hosts with PIF files set up to name the windows/icons for the hosts and select the script for auto-login. Serial port links or the other networks that kermit knows about should work just as well. >You can cut&paste in the same window, or between two different windows >(split screen that connects to different hosts simultaneously). MSkermit gives you n-screen rollback so you can even back up to find the piece you want and then use the Windows cut&paste tools. >I will probably be getting one of these for testing and evaluation later >this summer. If you happen to have a 386 with windows sitting around it might make an interesting comparison. BTW, does anyone know where to get a terminfo entry for kermit 3.10? I've been using vt102, but this version is supposed to be a near vt320 with color support etc. Les Mikesell les@chinet.chi.il.us