Bug 127285

Created attachment 16080 [details]
Script to use VT100 Control Sequences to print files from remote host

Using this script under PuTTY and other terminal emulation software, printer
output is transmitted directly to a VT100 terminal to be sent to a printer. 
When this script works, Konsole is honoring the right control codes.

Michael,

> The unsupported terminal sequences are "^[[5i" ("ESC [5i" -- Printing begin) and
> "^[[4i" ("ESC [4i" -- Printing finish).


indeed the sequences are unsupported. Originally, i did not include this command,
because i thought the application would be rare and chances are that you get a
deranged terminal it the printing-finish command does not occur. I would now hesitate
for other reasons, as i found virtually any application i learned about an to multiplex
the terminal for various purposes risking to stumble into security issues.

Normally, you can help yourself with the "tee" command.

> Ideally, if I'm ssh'd into a
> server somewhere through a Konsole session, I should be able to pipe a raw text file or
> PostScript document into a shell printing script and it should work.    


... and this, i believe, is the point. Why not using a proper remote printer for your task?

-lars

>> Ideally, if I'm ssh'd into a 
>> server somewhere through a Konsole session, I should be able to pipe a raw 
>> text file or PostScript document into a shell printing script and it should 
>> work.     

> ... and this, i believe, is the point. Why not using a proper remote printer 
> for your task? 
 
This is the proper remote printing setup for printing to a terminal.  Now, of the terminals that support it (even hardware ones) you can turn off the "magic" of those printing sequences, and if you wanted, they could be off by default.  The point is that this is standard terminal functionality that I use and that Konsole doesn't support, so for the time being, I am stuck using PuTTY on Linux (which isn't all that prettty).  I am not a developer of C/C++, otherwise, I would give Konsole the support and submit a patch to be tested... but the functionality is important.

Assuming you were talking about lpd/lpr, it is because in some circumstances, lpd/lpr isn't available, or isn't practical.  That's why I started using this printing solution to begin with.  In some cases, it's just not practical -- for a (trivial) example, ssh to freeshell.org and print up the list of dialup phone numbers.  It's much easier to be able to do "getdialup 678 | lpansi" and have it pop up on your local printer by way of whatever command you want Konsole (or whatever) to use to print.  I suspect that Konsole would go through the KDE printer stuff to do it, as it probably does for the screen.

Anyway, getting back to the main thing:  This is something that should be supported.  When I'm at work, I have to use PuTTY since they're using Windows, but if I'm home and using my laptop, or whatever, I should be able to do the same thing.  Of course, I could redirect the output to a file and then use file transfer for the hosts that I use that support it, or, copy and paste each page of the file for those hosts that don't... but I shouldn't have to.

Thanks for understanding.

Michael,

i have a patch on an archive tape somewhere that does it. I can dig it up for you.

I neverthenless hesitate to include it into the konsole - if it is about konsole's usability,
as i believe, the solution to build it in is not the right way. Typically, were such a feature
is used, it is actually about creating a multiplexer to tunnel data forth and back on the
terminal line for various reasons.

Very typically are mere technical applications, e.g. a konsole build into a technical device,
which is controlled over the remote line, too. Now the number of such channels vary, as
does the programs accepting or sending data - there are not only printers that can be
attached to terminals, but also "readers", like balances or bar code readers to be concrete.

I have seen this in more "commertial" applications, where they even allow to pass any
command lines over the back channel. Thus, what the "printer" is on the other side, might
vary extremely.

The alternative would be a complete separate program, say "ptytunnel", that hooks
between the konsole and the telnet/ssh/serial line. One could for instance say "ptytunnel
ssh me@host". Now ptytunnel could have a configuration and filter out perhaps configurable
escape sequences, switching channels, starting program that communicate with device, etc.
Often a remote application would like to know, whether the attached device is ready or
available at all, etc, etc.

