Hi Scott. > echo -ne "\\033\133\065\151" > cat $* > echo -ne "\\033\133\064\151" Okay, I looked these escape sequences up at vt100.net and they do exactly what you say they do. The first one says, "terminal, please redirect everything I tell you to your printer instead of your screen" and the last one says, "stop redirecting to the printer and go back to directing to the screen". I played around with xterm and .Xdefaults a bit and got it to work. The X resourses that are needed are:
xterm*printerCommand: lpr xterm*printerAutoClose: true where lpr is the printing program. Since these output devices are basically just line printers we could probably construct our own custom lpr program if needed. Are your linux register boxen going to be running X? I checked whatever version of the kernel source I have laying aroudn on my hard-drive (console.c) and the kernel's console vt's don't appear to support those particular escape sequences. I don't think it would be too terribly hard to add that feature to the kernel tho (it's all grouped in a pretty easy to follow set of switch() statements). There may already be a patch on the net somewhere, or it may already be in the kernel in a non-obvious [for me] spot. I'll do more investigating if you like. > In Counterpoint certain codes are defined for this type of pole display > that insert themselves in the lpt stream and send the right data to > the pole and the rest to the printer. Interesting. What are those codes? When I looked in the vt102 user manual, I didn't see anything to support printer selection (probably because real vt102's and the like only had at most one printer per terminal). > It is this pass through and local file configuration that I am > not certain about, yet, with a pure linux register. Me neither. If the sequence that specifies which output it's going to comes after the print sequence then we can just have our lpr scan for that sequence and choose accordingly. If it happens before the print sequence, then we'll probably have to patch xterm to support it. If X isn't an option at all, then we'll have to patch console.c in the kernel. > I know it is doable, but I have not tried, period. Yea I think we'll be able to get it to work. Although, I'll admit that I've never done anything like this before. --Ray