[opensuse] Native printing via SSH
I have an old DOS program running under dosemu. Everything works ok except for printing. I was wondering how I can redirect the printer output via SSH (but not using port forwarding) It seems to be possible on the client side but I can't figure out how to redirect the printer on the server side. According to the SSH client's docs: "A lot of VT100-compatible terminals support printing under control of the remote server. PuTTY supports this feature as well, but it is turned off by default. To enable remote-controlled printing, choose a printer from the "Printer to send ANSI printer output to" drop-down list box. This should allow you to select from all the printers you have installed drivers for on your computer. Alternatively, you can type the network name of a networked printer (for example, \\printserver\printer1) even if you haven't already installed a driver for it on your own machine. When the remote server attempts to print some data, PuTTY will send that data to the printer raw - without translating it, attempting to format it, or doing anything else to it. It is up to you to ensure your remote server knows what type of printer it is talking to." And that is exactly what I need to do... redirect LPT1 in dosbox to the SSH client's printer. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
----- Original Message ----- From: "Andrew Joakimsen" <joakimsen@gmail.com> To: "opensuse" <opensuse@opensuse.org> Sent: Saturday, September 06, 2008 11:16 AM Subject: [opensuse] Native printing via SSH
I have an old DOS program running under dosemu. Everything works ok except for printing. I was wondering how I can redirect the printer output via SSH (but not using port forwarding) It seems to be possible on the client side but I can't figure out how to redirect the printer on the server side.
According to the SSH client's docs:
"A lot of VT100-compatible terminals support printing under control of the remote server. PuTTY supports this feature as well, but it is turned off by default.
To enable remote-controlled printing, choose a printer from the "Printer to send ANSI printer output to" drop-down list box. This should allow you to select from all the printers you have installed drivers for on your computer. Alternatively, you can type the network name of a networked printer (for example, \\printserver\printer1) even if you haven't already installed a driver for it on your own machine.
When the remote server attempts to print some data, PuTTY will send that data to the printer raw - without translating it, attempting to format it, or doing anything else to it. It is up to you to ensure your remote server knows what type of printer it is talking to."
And that is exactly what I need to do... redirect LPT1 in dosbox to the SSH client's printer.
That's not what you seem to think it is. That's just plain old ansi printer sequences. Also called "passthru" printing. All that means is this: If your terminal impliments the feature, as putty and almost every other terminal and terminal emulator does, then you can send data from the server to the terminals printer by wrapping the data in the ansi printer escape sequences. Go into putty config and specify some printer for the ansi passthru printing. Make sure it's a printer that understands pcl5 or lower, or plain text on it's own, it can't be a windows gdi printer or even a pcl6 one unless it happens to also have pcl5e or less. An awful lot of printers will not work this way. And generally if it was cheap, then it won't work. Now from the server send a small print job: echo -e "This text will be on the screen.\n\033[5iThis text should go to the printer.\r\n\033[4iThis text is on the screen." If your printer isn't a piece of junk then you should have got a line of text printed out. The data came in-band down the same tty that is used to draw text on your screen, but your terminal recognized "Esc[5i" and as redirected all incoming data to a print job instead of the screen until it saw the "Esc[4i". It's just a form of markup really. You can't practically use passthru printing to do what you want. Generally it is used by applications that have built in support specifically for it. The application uses the printer control sequences itself just the way it uses everything else it gets from termcap or terminfo such as the codes for changing text colors etc... No dos program is going to understand ansi printing. You could set up a script that acts as a virtual printer that sends print jobs to your tty from the background, except you can't because that background process has no way to ensure that the forground process does not print any characters or other data to the tty while the print job is transferring. Also, putty is the worst of any terminal emulator in existence for ansi printing because unlike every other terminal, it has no print job flush timer. Most terminals have a print job timer where whenever a print job comes through, when the printer-off sequence comes along, the print job is still held open on the terminal and a timer starts counting down in the background while outwardly the terminal resumes normal interactive use. If a printer-on comes along before the timer runs out, then the new data is merely appended to the already pending job, when the printer-off comes again, the timer is reset and starts counting down from the top again. Only when the timer reaches 0 does the terminal close the print job, resulting in the page eject. Programs the use passthru printing will send printer-on-off codes possibly many times per second, sending a little data to the printer, a little to the screen, a little more to the printer etc.. all during say, printing a report. In most terminal emulators, the typically 5 second flush timer means all the little tiny snips of print data are coelesced into one actual print job. In putty, depending on the application, you can get a page eject for every line of a report. aside: I have actually paid a developer to add a flush timer and a few other features to putty for me but he's taking a ridicuous number of weeks. The flush timer happens to be the one thing he did so far but I'm not ready yet to put the results back out into the public. In fact, I don't even have the modified source yet anyways. The only sensible way to get your dos app to print to a remote windows pc is via network. Share the printer and then either via vpn or ssh tunnel or plain port forwarding, make that share reachable from the server. You absolutely do not want to allow samba access from the internet, but there is also print services for unix (windows lpd server) and exernal print servers that can be used by a number of different protocols like raw tcp, ftp, email. Then configure dosemu to associate lpt1 with the cups queue. If your dos app has a config option to define a command to run for printing, maybe then you could use passthrough, as long as the application runs the print program in the foreground so that nothing else can access the tty while the print program is running. Then you could define a print command that is just a little script that sends the printer escape sequence, the data, and the closing printer sequence. I extremely doubt you are going to find any such option. Possibly there is a way to get dosemu to do what the app never imagined. Dosemu should be able to block off access to the tty while it sends a passthru print job, even if the app tries to write to the tty at the wrong time, except I don't think it actually has the necessary options. -- Brian K. White brian@aljex.com http://www.myspace.com/KEYofR +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
That's precisely what I am trying to figure out. Do you know what the option would be called? The application writes PCL direct to the LPT port so if I can figure a way to block tty access (I don't think it will be an issue the application does nothing else while it prints and in the Windows environment if the printer is not setup correctly the app just hangs). I am trying to avoid forwarding ports or using a VPN... because if each user needs to have their own printer I think this way (with TTY printing) will be easier to mange on the server side. On Sat, Sep 6, 2008 at 2:18 PM, Brian K. White <brian@aljex.com> wrote:
. Possibly there is a way to get dosemu to do what the app never imagined. Dosemu should be able to block off access to the tty while it sends a passthru print job, even if the app tries to write to the tty at the wrong time, except I don't think it actually has the necessary options.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
----- Original Message ----- From: "Andrew Joakimsen" <joakimsen@gmail.com> To: "Brian K. White" <brian@aljex.com> Cc: <opensuse@opensuse.org> Sent: Saturday, September 06, 2008 3:49 PM Subject: Re: [opensuse] Native printing via SSH
That's precisely what I am trying to figure out. Do you know what the option would be called? The application writes PCL direct to the LPT port so if I can figure a way to block tty access (I don't think it will be an issue the application does nothing else while it prints and in the Windows environment if the printer is not setup correctly the app just hangs). I am trying to avoid forwarding ports or using a VPN... because if each user needs to have their own printer I think this way (with TTY printing) will be easier to mange on the server side.
Then you may be lucky. It appears to be possible to tell dosemu to run a command to print. In fact it appears to be the default way it prints. (last time I used dosemu was sometime in the late 90's and I seem to remember a completely different style of config and I seem to remember granting dosemu access to /dev/lp0 , not defining a spooler program. But, it looks simple enough. Try this, vi /usr/local/bin/ansiprint #!/bin/bash # Print to ansi terminal printer stty raw </dev/tty echo -en "\033[5i" cat "$@" echo -en "\033[4i" stty cooked </dev/tty then chmod 755 /usr/local/bin/ansiprint Now put this in /etc/dosemu/dosemu.conf $_lpt1 = "ansiprint" The script is used a lot on all my servers so it's heavily tested, but, you still may have some issue with the stty commands. You can comment them out and the only result will be that print jobs with lots of binary raster graphics data will fail. For several years I didn't have those lines either and almost a thousand end users did 100% of their buisinesses printing that way, so, even that way is ok. The dosemu is untested. However, since the other examples are simply "lpr" then I know that dosemu must do one of two things, either it gives a temp file on the command line "lpr filename" or it pipes data into the command. The script works either of those ways so it should work, as long as you are right about the dos app's behaviour. I just did a "zypper in dosemu" and looked at the config file. I haven't actually run anything since I'm on the road at the moment using a centro as an evdo modem. If it breaks, you get to keep the pieces :) -- Brian K. White brian@aljex.com http://www.myspace.com/KEYofR +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
I got it to print one page... but on the back it said Invoice # 40600 printed ok1;1H25;1HCreating file, reading record #1;1H25;4 And when the 2nd page printed it was not formatted (everything was stuck together with no spacing And the application hangs with "Printing to LPT1:" On Sat, Sep 6, 2008 at 7:05 PM, Brian K. White <brian@aljex.com> wrote:
----- Original Message ----- From: "Andrew Joakimsen" <joakimsen@gmail.com> To: "Brian K. White" <brian@aljex.com> Cc: <opensuse@opensuse.org> Sent: Saturday, September 06, 2008 3:49 PM Subject: Re: [opensuse] Native printing via SSH
That's precisely what I am trying to figure out. Do you know what the option would be called? The application writes PCL direct to the LPT port so if I can figure a way to block tty access (I don't think it will be an issue the application does nothing else while it prints and in the Windows environment if the printer is not setup correctly the app just hangs). I am trying to avoid forwarding ports or using a VPN... because if each user needs to have their own printer I think this way (with TTY printing) will be easier to mange on the server side.
Then you may be lucky. It appears to be possible to tell dosemu to run a command to print. In fact it appears to be the default way it prints. (last time I used dosemu was sometime in the late 90's and I seem to remember a completely different style of config and I seem to remember granting dosemu access to /dev/lp0 , not defining a spooler program. But, it looks simple enough.
Try this,
vi /usr/local/bin/ansiprint
#!/bin/bash # Print to ansi terminal printer stty raw </dev/tty echo -en "\033[5i" cat "$@" echo -en "\033[4i" stty cooked </dev/tty
then chmod 755 /usr/local/bin/ansiprint
Now put this in /etc/dosemu/dosemu.conf $_lpt1 = "ansiprint"
The script is used a lot on all my servers so it's heavily tested, but, you still may have some issue with the stty commands. You can comment them out and the only result will be that print jobs with lots of binary raster graphics data will fail. For several years I didn't have those lines either and almost a thousand end users did 100% of their buisinesses printing that way, so, even that way is ok.
The dosemu is untested. However, since the other examples are simply "lpr" then I know that dosemu must do one of two things, either it gives a temp file on the command line "lpr filename" or it pipes data into the command. The script works either of those ways so it should work, as long as you are right about the dos app's behaviour. I just did a "zypper in dosemu" and looked at the config file. I haven't actually run anything since I'm on the road at the moment using a centro as an evdo modem.
If it breaks, you get to keep the pieces :)
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Oh well. Thats why I said it's almost certainly not a viable approach. I knew the app would draw on the screen and that screen data would wind up injected into, and thus screwing up, the print job. It may still be possible but you are on your own now, it's no longer a generic issue but one that needs in depth look at your application to see what -exactly- it does, and what, if anything, can be changed about it, and what can be lashed together around it. This may be a start, something printed, merely it needs to work better now, or it may be a total waste of time. I have no idea if there is any such kernel module or daemon as what I'm about to describe, but the one way I beleive this would work is the way Digi multiport intelligent serial card drivers work. Because they are a kernel driver for the very tty your terminal is using (in the case of a serial terminal hooked to a digiboard), it's possible for the driver to do a little magic and provide virtual printer device files. The driver provides device nodes like /dev/ttyNNNp where NNN is the normal tty name for some port on the digi and NNNp is the printer on that tty. Any program any where any time may send data to /dev/ttyNNNp just as if it was a plain dedicated serial printer. The _driver_ can do what no other process can do, which is block other things from writing to the tty while it sends ansi print data. Since it happens at the kernel driver level, it's transparent to all user processes without screwing them up at all. when a program tries to write to the tty while the driver is sending print data, the programs output is merely buffered and/or the program is told to wait. We used to use it a lot and it was perfectly solid. I see no reason why a generic kernel module or possibly even a userspace daemon process, possibly a /bin/login wrapper like the way ttysnoop works, could not be written to do that for any tty , with no relation to digiboards or any other serial ports. But since I don't need this, I'll leave you to investigate the possibility. good luck. -- Brian K. White brian@aljex.com http://www.myspace.com/KEYofR +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk! ----- Original Message ----- From: "Andrew Joakimsen" <joakimsen@gmail.com> To: "Brian K. White" <brian@aljex.com> Cc: <opensuse@opensuse.org> Sent: Saturday, September 06, 2008 8:46 PM Subject: Re: [opensuse] Native printing via SSH
I got it to print one page... but on the back it said Invoice # 40600 printed ok1;1H25;1HCreating file, reading record #1;1H25;4
And when the 2nd page printed it was not formatted (everything was stuck together with no spacing
And the application hangs with "Printing to LPT1:"
On Sat, Sep 6, 2008 at 7:05 PM, Brian K. White <brian@aljex.com> wrote:
----- Original Message ----- From: "Andrew Joakimsen" <joakimsen@gmail.com> To: "Brian K. White" <brian@aljex.com> Cc: <opensuse@opensuse.org> Sent: Saturday, September 06, 2008 3:49 PM Subject: Re: [opensuse] Native printing via SSH
That's precisely what I am trying to figure out. Do you know what the option would be called? The application writes PCL direct to the LPT port so if I can figure a way to block tty access (I don't think it will be an issue the application does nothing else while it prints and in the Windows environment if the printer is not setup correctly the app just hangs). I am trying to avoid forwarding ports or using a VPN... because if each user needs to have their own printer I think this way (with TTY printing) will be easier to mange on the server side.
Then you may be lucky. It appears to be possible to tell dosemu to run a command to print. In fact it appears to be the default way it prints. (last time I used dosemu was sometime in the late 90's and I seem to remember a completely different style of config and I seem to remember granting dosemu access to /dev/lp0 , not defining a spooler program. But, it looks simple enough.
Try this,
vi /usr/local/bin/ansiprint
#!/bin/bash # Print to ansi terminal printer stty raw </dev/tty echo -en "\033[5i" cat "$@" echo -en "\033[4i" stty cooked </dev/tty
then chmod 755 /usr/local/bin/ansiprint
Now put this in /etc/dosemu/dosemu.conf $_lpt1 = "ansiprint"
The script is used a lot on all my servers so it's heavily tested, but, you still may have some issue with the stty commands. You can comment them out and the only result will be that print jobs with lots of binary raster graphics data will fail. For several years I didn't have those lines either and almost a thousand end users did 100% of their buisinesses printing that way, so, even that way is ok.
The dosemu is untested. However, since the other examples are simply "lpr" then I know that dosemu must do one of two things, either it gives a temp file on the command line "lpr filename" or it pipes data into the command. The script works either of those ways so it should work, as long as you are right about the dos app's behaviour. I just did a "zypper in dosemu" and looked at the config file. I haven't actually run anything since I'm on the road at the moment using a centro as an evdo modem.
If it breaks, you get to keep the pieces :)
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
There we go. Create my own print queue and direct the dosemu output to it. #!/bin/bash #print2file TMPFILE=`mktemp ~/printjobs/dfprint.XXXXXXXXXX` || exit 1 cat "$@" >> $TMPFILE #!/bin/sh #launch dosemu & load oeextb.bat file #do not call oeext.ext direct because it will not exit #dosemu when user exits app dosemu -E oeextb reset echo Processing Print Queue... directory=~/printjobs/ for file in $( ls $directory ) do sleep 1 printf "\033[5i\c" echo $directory$file cat $directory$file printf "\033[4i\c" sleep 1 rm $directory$file done exit Since the dos app is intended to be running via SSH and is set to run automatically (they used to have one icon for each program when it was run locally) i.e the user really doesn't know it's not running locally, this actually works well enough, just call the file2print script when the application exits. The issue is if the user is to have a local printer it will become unmanageable if the printers need to be managed centrally. On Sat, Sep 6, 2008 at 9:22 PM, Brian K. White <brian@aljex.com> wrote:
what can be lashed together around it. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (2)
-
Andrew Joakimsen -
Brian K. White