Likely, printing demands can vary. If it is only a file to print, ok, [4i goes to the spooler, if a
real printer is attached (think of a PDA-like device), [4i might only switch channels, but does
not close, etc.

To cope with all such diversities, my preferred solution is actually to have such a feature not
being integrated into the konsole, but to have it as a separate program, much like "writed" is
separate from the konsole. The advantage would also be to allow to run any terminal program
on top of it, much like any terminal program runs on top of telnet or ssh. I have looked in sf.net
and freshmeat.net, but such a program does not appear to be available.

Michael, I'm currently too busy with other stuff, so i cannot spent the week it needs to code
such as thing. If you know a C-programmer who thinks such a thing would be fun, i can help
with a specification and technical details.

I do understand that you ask for something simple, that you want the banana but not the gorilla.
I thus can dig up the patch for the [5i and [4i stuff for your personal use these days, but i'm not
in favour to integrate it into the konsole. There, my preference is clearly a "ptytunnel" solution as
sketched above.

-lars

That is probably why it shouldn't be enabled by default.  If I could actually work with the source code myself, I would be more then happy to take a look at implementing it.  However, I know very little about C, let alone C++ and the KDE framework.  I was looking into it to see if I'd be able to check out konsole and see how it could be implemented.  I am *still* (several hours later) waiting on SVN to give me a tree of the trunk to look at it.  I'd be happy to wait on the feature, as I work around it right now by simply using PuTTY.  But I rather like the idea of using KDE applications, and Konsole is more aesthetically pleasing, anyway.

It *is* a rather simple feature -- I think that it's being over-thought here.  It is supported by VT100 and ANSI hardware terminals, and so I think it should be supported in the software emulation of them, as well -- optionally.

This also happens to be the way that 'lynx' uses for remote printing -- which I still find useful when I'm using 'lynx' over an ssh or telnet session to a local library's text online catalog.  It still definitely has its uses.  Don't get me wrong, I'm more then willing to be patient and wait for its implementation, because I have neither the know-how nor the money to accelerate its implementation into Konsole, and I do realize that it isn't an often used feature in the 2000's, but it is still useful.

When I have the money, I'd be more then happy to send a bounty on this one -- it is that useful.  It's nothing to do with data channels or anything -- just the simple VT100/ANSI remote-terminal-printing support.  The shell script that I attached is the script that I use nearly every day to use this feature in PuTTY, and that probably shows more concisely what I'm looking for.  At this point in time, executing that script under Konsole just displays on the terminal what should be diverted to a printer, Konsole ignores the ESC sequences.  (This should probably be the default behavior with a toggle option, similar to PuTTY.)

(Also, the script may/may not show up properly when you view it... the START_CODE / END_CODE variables contain the ESC sequences inserted directly into the file via the ^VESC key combination in vim.)

Michael, All,

as the issue of multiplexing the terminal lines comes up time and
again in various forms, attached an explicit proposal how to cope
with it.

We had another such a case on the list last year under the topic
"Remote host executing local functions", for instance, other applications
were embedded devices (e.g. cash registers or pda-like devices in
a store) with a konsole plus some machinery to be controlled or
issuing data to be kept separately from keyboard input all over the
same terminal line, to present some examples. These are all valid,
though very particular uses of the konsole.

Now remote printing is indeed part of the VT* specification, but falls
into the same category, i believe. Note that the Linux console for
instance does not implement it, either, perhaps for likely reasons.

My suggestion is so not to add support for such tunnels to the stock
konsole core, but to keep it instead in a separate program. This has
many advantages, among them:

1) The extensions can be localised.
2) The extensions can be used with any terminal.
3) Private variations of such extensions are more easy
    to make than within the full konsole source.
4) The approach can be used for the complete class of
    such extensions.
5) Keeping such extensions separate, they are not critical
    with respect to the default configuration, as the program
    has to be called separately and is not present in any
    konsole session by default.

The attached ptytunnel does the remote printing, and should
otherwise serve both as an example and a prove of concept.

Please see the manual page in the attached tar ball for more
information.

-lars


Created an attachment (id=16240)
ptytunnel-1.0.tgz

The wish has been dealt with, see the attachment (ptytunnel) in a preceding mail. It works well here. Whether it works in the particular environment of the bug's owner is unknown, because there was no reply for now over a month. I close the bug, therefor.

I suggest to include the proposed solution into the konsole source tree, perhaps under a separate directory, not dedicating it to binary distribution. The solution is a prototype for cases using the terminal line for tunneling, which are various. The solution is terminal-agnostic by design, so it could alternatively be released to a non-KDE related project site. 

A modification of the konsole itself is not necessary. If ever needed on a regular basis, the tunnel can transparently be added to the stack using a konsole session type.