Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On Sun, Jan 21, 2024 at 10:44:35PM +, phoebus phoebus wrote: A filter in between that in response to escape-code-1 starts sending data to the serial port instead of the terminal application and switches back to the terminal application on receiving of escape-code-2. Development of a transparent and responsive intermediate filter to ensure a smooth user experience. This filter must handle incoming and outgoing commands without disruption. This is old, old, old tech. The suggestion early on to use screen was one reasonable answer, xterm is another. Solutions exist for this, the main problem is dusting off documentation old enough to be aware this functionality exists. (As seen by so many of the responses here, which are apparently unaware that at one time an actual terminal--the hardware device with a screen and a keyboard that a "terminal emulater" emulates--had a serial connection to a server and could also have a second serial connection to a printer, and escape sequences were used to switch the server output from screen to printer and back.) This isn't functionality that has to be developed, it was written long ago and simply isn't used much anymore. You'll have to find old code, because newer terminal emulators don't bother implementing this since not many people are asking for it (and those that do, can simply use the old code and probably aren't as interested in compositor transparency effects). Waiting for Returns: The filter remains attentive to returns of information coming from the serial printer. These returns may include information about the printing status, errors, or other relevant data. This is where things go off the rails--"other...data". Most of the unix terminal emulators use the ANSI escape sequences which, as far as I know, had unidirectional printing. The datastream coming from the server had escape sequences to change output from screen to printer, but the printer had no way to interrupt that and talk back to the server. The documentation about "passthrough printing" you've referenced several times *does not* describe any capability for doing this. (In fact, the capability described involves a pipe and can't possibly be bidirectional.) There were escape sequences the server could use to query specific things about the printer (like "printer ready"; and, as far as I know, that was it). I have no idea whether any of the terminal emulators do much or anything with the status sequence, as they mostly expect to pipe output and aren't actually written to directly connect to a serial printer and check its status lines. (In an actual terminal/printer situation the query would report the status of DTR or CTS or whatever the specific hardware was using to communicate printer status.) In theory it would be a relatively trivial addition to tie the "printer status" escape code to something that queries printer status, if it's possible to do so and it's not already implemented in a terminal emulator that does support printing. But that's still not communication of arbitrary data. Now VT100 wasn't the only terminal out there. For example, Wyse was a big name in terminals, and they used a completely different set of escape codes. One of theirs enabled a bidirectional mode, used for things like connecting an optical barcode scanner at a library checkout desk to the minicomputer in the back. I don't know of many open source wyse emulators, and none that implement this. IBM had their own proprietary terminals and control mechanisms, like the 3270 or 5250, with another set of capabilities. Again, I don't know of many open source emulators, and those that I am aware of had limited functionality. If this is the sort of thing you're talking about, you'd get much further searching for information about wyse terminal emulators (or whatever terminal language your software uses--there were far more than DEC VT or Wyse or IBM) rather than an open ended question about printing. (In reality, the bidirectional peripheral control might have been lumped into the printer escape sequences in terminal manuals and might have connected via the port labeled "printer", but wasn't ever really about printing because printing is unidirectional. This is obviously confusing to people not aware of the jargon.) I would not expect to find much open source software in this space because it's very niche and basically requires expensive proprietary software to test against if the goal is to run expensive proprietary software correctly. This is literally tech from the 1970s, so without the right keywords you're going to mostly find unrelated but newer and higher-ranked stuff that's not what you're looking for.
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On Wed 24 Jan 2024 at 23:46:31 (+0700), Max Nikulin wrote: > On 24/01/2024 00:16, David Wright wrote: > > On Wed 24 Jan 2024 at 00:00:57 (+0700), Max Nikulin wrote: > > > Server-side code mixing 2 data streams into single channel may be a > > > bit more simple than association of 2 connections with the same > > > client, but the price is this long thread. > > > OTOH we've all experienced misconfigurations where printer jobs > > go to the wrong printer. What's the cost of the wrong till-receipt > > printer opening an unattended cash drawer? There are some benefits > > that come with localising connections. > > Just to be clear, I do not suggest to statically configure all POS > printers on the server. SSH session may handle multiple data streams, > so it should be possible to associate UI terminal stream and > printer/scanner links when a client connects to the server. I guess I find this suggestion more vague than what the OP was describing, so you'd have to elaborate. But what I was commenting on (snipped from above) is having "independent connections on any network layer". There are LAN-connected printers around for sale, but there are security dangers with such connection methods, depending on the application. Cheers, David.
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On 23/01/2024 08:52, phoebus phoebus wrote: "Xterm 216" is unclear for me. > PuTTY documentation in 4.4.3 Changing the action of the function keys and keypad explain it by "In Xterm 216 mode, the unshifted function keys behave the same as Xterm R6 mode. But pressing a function key together with Shift or Alt or Ctrl generates a different sequence containing an extra numeric parameter of the form (1 for Shift) + (2 for Alt) + (4 for Ctrl) + 1. For F1-F4, the basic sequences like ESC OP become ESC [1;bitmapP and similar; for F5 and above, ESC[index~ becomes ESC[index;bitmap~. Thanks. It seems it is supported by most terminal applications in Linux. However usually enough such keystrokes are grabbed for window manager and desktop environment hotkeys. In the case of POS it may be a kind of single-application kiosk with no WM and DE. The small program described in the previous proposal could indeed be the intermediate filter. So you can offer developers alternatives: to extend a combined terminal+SSH application like putty or to create a filter working with any terminal application.
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On 24/01/2024 00:16, David Wright wrote: On Wed 24 Jan 2024 at 00:00:57 (+0700), Max Nikulin wrote: Server-side code mixing 2 data streams into single channel may be a bit more simple than association of 2 connections with the same client, but the price is this long thread. OTOH we've all experienced misconfigurations where printer jobs go to the wrong printer. What's the cost of the wrong till-receipt printer opening an unattended cash drawer? There are some benefits that come with localising connections. Just to be clear, I do not suggest to statically configure all POS printers on the server. SSH session may handle multiple data streams, so it should be possible to associate UI terminal stream and printer/scanner links when a client connects to the server.
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On Wed 24 Jan 2024 at 00:00:57 (+0700), Max Nikulin wrote: > On 22/01/2024 22:33, Stefan Monnier wrote: > > > That's the way it was built -- just mimicking the "real terminal cum > > > firmware" which was replaced with "DOS/Windows PC cum terminal > > > application". > > > > I think it's more than that. It's a design that makes a lot of sense: > > it would be more complex having to connect both the terminal and the > > printer to the server, since the terminal and printer really > > belong together. > > It had a lot of sense at the time when terminals were directly wired > to servers. Currently it is ssh over TCP/IP over Ethernet or WiFi and > there is no a terminal emulator application that supports off-band > communication with printer out of the box. So independent connections > on any network layer would be more flexible. > > Server-side code mixing 2 data streams into single channel may be a > bit more simple than association of 2 connections with the same > client, but the price is this long thread. OTOH we've all experienced misconfigurations where printer jobs go to the wrong printer. What's the cost of the wrong till-receipt printer opening an unattended cash drawer? There are some benefits that come with localising connections. Cheers, David.
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On 22/01/2024 22:33, Stefan Monnier wrote: That's the way it was built -- just mimicking the "real terminal cum firmware" which was replaced with "DOS/Windows PC cum terminal application". I think it's more than that. It's a design that makes a lot of sense: it would be more complex having to connect both the terminal and the printer to the server, since the terminal and printer really belong together. It had a lot of sense at the time when terminals were directly wired to servers. Currently it is ssh over TCP/IP over Ethernet or WiFi and there is no a terminal emulator application that supports off-band communication with printer out of the box. So independent connections on any network layer would be more flexible. Server-side code mixing 2 data streams into single channel may be a bit more simple than association of 2 connections with the same client, but the price is this long thread.
Re: Seeking a Terminal Emulator on Debian for "Passthrough"Printing
On 1/22/24 20:52, phoebus phoebus wrote: Hello, You now want to replace of the components, but since it's very dependent on the rest of the system, you are having a hard time finding a replacement. It's even difficult to describe the requirements, because it's something really unusual. So: have you considering replacing the whole system? Sure, in the short term it will be costly. It'll be difficult, and cause disruptions. The users will have to be trained in the new system, productivity will decrease a little until they get proficient in it, there might be the need for some downtime, etc. So I totally understand that what I'm proposing is not something easy to ask. But given that the difficulty you are having in replacing this one component will likely be repeated when some other part needs to be changed, I do not think it's entirely unreasonable that this option is studied. I completely understand your point of view and I agree that the decision to replace the entire system is a complex matter. However, it is not within the scope of our project team. It is indeed a strategic decision that falls under the purview of the company's leadership. Our role is limited to working on the Unix/Linux part of the project and ensuring that we adhere to the schedule, budget, and business functionalities defined by the leadership. If such a decision were to be considered, it would involve broader considerations that go beyond our technical responsibilities. We (aka projects team) are here to contribute to the project's success within the framework of the directives provided to us. How about "Replace a locked-in solution with an fully open source [hopefully] solution"? It definitely looks like there is no ready open source solution to the component the OP wants to replace. It might be possible to adapt an existing terminal emulator to include the necessary functionality, solving the immediate problem, but the next part that they want to replace might end up with the same problem. Certainly, that could certainly be a viable option, but from my perspective, it would look more like a future project that the leadership might consider launching in a few years. Currently, my focus is on completing the current project, which falls within my current responsibilities. "Xterm 216" is unclear for me. PuTTY documentation in 4.4.3 Changing the action of the function keys and keypad explain it by "In Xterm 216 mode, the unshifted function keys behave the same as Xterm R6 mode. But pressing a function key together with Shift or Alt or Ctrl generates a different sequence containing an extra numeric parameter of the form (1 for Shift) + (2 for Alt) + (4 for Ctrl) + 1. For F1-F4, the basic sequences like ESC OP become ESC [1;bitmapP and similar; for F5 and above, ESC[index~ becomes ESC[index;bitmap~. " The things missing there are "escape sequence to start sending stuff via serial port to the printer" and "send everything coming from the serial port to the app". I envision a small program in the middle of all spawning an SSH, opening the serial port and running in an xterm (so your ssh is just wrapped in that process). My limited knowledge of Expect (session login script automation) had led me to believe that Expect would not do the job, but I was wrong. Since Expect can be capable of detecting escape sequences and sending back data to the terminal based on these sequences. So, Expect can be used to monitor the output of a terminal, detect specific patterns, such as escape codes, and take actions accordingly, such as sending commands or interacting with the terminal. The small program described in the previous proposal could indeed be the intermediate filter. The intermediate filter acts as a kind of mediator between the terminal emulator (in this case, SSH running in an xterm) and the serial printer, redirecting data appropriately. In this scenario, the intermediate filter would be responsible for two main functions: Detecting escape sequences (as mentioned in the question) to know when to start redirecting data to the serial port of the printer. Taking data from the serial port of the printer and transmitting it to the terminal application (SSH in an xterm) seamlessly. Thus, this small program could be considered as a component of the intermediate filter, ensuring smooth data management between the terminal emulator and the serial printer. The component could be expect or a C/python/tcl/perl program. Regards, Thierry Or even bash which I have done in long past installs as part of procmail. Or wrappers for amanda. You are finally beginning to get down to what you want to do, thank you. . Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, > You now want to replace of the components, but since it's very dependent > on the rest of the system, you are having a hard time finding a > replacement. It's even difficult to describe the requirements, because > it's something really unusual. > > So: have you considering replacing the whole system? > > Sure, in the short term it will be costly. > > It'll be difficult, and cause disruptions. The users will have to be > trained in the new system, productivity will decrease a little until > they get proficient in it, there might be the need for some downtime, etc. > > So I totally understand that what I'm proposing is not something easy to > ask. But given that the difficulty you are having in replacing this one > component will likely be repeated when some other part needs to be > changed, I do not think it's entirely unreasonable that this option is > studied. I completely understand your point of view and I agree that the decision to replace the entire system is a complex matter. However, it is not within the scope of our project team. It is indeed a strategic decision that falls under the purview of the company's leadership. Our role is limited to working on the Unix/Linux part of the project and ensuring that we adhere to the schedule, budget, and business functionalities defined by the leadership. If such a decision were to be considered, it would involve broader considerations that go beyond our technical responsibilities. We (aka projects team) are here to contribute to the project's success within the framework of the directives provided to us. > How about "Replace a locked-in solution with an fully open source > [hopefully] solution"? > > It definitely looks like there is no ready open source solution to the > component the OP wants to replace. It might be possible to adapt an > existing terminal emulator to include the necessary functionality, > solving the immediate problem, but the next part that they want to > replace might end up with the same problem. Certainly, that could certainly be a viable option, but from my perspective, it would look more like a future project that the leadership might consider launching in a few years. Currently, my focus is on completing the current project, which falls within my current responsibilities. > "Xterm 216" is unclear for me. PuTTY documentation in 4.4.3 Changing the action of the function keys and keypad explain it by "In Xterm 216 mode, the unshifted function keys behave the same as Xterm R6 mode. But pressing a function key together with Shift or Alt or Ctrl generates a different sequence containing an extra numeric parameter of the form (1 for Shift) + (2 for Alt) + (4 for Ctrl) + 1. For F1-F4, the basic sequences like ESC OP become ESC [1;bitmapP and similar; for F5 and above, ESC[index~ becomes ESC[index;bitmap~. " > The things missing there are "escape sequence to start sending stuff > via serial port to the printer" and "send everything coming from the > serial port to the app". > > I envision a small program in the middle of all spawning an SSH, > opening the serial port and running in an xterm (so your ssh is > just wrapped in that process). My limited knowledge of Expect (session login script automation) had led me to believe that Expect would not do the job, but I was wrong. Since Expect can be capable of detecting escape sequences and sending back data to the terminal based on these sequences. So, Expect can be used to monitor the output of a terminal, detect specific patterns, such as escape codes, and take actions accordingly, such as sending commands or interacting with the terminal. The small program described in the previous proposal could indeed be the intermediate filter. The intermediate filter acts as a kind of mediator between the terminal emulator (in this case, SSH running in an xterm) and the serial printer, redirecting data appropriately. In this scenario, the intermediate filter would be responsible for two main functions: Detecting escape sequences (as mentioned in the question) to know when to start redirecting data to the serial port of the printer. Taking data from the serial port of the printer and transmitting it to the terminal application (SSH in an xterm) seamlessly. Thus, this small program could be considered as a component of the intermediate filter, ensuring smooth data management between the terminal emulator and the serial printer. The component could be expect or a C/python/tcl/perl program. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On Mon, Jan 22, 2024 at 10:33:02AM -0500, Stefan Monnier wrote: > > That's the way it was built -- just mimicking the "real terminal cum > > firmware" which was replaced with "DOS/Windows PC cum terminal application". > > I think it's more than that. It's a design that makes a lot of sense: > it would be more complex having to connect both the terminal and the > printer to the server, since the terminal and printer really > belong together. Don't get me wrong. I was thinking in terms of "a terminal emulator with graft-on funny functionality as a monolithic application" vs. "a dedicated application with a standard terminal emulator hanging off one socket (or PTY), a standard SSH hanging off another and a printer hanging off a TTY" or something. The idea of having one "wire" (aka net connection) to the terminal and hang the printer on that isn't bad per se. After all, the person standing at the terminal is the one who wants to see the paper receipt. Cheers -- t signature.asc Description: PGP signature
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
> That's the way it was built -- just mimicking the "real terminal cum > firmware" which was replaced with "DOS/Windows PC cum terminal application". I think it's more than that. It's a design that makes a lot of sense: it would be more complex having to connect both the terminal and the printer to the server, since the terminal and printer really belong together. Stefan
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On Mon, Jan 22, 2024 at 10:00:44PM +0700, Max Nikulin wrote: > On 22/01/2024 05:44, phoebus phoebus wrote: > > Handling Returns: When the filter receives returns from the serial > > printer, it directly transmits them to the terminal application without > > any modification or addition. Thus, information from the serial printer > > is relayed as is to the terminal application without altering the > > pass-through mode. > > I feel that I miss something. Shouldn't data from devices connected to the > serial port be sent to the server (the application running on the server) > not to the terminal application that just displays text? But it's only the "terminal application" who has contact to the server, so it has to play middleman. That's the way it was built -- just mimicking the "real terminal cum firmware" which was replaced with "DOS/Windows PC cum terminal application". Of course, if you look closer, you'll somehow find several components, whether they run in one address space or in separate processes :-) > > The PuTTY application has been evaluated to meet consultation needs but > > does not fulfill the requirements related to sales, especially concerning > > access to the serial printer. > > Terminals details include the use: > > Coonection by key type: ed25519 with passphrase > > The backspace key: Control-? (127) > > The function keys and keypad: Xterm 216+ > > "Xterm 216" is unclear for me. > > If there was no requirement for passthrough printing then would putty have > some features unavailable e.g. in the following case? > > xterm -e ssh example.com > The things missing there are "escape sequence to start sending stuff via serial port to the printer" and "send everything coming from the serial port to the app". I envision a small program in the middle of all spawning an SSH, opening the serial port and running in an xterm (so your ssh is just wrapped in that process). > ...or with any of libvte-based terminal applications. Would it be enough to > run ssh in a VT (TERM=linux)? So yes... nearly:-) Cheers -- t signature.asc Description: PGP signature
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On 22/01/2024 05:44, phoebus phoebus wrote: Handling Returns: When the filter receives returns from the serial printer, it directly transmits them to the terminal application without any modification or addition. Thus, information from the serial printer is relayed as is to the terminal application without altering the pass-through mode. I feel that I miss something. Shouldn't data from devices connected to the serial port be sent to the server (the application running on the server) not to the terminal application that just displays text? The PuTTY application has been evaluated to meet consultation needs but does not fulfill the requirements related to sales, especially concerning access to the serial printer. Terminals details include the use: Coonection by key type: ed25519 with passphrase The backspace key: Control-? (127) The function keys and keypad: Xterm 216+ "Xterm 216" is unclear for me. If there was no requirement for passthrough printing then would putty have some features unavailable e.g. in the following case? xterm -e ssh example.com ...or with any of libvte-based terminal applications. Would it be enough to run ssh in a VT (TERM=linux)?
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On 22/01/2024 10:57, Stefan Monnier wrote: So: have you considering replacing the whole system? You mean, fix this one well-understood problem, and replace it with an unknown number of unknown problems? Sounds great! How about "Replace a locked-in solution with an fully open source [hopefully] solution"? It definitely looks like there is no ready open source solution to the component the OP wants to replace. It might be possible to adapt an existing terminal emulator to include the necessary functionality, solving the immediate problem, but the next part that they want to replace might end up with the same problem. -- BASIC is the Computer Science equivalent of `Scientific Creationism'. Eduardo M KALINOWSKI edua...@kalinowski.com.br
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
> So: have you considering replacing the whole system? You mean, fix this one well-understood problem, and replace it with an unknown number of unknown problems? Sounds great! Stefan
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On 11/01/2024 21:27, phoebus phoebus wrote: [snip description of problem] I'm on the category of people that haven't fully understood the requirements. Maybe because I do not have experience in this specific area, and also probably because I haven't read each email carefully. But that's ok, because I want to talk in more general terms. You probably won't like the suggestion, though. It seems that the system you have has become quite complex and its many components depend on each other in very specific ways. It has become something rather peculiar. Maybe it's not unique, maybe many retailers have similar systems, but they all depend on the same vendor or couple of vendors. You now want to replace of the components, but since it's very dependent on the rest of the system, you are having a hard time finding a replacement. It's even difficult to describe the requirements, because it's something really unusual. So: have you considering replacing the whole system? Sure, in the short term it will be costly. It'll be difficult, and cause disruptions. The users will have to be trained in the new system, productivity will decrease a little until they get proficient in it, there might be the need for some downtime, etc. So I totally understand that what I'm proposing is not something easy to ask. But given that the difficulty you are having in replacing this one component will likely be repeated when some other part needs to be changed, I do not think it's entirely unreasonable that this option is studied. -- Eduardo M KALINOWSKI edua...@kalinowski.com.br
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On Sun, Jan 21, 2024 at 10:44:35PM +, phoebus phoebus wrote: > Hello, > > I will try to be more explicit in my request and avoid giving the impression > that I'm avoiding the discussion of technical issues [...] Thanks, although, as I said, I haven't had that impression myself. [...] > Non-Printing Terminal in passthrough Mode: > > A terminal emulator is used to access a semi-graphical application with a > text-based user interface. It should be capable of displaying multi-level > grids and application selection menus seamlessly. This one sticks out for me: back then (TM) there were terminals capable of some "forms mode" where there was immutable text and the back end just sent the content of fields. I don't know whether modern Linux terminal emulators (or even PuTTY,for that) can do this. One would have to look into that. There might be some risk for "interesting implementation details" here. > Intermediate Filter: [...] This all looks doable, regardless of what implementation detail might be chosen. > Constraints: > > Reliability: > The solution must be highly reliable, as any loss of sales or issues > related to the generation of legal documents, such as invoices and receipts > (whether printed or digital), is unacceptable. Business continuity is > paramount. Here's another point: On updates you will need a testing procedure to asses whether to roll out things. This might be something which up to now, your provider is doing for you (what kind of guarantees do you get currently?). Perhaps you need a new process in place you delegated to your provider up to now. Cheers -- t signature.asc Description: PGP signature
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, I will try to be more explicit in my request and avoid giving the impression that I'm avoiding the discussion of technical issues. As you mentioned, my previous response seemed to resemble the replies of corporate support teams, but I don't really fall into the category of "those who are afraid to disclose some knowledge they might have heard." I have shared all the information I possess as a system engineer regarding the solution we use, and I have even gone beyond my responsibilities (scope) by addressing the aspect of the workflow that falls under the domain of our application developers working on the functional side. However, I align more with the first category of individuals "who do not know the technical details" because I struggle to explore beyond the features offered by the proprietary emulator and other similar solutions that the project team has asked me to evaluate. The problem likely lies, as Abraham Maslow said, in the fact that "If your only tool is a hammer then every problem looks like a nail." I have been constrained in my thinking by wanting to replicate the same implementation as the one I am familiar with in proprietary offerings and I find it challenging to understand how another solution could provide the same outcome while being implemented differently. Do you expect something like that for Technical specifications for the required solution: Connection Security: Utilization of the SSH protocol to ensure a secure connection to the Linux server, replacing Telnet. Non-Printing Terminal in passthrough Mode: A terminal emulator is used to access a semi-graphical application with a text-based user interface. It should be capable of displaying multi-level grids and application selection menus seamlessly. Intermediate Filter: A filter in between that in response to escape-code-1 starts sending data to the serial port instead of the terminal application and switches back to the terminal application on receiving of escape-code-2. Development of a transparent and responsive intermediate filter to ensure a smooth user experience. This filter must handle incoming and outgoing commands without disruption. Detection of Escape Codes: The filter continuously monitors incoming data from the terminal emulator to detect the presence of specific escape codes, such as "escape-code-1" and "escape-code-2." Switching to the Serial Port: When the filter detects "escape-code-1" in the incoming data, it switches to a data redirection mode towards the output device, such as the serial port. From that point on, all incoming data is directed to the output device instead of being displayed in the terminal application, while it continues to monitor communication with the printer. Waiting for Returns: The filter remains attentive to returns of information coming from the serial printer. These returns may include information about the printing status, errors, or other relevant data. Handling Returns: When the filter receives returns from the serial printer, it directly transmits them to the terminal application without any modification or addition. Thus, information from the serial printer is relayed as is to the terminal application without altering the pass-through mode. Reception of "Escape-code-2": When the filter detects "escape-code-2" in the incoming data (usually sent from the terminal application), it ceases redirecting data to the output device. At this stage, it returns to the normal behavior of the terminal emulator, displaying data in the terminal application. Transparent Processing: Throughout this process, the filter ensures that the transition between data redirection to the output device and display in the terminal application occurs seamlessly, so the user doesn't notice any interruptions or disruptions in data display or printing. Synchronization with the Terminal Application: The intermediate filter must stay synchronized with the terminal application to correctly detect "escape-code-1" and "escape-code-2." It must react promptly when it detects these codes to switch between redirection and pass-through modes. Poor synchronization could lead to interruptions or unwanted disruptions for the user. Synchronization with the Serial Printer: The filter must also maintain synchronization with the serial printer to handle returns of information appropriately and transmit them to the terminal application at the right moment. Desynchronization with the serial printer could result in the loss of crucial information regarding the printing status or errors. Latency Minimization: To ensure precise synchronization, the filter must minimize latency in data and signal processing. Excessive latency could lead to synchronization issues and unwanted delays. Exception Handling: Synchronization must also be considered when handling exceptions, such as the
Re: Seeking a Terminal Emulator on Debian for "Passthrough"Printing
On Saturday 20 January 2024 07:56:16 pm gene heskett wrote: > We may even already > have a POS system you could use. I know for a fact one of the local > grocery stores here in this village of around 6000 is running something > on linux in the checkout lanes, I saw it boot up after a power failure > before the actual app was auto-started. What that app was, no one had > been instructed as it was totally auto starting. Typical of the > checkout lanes I suspect. Without naming the rather large company involved, I had some similar experience -- I ran a service call to do some updates on one of those checkout lane systems, and they were running a customized version of RH7! I was instructed to bring a keyboard and a monitor because the POS screen and keyboard wouldn't show all that needed to be seen or to key in the necessary stuff... -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin
Re: Seeking a Terminal Emulator on Debian for "Passthrough"Printing
On 1/21/24 01:46, to...@tuxteam.de wrote: On Sat, Jan 20, 2024 at 07:56:16PM -0500, gene heskett wrote: On 1/20/24 19:03, phoebus phoebus wrote: Hello, Hm ok, it's all too much guesswork then. I understand that the lack of detailed information can make it challenging to provide precise solutions. I believe I have addressed these questions as accurately and honestly as possible in my previous response to Greg, while also incorporating the information we discussed earlier. Regards, Thierry I might point out in all this hand waving, that no one puts a contract out for bid, without specifying the performance required to do the job, which we aren't privileged to see. A description of what it must do, should not be a copyright probem as its is part and parcel of the "clean room" description the coders work from. [...] I must say that the OP's description was sufficiently clear to me to get a rough idea of what I'd do to wrap it in C (OK, the specific escapery would have to be written down and so on, but that's details). Perhaps I've lived for too long in this weird design space. At 89, Tomas, I've long since got that message. I go to walmart for some food since here in small town USA they are one of the two choices, and every time I go thru the self checkout they've changed the software in the scanner and something that worked 3 days ago doesn't today. I've offered to write them something that just works more than once. It would take a while to sort the hardware's needs but that's detail stuff and we both know it. Maybe the coders that do it in Bentonville are doing it for job security knowing if they ever did it right, the job would be over. That is how MBA's think. But having to contain and face the wrath of an MBA who thinks he's my boss whose sales idea is payola, subject to a $27,500 fcc fine for every time it airs, I've been threatened with firing for insubordination, but as long as I have the fcc required letter in my file cabinet, designating me as chief operator, my sayso gets their tape dropped on the eraser. Like Shakespear said about lawyers long ago applies here. Cheers Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On 21/01/2024 06:55, phoebus phoebus wrote: My role is strictly technical, focused on providing unbiased, pragmatic, and fact-based assessments of solutions, whether they are proprietary or open source. From my point of view, you are trying hard to avoid discussion of technical issues. It is still unclear to me why you want namely a customized terminal emulator instead of combining existing applications, perhaps with a tiny custom helper. - SSH, VPN, etc. to ensure secure connection to the server. - A terminal application without passthrough printing. - A filter in between that in response to escape-code-1 starts sending data to the serial port instead of the terminal application and switches back to the terminal application on receiving of escape-code-2. Even if "expect" is not suitable (I am in doubts, but I am not closely familiar with it), creation of the custom tool should be easier than modification of a terminal emulator. Moreover, it would allow to change other parts of the solution. Developers anyway would need a testbench to debug code you need without relying on your server. It does not matter whether it would be a filter or a terminal emulator. Nobody is trying to force you to name companies. The real issue is that you are refusing questions concerning *examples* for what use cases suggestions would not work. What I read in this thread is just "we have special needs". It resembles replies from enterprise support stuff who either do not know any technical details or are afraid to disclose some know-how they might heard. P.S. https://lists.debian.org/msgid-search/zzrrbqsut2fnu...@einval.com Monthly FAQ for Debian-user mailing list (modified 20240102) * It is not necessary to answer every post on the mailing list. * It may also be useful for someone to post a summary email from time to time to explain long threads.
Re: Seeking a Terminal Emulator on Debian for "Passthrough"Printing
On Sat, Jan 20, 2024 at 07:56:16PM -0500, gene heskett wrote: > On 1/20/24 19:03, phoebus phoebus wrote: > > Hello, > > > > > Hm ok, it's all too much guesswork then. > > > > I understand that the lack of detailed information can make it challenging > > to provide precise solutions. > > I believe I have addressed these questions as accurately and honestly as > > possible in my previous response to Greg, while also incorporating the > > information we discussed earlier. > > > > Regards, > > Thierry > > > I might point out in all this hand waving, that no one puts a contract out > for bid, without specifying the performance required to do the job, which we > aren't privileged to see. A description of what it must do, should not be a > copyright probem as its is part and parcel of the "clean room" description > the coders work from. [...] I must say that the OP's description was sufficiently clear to me to get a rough idea of what I'd do to wrap it in C (OK, the specific escapery would have to be written down and so on, but that's details). Perhaps I've lived for too long in this weird design space. Cheers -- t signature.asc Description: PGP signature
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On Sat, Jan 20, 2024 at 08:11:25PM +, phoebus phoebus wrote: > Hello, > [...] > I want to emphasize that your response reflects a clear understanding of our > specific needs and the constraints we are facing in this project. Thanks to confirming my mental model :-) [phoebus phoebus] > Yes, that's indeed how it used to work. In our case, the complex escapery you > mentioned, for instance, involves the printing process using the ESC/POS > printer control language. > > >> So the thing is just a natural evolution dating back to The Dinosaurs. > > While it may seem unusual and archaic by today's standards, this approach has > proven to be an effective solution for addressing the needs of our business. > It has been thoughtfully evaluated and retained because it ensures the > efficient execution of our application while aligning with our business > requirements. Just like certain evolutionary traits persist over time in the > process of Darwinism, this approach endures, indicating that the choice isn't > as misguided as it may appear. Don't get me wrong: I'm not criticising your decision process. I'm long enough in this business to know that technical processes are evolutory. You change a few things and keep most of the rest (because that "rest" is so overwhelmingly complex and huge that you have to). Which parts to keep and which to change is a tough decision which IMO has to be taken by the people involved. Things like "disruption" are, in my view,just empty marketing terms :-) So no, I don't believe your choice is misguided. Who am I to. I still believe you'll have an easier (technical) life if you separate the terminal and the "dispatching" process (now talking about UNIX processes) -- the latter might be minicom or something in its class, or something written in C, Python or Perl or whatever your folks are comfortable with. The fact that both have a separate address space is hidden in the "Linux box", which may well be a Raspi or something similar. But I'm aware that I might well be wrong: if one of us is wrong, then it's me :-) Cheers -- t signature.asc Description: PGP signature
Re: Seeking a Terminal Emulator on Debian for "Passthrough"Printing
Hello, On my technical side, I don't have insight into the contractual aspect or the costs involved. I'm not involved in the bidding and proposal writing phases either. My role comes into play after project maanger send me companies solutions to evaluate them from a purely technical and security standpoint. If the solutions pass our initial technical evaluation (performed by the systems teams), they are then passed on to more specialized functional teams for further testing. I wasn't familiar with the English acronym TANSTAAFL (There ain't no such thing as a free lunch), but I completely agree with it. My internal technical specification is to have an equivalent to the commercial product I have on my Wyse PC for testing. The decision to promote Putty was mine as a Linux enthusiast and advocate for open-source software. It performed well in testing, except for the passthrough printing aspect. The only cost I'm aware of is that of a proprietary product I mentioned earlier, which is available on their website: "AnzioWin starts at $150.00* per PC with quantity discounts beginning at 10 copies. Anzio Lite starts at $40.00* per PC with quantity discounts beginning with a license for 10 PCs." So, if we consider the cost of the more expensive version and assume we have 1000 PCs, it would range from $150,000 to $75,000 without any discounts. I won't disclose the exact number of our PCs, but let's say it falls within the range of 500 to 1000. I assume that with the simple cost of software plus the undisclosed maintenance cost paid annually, we could allocate a budget for open-source development that would benefit our company and, subsequently, the community, especially if the open-source product becomes part of the official product branch with included maintenance. What I can say is that I have management's approval for my interactions with the community and exploring potential open-source alternatives. However, there are no guarantees at this point, as I haven't yet produced concrete results in terms of an open-source alternative or engaged with the community for further development, budget allocation, and associated assurances. My approach might be naive or clumsy because I'm not familiar with the customs and practices in this business field. For the time being, our project management team prefers that the system team engages with the community to find something and intervenes later on in the negotiation and commercial aspects. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, > With free software, it might not be too costly to try out > suggestions like Putty. But I speak as someone with a university > background, not a company one. We might have had a bit more > freedom to mess around, and even mess up. And a small base of > sophisticated users rather than a large number of likely > unskilled users Your academic perspective is appreciated, and it is true that in the professional world, especially in the retail sector, compatibility with specific peripherals is crucial for the smooth operation of operations. > From a position of ignorance, I would have thought that serial > pass-through printing is necessarily bidirectional, if only for > flow-control, but UARTs can do that in hardware with RTS/CTS. > So it's unlikely that that's enough to support what the OP wants, > which is probably things like ink/paper supply or, when there's > a cash drawer installed, drawer open/closed; typical POS stuff. > And that's without taking into account the peripherals mentioned > above. Regarding the use of Putty, it appears that in some cases, it can partially meet our needs by allowing interactions such as printing tickets and opening the cash drawer. However, i also mentioned that some other operations do not work. It is important to note that Putty is primarily designed as a terminal emulator and may not be equipped to meet all the specific requirements of our retail application. As for the evolution of Putty, it is understandable that the developer has not responded to our contact attempts, and we respect their decision to maintain the software according to their own criteria. I also pointed out that we have proprietary emulator solutions that come with integrated hardware offerings, such as Wyse-type client terminals or Android tablets. These solutions meet our needs and provide the necessary services at a given cost. I just to emphasize that the diversity of options, whether open source or proprietary, is a wealth, as it allows each company to find the solution that best suits its needs. Ultimately, our goal is to find the best solution for our retail application, taking into account hardware compatibility, required features, and associated costs. While we are open to exploring open-source solutions if they can meet our needs, we also value the reliability and support that proprietary solutions can provide. We will continue to evaluate all available options, ensuring that we choose the approach that best aligns with our business requirements and technical considerations. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough"Printing
On 1/20/24 19:03, phoebus phoebus wrote: Hello, Hm ok, it's all too much guesswork then. I understand that the lack of detailed information can make it challenging to provide precise solutions. I believe I have addressed these questions as accurately and honestly as possible in my previous response to Greg, while also incorporating the information we discussed earlier. Regards, Thierry I might point out in all this hand waving, that no one puts a contract out for bid, without specifying the performance required to do the job, which we aren't privileged to see. A description of what it must do, should not be a copyright probem as its is part and parcel of the "clean room" description the coders work from. That and what you might be willing to pay a competent programmer to do might sweeten the project enough for a free software developer to do. These people here are doing it to aid the free software environment, doing it for our thanks, but they like to be able to eat and pay the rent. like TANSTAAFL, it is not optional. The OP's choice is not to do that specification. If that spec is forthcoming, and doable with the tools we have you may pique someones interest. They in turn may contact you privately with an estimate/offer. But w/o that spec, so the coder knows for sure what it must do, circular without any solution will be this thread. We may even already have a POS system you could use. I know for a fact one of the local grocery stores here in this village of around 6000 is running something on linux in the checkout lanes, I saw it boot up after a power failure before the actual app was auto-started. What that app was, no one had been instructed as it was totally auto starting. Typical of the checkout lanes I suspect. FWIW that coder isn't me, my coding heyday was in the later 70's thru about 2002. Now I'm 89 and retired for 22 years, diabetic for 40 years, chest full of hardware, running on what some might call borrowed time. Cheers, Gene Heskett, CET. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, > Hm ok, it's all too much guesswork then. I understand that the lack of detailed information can make it challenging to provide precise solutions. I believe I have addressed these questions as accurately and honestly as possible in my previous response to Greg, while also incorporating the information we discussed earlier. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, > See, now we're going in circles again. I already *asked* the OP to > explain the full picture, and they still only gave a partial answer. > > It has been hinted to us that there are more layers in the problem > than simply Server <--> PC --> Printer. We've been told that there > is another layer of devices connected to the Printer, although this > was never confirmed in the "big picture" answer. > > Apparently the (retail sales??) application on the server needs to > talk to all three layers of hardware: the PC (to display information > on the screen), the Printer (to generate ink on paper), and the other > devices beyond the Printer (reasons never given). Communication with > the devices beyond the Printer is apparently "bidirectional", meaning > the server application needs to be able to query one of these devices > and get information from it, which will cause application state to > be altered, information to appear on the screen, etc. Or maybe the > devices beyond the Printer are capable of initiating an async data > transfer to the server app? Who knows. It was never clearly stated. > > Apparently the OP has a proprietary Windows terminal emulator + telnet > client program (name never revealed?) that can already do everything, > and they want a Debian program that can be used in place of it. > > The problem for *us* is that we don't know what "everything" is (since > the OP is incapable of explaining it all), which makes it very hard > to find a program that can do "everything". I've tried to be as precise as I can in the technical description. I understand I'm seeking help, but it's challenging for me to provide specific product names and details without violating the security guidelines I've agreed to in this project, which is critical for our company. I have previously mentioned that this is a Point of Sale (POS) system, consisting of the workstation (Wyse-type) that includes the terminal emulator and the receipt printer. This setup is used in the retail sector, primarily for sales transactions. I cannot disclose the names of commercial products in use because we are simultaneously evaluating various proprietary products in a competitive pre-sales phase. My role is strictly technical, focused on providing unbiased, pragmatic, and fact-based assessments of solutions, whether they are proprietary or open source. I always provide detailed arguments and references whenever possible. I must avoid any potential legal issues that could arise from disclosing sensitive information to any of the product vendors involved in the project. Additionally, I don't use the application myself, and I'm not familiar with its functional aspects. My knowledge is limited to the technical aspects of how things work, more like a black-box perspective. I can, for example, mention that this guide explaining passthrough mode (https://www.anzio.com/resources/guide-anzios-passthrough-printing) is a proprietary product that could potentially meet our requirements. I can cite it because, as of now, the project team hasn't initiated any commercial contact with this vendor during the pre-sales phase. However, the technical principles are well described in this resource: https://www.anzio.com/resources/printing-anzio in the Passthrough Printing + Aux Printing section, along with this additional resource: https://www.anzio.com/resources/using-aux-devices-anzio. The current emulator comes bundled with the Wyse-type workstation equipment; we don't have access to this software independently. From a practical standpoint, when it comes to printing, we simply select the Passthrough Printing option and choose the COM port. That's all there is to it, and it works this way. It's almost the same as in PuTTY, except here, we can choose a hardware port instead of a virtual printer. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, > Ok, and what's the problem? That the server wants to print to the > printer? That the application sends data to the "screen" (a terminal > emulator) instead of sending it to the printer? That it is necessary > to see the printer data displayed in a terminal emulator? The problem here revolves around the interaction between the terminal emulator, the application, and the printing process. The terminal emulator has a "printing passthrough" function, which means that depending on the user's interactions with the application, data can be displayed on the screen and, at times, passed through the terminal's passthrough mode to be printed on the physical printer. So, to address your questions specifically: 1. The server itself doesn't initiate printing; instead, it's the user on the workstation with the terminal emulator who wishes to print to their local printer. The application running on the server sends data to the user's screen (terminal emulator) and, when requested by the user, can be sent to the user's local physical printer connected to their workstation. 2. The application may send data to both the screen and the printer, depending on the specific user interactions and transaction requirements. The screen serves as a visual interface for the user, while the printer captures some of the data for hardcopy records. 3. It's necessary to have the option to selectively send certain data to the physical printer from the terminal emulator based on the user's choice, as it provides real-time feedback and visibility for the user during interactions with the application. However, not all data displayed on the screen needs to be sent to the printer, as it may include additional information or layout formatting relevant to the current screen content or user interactions. The display on the screen and the printing on the printer are designed to complement each other based on the specific transactional needs and the user's preferences. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, > It's running on a Windows PC. Walk into many a shop and you can see > the sort of setup, a PC and screen with a barcode scanner, keyboard, > credit card reader, receipt printer, etc, all hanging off it. The > server might be in an office, or perhaps at HQ or in the cloud. > All perfectly normal. The import of the thread is Windows → Linux. Yes, the challenge here is ideally to migrate the Windows-based workstation to Linux, provided that we have the necessary open-source emulator. Functionally, we already have proprietary alternatives that meet the requirements, but exploring open-source options is our preference, given our commitment to open-source solutions within our Linux environment. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >>> I don't understand why you involve a terminal emulator in the process. >>> Do you need to see the data that goes through the COM port displayed >>> in a terminal (like minicom)? >> >> People interact with the (remote) application by means of the terminal >> emulator. Things get sent to/from the printer based on escape sequences >> initiated by the application. >Desktop sharing works fine with gnome these days. Why not interact >with the application through that kinda locally? You suggest an interesting alternative by using the desktop sharing feature available with GNOME to interact with the application remotely. I was not aware of this particular use of the GNOME feature; I primarily knew it for remote control and screen sharing purposes. At this stage, I am not yet familiar enough with GNOME to provide a comprehensive opinion on this approach. However, I want to emphasize that within the scope of the mission I have been entrusted with, I do not have the authority to modify the server application's functionalities. I am subject to the constraints and decisions of the project team. Therefore, implementing this suggestion goes beyond the boundaries of my current responsibilities. >> In the original (proprietary) application, the dispatching functionality > > Dispatching functionality? > >> is integrated in the terminal emulator, so it is understandable that >> pheoebus phoebus wants to keep that structure in the replacement. In this project to migrate the application server from Unix to Linux, the primary objective was to maintain the stability and functionality of the server component, while the client side (the terminal) underwent an evaluation to explore open-source alternatives to the proprietary terminal emulator solution, all while preserving the existing functionality. > Well, I'd have to be quit a bit older to have experienced "real" > terminals like that. I do remember printers accepting some escape > sequences to control their functionality, though. > > If this application is running on such a terminal, maybe it's time to > find a more modern und thus more feasible replacement ... An ancient > terminal may cease to work eventually and be very difficult to repair > once it does ... This application does not run on a physical "real terminal" but on a terminal emulator, which is software running on a Windows-based workstation (Wyse). Currently, there are various hardware options available for this, including proprietary solutions with newer versions of Wyse and proprietary terminal emulators, as well as Android-based devices that can fulfill the task with proprietary emulators. However, as someone working with Linux and for whom open source and freedom have significance in my profession, I proposed to explore if there might be open-source solutions that can meet this requirement. If there are none available at this time, then so be it, but at least considering this option in our evaluation is an important step for us when it's feasible. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough"Printing
Hello, >> On the Linux server, are there multiple users logging into this server via >> ssh and each of them needs to print to a local printer in the way you >> mention? Yes, there are indeed multiple users logging into the Linux server via SSH and each of them needs to print to a local printer specific to their Point of Sale (POS) activity. This is essential because it involves a POS station and a printer specifically designated for this business activity. >> Would one normally attach a printer physically to the server and your >> software talk directly to this locally attached device on the server? I am >> curious how, if you have multiple users logging in, the software would know >> which ssh session to use to communicate with the local physical printer. Indeed, it is possible to physically connect a printer to the server and the software could communicate directly with this device through a print spooler system. However, in the context of our Point of Sale (POS) environment, this approach doesn't make sense. The printer needs to be dedicated to the POS station, ensuring that the staff using the PC is as close as possible to our customers and that the printing occurs directly in front of them quickly and seamlessly. In the case of SSH sessions, each user connects to the server with their individual session streams. The printing flow is, therefore, directed through this session in a straightforward and secure manner (which is the essence of printing in passthrough mode). >> When you say ‘serial port’ as in com1:, are you referring to an old RS422 or >> RS232 serial port? Or is the device connected to a USB and has an >> association with com1 on the windows side? When I mention a "serial port" like com1:, I am indeed referring to a traditional RS422 or RS232 serial port. If the device is connected via USB and is associated with a virtual com1 port on the Windows side, it doesn't require any software modifications to handle printing in passthrough mode. From the perspective of the proprietary terminal emulator, the data flow goes through a COM port, whether it's physical or virtual. >> I recommend that you do not try and modify PuTTY or KiTTY or any of the ssh >> terminals. This will be hard to support and you may cause a security >> nightmare. We absolutely refrain from attempting to modify software such as PuTTY, KiTTY, or SSH terminal emulators ourselves. This is because it can be challenging to implement and may pose security risks. Therefore, we are actively seeking to engage with the teams behind these projects to explore potential solutions that align with our needs or we are considering proprietary alternatives >> A possible solution is to run some small glue program on both sides of the >> connection which uses a port forward tunnel. For example, on the server, a >> small program which creates a pseudo device or named socket that looks like >> a local printer. This small program reads data on the pseudo dev and copies >> it to and from a local tcp port which is forwarded over ssh. Then, on the >> windows side, you write a second small program which listens on the local >> port and copies the data to and from com1:. Essentially you are building a >> tunnel from a device or socket on the server to the com port using an ssh >> tunnel between a local and remote tcp port. I cannot say if this solution would be viable when dealing with multiple users simultaneously. I don't have the flexibility to alter the behavior of the application, and this introduces constraints that I must consider when searching for an open-source solution to meet my requirements. Of course, if I opt for proprietary solutions, I have a clear path to solving my problem. >> If you have multiple people logging into the server, you will need to find a >> way to multiply the printer port on the server. This is why I asked about >> multiple users in my first question. I would need to understand that before >> making any recommendation around that. Off the top of my head, I would >> probably have my script create a named socket for each user in >> /run/user//foo/myprinter.sock and then in the software print to this >> socket which is unique for each user. >> Is there absolutely no way you can separate the part of your software that >> is running on the Linux server which talks bi-directionally to the printer >> and port this software to windows as a windows printer driver? Your >> situation seems a bit strange. I can’t help but think we’re missing >> something here. Developing on the Windows side for this printing functionality is not currently under consideration. Instead, the choice in this case would be to continue investing in a proprietary terminal solution, despite its cost, as it would provide more reassurance to the project team than the long-term expenses associated with maintaining this type of Windows development. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >> People interact with the (remote) application by means of the terminal >> emulator. Things get sent to/from the printer based on escape sequences >> initiated by the application. >> >> In the original (proprietary) application, the dispatching functionality >> is integrated in the terminal emulator, so it is understandable that >> pheoebus phoebus wants to keep that structure in the replacement. I want to emphasize that your response reflects a clear understanding of our specific needs and the constraints we are facing in this project. >> I proposed splitting off the "mux" functionality from the terminal >> emulator functionality, but I fully understand that phoebus phoebus >> favours the more "conservative" approach. The use of a terminal emulator in passthrough mode is tied to our existing infrastructure and the way our application was originally designed. Within the scope of the ongoing project, which involves migrating our application from Unix to Linux, it is not within the migration's scope to alter this particular aspect, as it is both critical and sensitive. While I have some leeway to propose technical enhancements and changes, this specific area is off-limits due to its significant impact on a crucial functional aspect from both a business perspective and certain certification standards under which our POS system is certified. >> By the way -- back then (TM), when terminals were real things, it was >> not unheard of that they came with an attached printer and some bar >> code scannery -- all handily multiplexed over the RS-232 (or something >> more monstruous), orchestrated via intricate escapery. Yes, that's indeed how it used to work. In our case, the complex escapery you mentioned, for instance, involves the printing process using the ESC/POS printer control language. >> So the thing is just a natural evolution dating back to The Dinosaurs. While it may seem unusual and archaic by today's standards, this approach has proven to be an effective solution for addressing the needs of our business. It has been thoughtfully evaluated and retained because it ensures the efficient execution of our application while aligning with our business requirements. Just like certain evolutionary traits persist over time in the process of Darwinism, this approach endures, indicating that the choice isn't as misguided as it may appear. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >> I don't understand why you involve a terminal emulator in the process. >> Do you need to see the data that goes through the COM port displayed in a terminal (like minicom)? The existing solution is designed in that manner. We migrated our application from AIX to Linux, and this is the approach that has been historically used. On the client-side, we are exploring if there's an open-source alternative to the proprietary solution that fulfills the necessary functions. >> I do not understand what you are trying to do at all. Are you trying >> to print to a remote printer that has a serial port? For that, >> perhaps you could use a printserver with a serial port (if you can >> find one) or a printserver and an adapter from parallel to serial. In our POS system, the printer is located at the POS station so that our customers can have their prints quickly and in front of them. Printing from the server in this POS context doesn't make sense for us in this scenario. >> If you're trying to create a two-way communication between a remote >> server and a remote client, with the client sending and receiving the >> data through its COM port (for some weird reason), you could do that >> over ethernet, using your own protocol or an existing one (maybe even >> xmpp). We already utilize the TCP protocol for communication over Ethernet, as the transparent printing flow is encapsulated within the encrypted SSH stream. Depending on the ASCII control codes, the data either displays on the terminal screen or gets printed on the connected printer. So, we are already leveraging Ethernet and TCP for this purpose. >>Unfortunately, COM ports have become quite rare :( In the retail environment, COM ports are still quite common, especially in equipment such as POS printers. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On Thu 18 Jan 2024 at 12:28:58 (+0100), hw wrote: > On Wed, 2024-01-17 at 23:08 -0600, David Wright wrote: > > On Tue 16 Jan 2024 at 11:47:53 (+0100), hw wrote: > > > On Mon, 2024-01-15 at 20:32 +0100, to...@tuxteam.de wrote: > > > > On Mon, Jan 15, 2024 at 08:08:36PM +0100, hw wrote: > > > > > > > > > > I don't understand why you involve a terminal emulator in the process. > > > > > Do you need to see the data that goes through the COM port displayed > > > > > in a terminal (like minicom)? > > > > > > > > People interact with the (remote) application by means of the terminal > > > > emulator. Things get sent to/from the printer based on escape sequences > > > > initiated by the application. > > > > > > Desktop sharing works fine with gnome these days. Why not interact > > > with the application through that kinda locally? > > > > > > > In the original (proprietary) application, the dispatching functionality > > > > > > Dispatching functionality? > > > > > > > is integrated in the terminal emulator, so it is understandable that > > > > pheoebus phoebus wants to keep that structure in the replacement. > > > > > > I don't understand. > > > > > > > I proposed splitting off the "mux" functionality from the terminal > > > > emulator functionality, but I fully understand that phoebus phoebus > > > > favours the more "conservative" approach. > > > > > > > > By the way -- back then (TM), when terminals were real things, it was > > > > not unheard of that they came with an attached printer and some bar > > > > code scannery -- all handily multiplexed over the RS-232 (or something > > > > more monstruous), orchestrated via intricate escapery. > > > > > > > > So the thing is just a natural evolution dating back to The Dinosaurs. > > > > > > Well, I'd have to be quit a bit older to have experienced "real" > > > terminals like that. I do remember printers accepting some escape > > > sequences to control their functionality, though. > > > > > > If this application is running on such a terminal, maybe it's time to > > > find a more modern und thus more feasible replacement ... An ancient > > > terminal may cease to work eventually and be very difficult to repair > > > once it does ... > > > > It isn't running on a terminal: tomas wrote "back then (TM), when > > terminals were real things". > > > > It's running on a Windows PC. Walk into many a shop and you can see > > the sort of setup, a PC and screen with a barcode scanner, keyboard, > > credit card reader, receipt printer, etc, all hanging off it. The > > server might be in an office, or perhaps at HQ or in the cloud. > > All perfectly normal. The import of the thread is Windows → Linux. > > Ok, and what's the problem? That the server wants to print to the > printer? That the application sends data to the "screen" (a terminal > emulator) instead of sending it to the printer? That it is necessary > to see the printer data displayed in a terminal emulator? AIUI, put simply, bidirectional passthrough printing by the server. I spent a couple of decades writing software that output to a variety of dot-matrix and inkjet printers, but never had to bother about the printer answering back. If the printer ran out of paper, users had to recover their printout by replaying the spool file. That was a deliberate choice, as any peripheral failures like that were unimportant. Likewise networked output through NFS: no feedback as to whether the server was up or not. From a position of ignorance, I would have thought that serial pass-through printing is necessarily bidirectional, if only for flow-control, but UARTs can do that in hardware with RTS/CTS. So it's unlikely that that's enough to support what the OP wants, which is probably things like ink/paper supply or, when there's a cash drawer installed, drawer open/closed; typical POS stuff. And that's without taking into account the peripherals mentioned above. With free software, it might not be too costly to try out suggestions like Putty. But I speak as someone with a university background, not a company one. We might have had a bit more freedom to mess around, and even mess up. And a small base of sophisticated users rather than a large number of likely unskilled users. Cheers, David.
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On Thu, 2024-01-18 at 07:14 -0500, Greg Wooledge wrote: > On Thu, Jan 18, 2024 at 12:28:58PM +0100, hw wrote: > > Ok, and what's the problem? That the server wants to print to the > > printer? That the application sends data to the "screen" (a terminal > > emulator) instead of sending it to the printer? That it is necessary > > to see the printer data displayed in a terminal emulator? > > See, now we're going in circles again. I already *asked* the OP to > explain the full picture, and they still only gave a partial answer. > > It has been hinted to us that there are more layers in the problem > than simply Server <--> PC --> Printer. We've been told that there > is another layer of devices connected to the Printer, although this > was never confirmed in the "big picture" answer. > > Apparently the (retail sales??) application on the server needs to > talk to all three layers of hardware: the PC (to display information > on the screen), the Printer (to generate ink on paper), and the other > devices beyond the Printer (reasons never given). Communication with > the devices beyond the Printer is apparently "bidirectional", meaning > the server application needs to be able to query one of these devices > and get information from it, which will cause application state to > be altered, information to appear on the screen, etc. Or maybe the > devices beyond the Printer are capable of initiating an async data > transfer to the server app? Who knows. It was never clearly stated. > > Apparently the OP has a proprietary Windows terminal emulator + telnet > client program (name never revealed?) that can already do everything, > and they want a Debian program that can be used in place of it. > > The problem for *us* is that we don't know what "everything" is (since > the OP is incapable of explaining it all), which makes it very hard > to find a program that can do "everything". Hm ok, it's all too much guesswork then.
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On Thu, Jan 18, 2024 at 12:28:58PM +0100, hw wrote: > Ok, and what's the problem? That the server wants to print to the > printer? That the application sends data to the "screen" (a terminal > emulator) instead of sending it to the printer? That it is necessary > to see the printer data displayed in a terminal emulator? See, now we're going in circles again. I already *asked* the OP to explain the full picture, and they still only gave a partial answer. It has been hinted to us that there are more layers in the problem than simply Server <--> PC --> Printer. We've been told that there is another layer of devices connected to the Printer, although this was never confirmed in the "big picture" answer. Apparently the (retail sales??) application on the server needs to talk to all three layers of hardware: the PC (to display information on the screen), the Printer (to generate ink on paper), and the other devices beyond the Printer (reasons never given). Communication with the devices beyond the Printer is apparently "bidirectional", meaning the server application needs to be able to query one of these devices and get information from it, which will cause application state to be altered, information to appear on the screen, etc. Or maybe the devices beyond the Printer are capable of initiating an async data transfer to the server app? Who knows. It was never clearly stated. Apparently the OP has a proprietary Windows terminal emulator + telnet client program (name never revealed?) that can already do everything, and they want a Debian program that can be used in place of it. The problem for *us* is that we don't know what "everything" is (since the OP is incapable of explaining it all), which makes it very hard to find a program that can do "everything".
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On Wed, 2024-01-17 at 23:08 -0600, David Wright wrote: > On Tue 16 Jan 2024 at 11:47:53 (+0100), hw wrote: > > On Mon, 2024-01-15 at 20:32 +0100, to...@tuxteam.de wrote: > > > On Mon, Jan 15, 2024 at 08:08:36PM +0100, hw wrote: > > > > > > > > I don't understand why you involve a terminal emulator in the process. > > > > Do you need to see the data that goes through the COM port displayed > > > > in a terminal (like minicom)? > > > > > > People interact with the (remote) application by means of the terminal > > > emulator. Things get sent to/from the printer based on escape sequences > > > initiated by the application. > > > > Desktop sharing works fine with gnome these days. Why not interact > > with the application through that kinda locally? > > > > > In the original (proprietary) application, the dispatching functionality > > > > Dispatching functionality? > > > > > is integrated in the terminal emulator, so it is understandable that > > > pheoebus phoebus wants to keep that structure in the replacement. > > > > I don't understand. > > > > > I proposed splitting off the "mux" functionality from the terminal > > > emulator functionality, but I fully understand that phoebus phoebus > > > favours the more "conservative" approach. > > > > > > By the way -- back then (TM), when terminals were real things, it was > > > not unheard of that they came with an attached printer and some bar > > > code scannery -- all handily multiplexed over the RS-232 (or something > > > more monstruous), orchestrated via intricate escapery. > > > > > > So the thing is just a natural evolution dating back to The Dinosaurs. > > > > Well, I'd have to be quit a bit older to have experienced "real" > > terminals like that. I do remember printers accepting some escape > > sequences to control their functionality, though. > > > > If this application is running on such a terminal, maybe it's time to > > find a more modern und thus more feasible replacement ... An ancient > > terminal may cease to work eventually and be very difficult to repair > > once it does ... > > It isn't running on a terminal: tomas wrote "back then (TM), when > terminals were real things". > > It's running on a Windows PC. Walk into many a shop and you can see > the sort of setup, a PC and screen with a barcode scanner, keyboard, > credit card reader, receipt printer, etc, all hanging off it. The > server might be in an office, or perhaps at HQ or in the cloud. > All perfectly normal. The import of the thread is Windows → Linux. Ok, and what's the problem? That the server wants to print to the printer? That the application sends data to the "screen" (a terminal emulator) instead of sending it to the printer? That it is necessary to see the printer data displayed in a terminal emulator?
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On Tue 16 Jan 2024 at 11:47:53 (+0100), hw wrote: > On Mon, 2024-01-15 at 20:32 +0100, to...@tuxteam.de wrote: > > On Mon, Jan 15, 2024 at 08:08:36PM +0100, hw wrote: > > > > > > I don't understand why you involve a terminal emulator in the process. > > > Do you need to see the data that goes through the COM port displayed > > > in a terminal (like minicom)? > > > > People interact with the (remote) application by means of the terminal > > emulator. Things get sent to/from the printer based on escape sequences > > initiated by the application. > > Desktop sharing works fine with gnome these days. Why not interact > with the application through that kinda locally? > > > In the original (proprietary) application, the dispatching functionality > > Dispatching functionality? > > > is integrated in the terminal emulator, so it is understandable that > > pheoebus phoebus wants to keep that structure in the replacement. > > I don't understand. > > > I proposed splitting off the "mux" functionality from the terminal > > emulator functionality, but I fully understand that phoebus phoebus > > favours the more "conservative" approach. > > > > By the way -- back then (TM), when terminals were real things, it was > > not unheard of that they came with an attached printer and some bar > > code scannery -- all handily multiplexed over the RS-232 (or something > > more monstruous), orchestrated via intricate escapery. > > > > So the thing is just a natural evolution dating back to The Dinosaurs. > > Well, I'd have to be quit a bit older to have experienced "real" > terminals like that. I do remember printers accepting some escape > sequences to control their functionality, though. > > If this application is running on such a terminal, maybe it's time to > find a more modern und thus more feasible replacement ... An ancient > terminal may cease to work eventually and be very difficult to repair > once it does ... It isn't running on a terminal: tomas wrote "back then (TM), when terminals were real things". It's running on a Windows PC. Walk into many a shop and you can see the sort of setup, a PC and screen with a barcode scanner, keyboard, credit card reader, receipt printer, etc, all hanging off it. The server might be in an office, or perhaps at HQ or in the cloud. All perfectly normal. The import of the thread is Windows → Linux. Cheers, David.
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On Mon, 2024-01-15 at 20:32 +0100, to...@tuxteam.de wrote: > On Mon, Jan 15, 2024 at 08:08:36PM +0100, hw wrote: > > Hi, > > > > I don't understand why you involve a terminal emulator in the process. > > Do you need to see the data that goes through the COM port displayed > > in a terminal (like minicom)? > > People interact with the (remote) application by means of the terminal > emulator. Things get sent to/from the printer based on escape sequences > initiated by the application. Desktop sharing works fine with gnome these days. Why not interact with the application through that kinda locally? > In the original (proprietary) application, the dispatching functionality Dispatching functionality? > is integrated in the terminal emulator, so it is understandable that > pheoebus phoebus wants to keep that structure in the replacement. I don't understand. > I proposed splitting off the "mux" functionality from the terminal > emulator functionality, but I fully understand that phoebus phoebus > favours the more "conservative" approach. > > By the way -- back then (TM), when terminals were real things, it was > not unheard of that they came with an attached printer and some bar > code scannery -- all handily multiplexed over the RS-232 (or something > more monstruous), orchestrated via intricate escapery. > > So the thing is just a natural evolution dating back to The Dinosaurs. Well, I'd have to be quit a bit older to have experienced "real" terminals like that. I do remember printers accepting some escape sequences to control their functionality, though. If this application is running on such a terminal, maybe it's time to find a more modern und thus more feasible replacement ... An ancient terminal may cease to work eventually and be very difficult to repair once it does ...
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On Mon Jan 15th, 2024 at 18:19, phoebus phoebus wrote: > Hello, > > >> I confess I have not read all messages. I think "expect" might be the > program > >> you need. > > Thank you for your suggestion and assistance. While 'Expect' is primarily > designed to automate interactions with text-based programs, its use for > intercepting and managing escape sequences to enable pass-through mode on a > terminal screen is complex, particularly in the specific context and > configuration of our POS system. > > Given that the terminal needs to interact very frequently and dynamically > with the printer based on real-time feedback from the server, I believe > that 'Expect' may not be the best solution for our situation. It is > generally more suitable for scripted interactions and predictable scenarios. > > I appreciate your input, and if you have any alternative suggestions or > insights that align more closely with our requirements, I would be grateful > for your guidance. > You may need to write the program yourself. It's probably not very complicated, but you have to be accustomed to writing programs. I'd write it in C, forking an ssh (or whatever is needed to connect to your server), leaving its standard input untouched, and piping its standard output to your program. Your program would send the data it receives to its own standard output, except between pairs of "magical escape sequences", where it would send the data either to the COM port, or to whatever program that may be needed. Best, Loïc
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On Mon, Jan 15, 2024 at 08:08:36PM +0100, hw wrote: > Hi, > > I don't understand why you involve a terminal emulator in the process. > Do you need to see the data that goes through the COM port displayed > in a terminal (like minicom)? People interact with the (remote) application by means of the terminal emulator. Things get sent to/from the printer based on escape sequences initiated by the application. In the original (proprietary) application, the dispatching functionality is integrated in the terminal emulator, so it is understandable that pheoebus phoebus wants to keep that structure in the replacement. I proposed splitting off the "mux" functionality from the terminal emulator functionality, but I fully understand that phoebus phoebus favours the more "conservative" approach. By the way -- back then (TM), when terminals were real things, it was not unheard of that they came with an attached printer and some bar code scannery -- all handily multiplexed over the RS-232 (or something more monstruous), orchestrated via intricate escapery. So the thing is just a natural evolution dating back to The Dinosaurs. Cheers -- t signature.asc Description: PGP signature
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
> Unfortunately, COM ports have become quite rare :( They disappeared from almost all my computers, indeed (except for serial consoles on SBCs), but I see them quite often among the various pieces of hardware in checkout counters. Stefan
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hi, I don't understand why you involve a terminal emulator in the process. Do you need to see the data that goes through the COM port displayed in a terminal (like minicom)? I do not understand what you are trying to do at all. Are you trying to print to a remote printer that has a serial port? For that, perhaps you could use a printserver with a serial port (if you can find one) or a printserver and an adapter from parallel to serial. If you're trying to create a two-way communication between a remote server and a remote client, with the client sending and receiving the data through its COM port (for some weird reason), you could do that over ethernet, using your own protocol or an existing one (maybe even xmpp). Unfortunately, COM ports have become quite rare :( On Sat, 2024-01-13 at 00:50 +, phoebus phoebus wrote: > Hello, > > > > Suggestion: Make another description of the challenge. > > > > > > Describe it as a travelling route. Spend effort on telling > > > what the endpoints were and are. > > > Our current starting point as being a third-party terminal emulator provided > by a licensed company. This emulator runs on an outdated version of Windows > and older Wyse versions and supports only the Telnet protocol, limiting our > ability to establish secure connections. > > Now, our mandatory choice, if no other alternative emerges is to upgrade our > infrastructure by transitioning to newer Wyse clients equipped with more > recent versions of Windows and migrating to the commercial emulator from the > same company (or another) which supports the SSH protocol and Passthrough > Printing. We aim to migrate to an open-source terminal emulator that supports > the Passthrough Printing, thereby offering improved security and this remains > our preferred path. > > Currently, PuTTY is an option but its current version has limitations that > make it insufficient for our operational use. > We have conducted research in our quest to find such an open-source emulator > with full Passthrough Printing, but thus far, we have been unable to identify > one that fully meets our needs. > > Best Regards, > Thierry >
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >> I confess I have not read all messages. I think "expect" might be the program >> you need. Thank you for your suggestion and assistance. While 'Expect' is primarily designed to automate interactions with text-based programs, its use for intercepting and managing escape sequences to enable pass-through mode on a terminal screen is complex, particularly in the specific context and configuration of our POS system. Given that the terminal needs to interact very frequently and dynamically with the printer based on real-time feedback from the server, I believe that 'Expect' may not be the best solution for our situation. It is generally more suitable for scripted interactions and predictable scenarios. I appreciate your input, and if you have any alternative suggestions or insights that align more closely with our requirements, I would be grateful for your guidance. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Dear Thierry, On Fru Jan 12th, 2024 at 05:08, phoebus phoebus wrote: > Dear members of the Debian community, > > I am currently on the lookout for a terminal emulator on Debian that can > handle controlled printing from a remote server often referred to as > "passthrough" printing. Our specific requirement is the ability to select > the printing device using a specific method, either the physical COM port > or the virtual COM port (emulated by a USB device). > > To be more precise, we want the terminal emulator to transmit data exactly > as it is received from a remote server (which is a Linux server) when it > attempts to print data through a set of escape sequences to send text in > transparent mode. This transmission should be directed to the COM device > without any modifications. > > We have noticed that PuTTY allows "passthrough" printing but > unfortunately, it only works unidirectionally and requires the use of a > serial software printer which also supports only unidirectional flow. While > PuTTY can manage connections to devices via the serial port > bidirectionally, it does not provide a solution to manage "passthrough" > printing directly to the COM port. This configuration is described in the > PuTTY documentation (https://documentation.help/PuTTY/config-printing.html > ). > > Our application runs on Linux and needs to communicate with a specialized > serial printer by sending data directly to it through a terminal emulator > on a client machine (with the printer connected to the client machine's > serial port). > > The purpose of my request is to explore the possibility of moving away > from a third-party terminal emulator that runs on Windows and is compatible > with somewhat older hardware and operating systems. > > I have conducted research within the list of available emulators on Debian > but have not yet found a solution that meets our requirements. Therefore, I > am reaching out to seek your assistance and suggestions. I have tried Tera > Term (https://osdn.net/projects/ttssh2/releases/) but it does not offer > the desired functionality. > > If you have any ideas or recommendations for a Debian terminal emulator > capable of bidirectional "passthrough" printing, I would greatly appreciate > hearing from you. > > Thank you in advance for your assistance and valuable suggestions. > I confess I have not read all messages. I think "expect" might be the program you need. Best, Loïc
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On Sat, Jan 13, 2024 at 1:14 PM gene heskett wrote: > > The 6809 cpu in the coco was first with program counter independant > code, put it anyplace in memory and it just ran, so we showed the pc's > of the day a much shorter, faster way home. But I've Been Moved chose > intel 8088's and dos and had a bigger advertising budget. That and > nobody ever got fired for buying IBM. After writing 8080 assembly code the 6809 was a breath of fresh air. Then the 68000, I think the first microprocessor Unix was ported to. >
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >> You don't mention it, but did you look at CKW (C-Kermit 10.0 for >> Microsoft Windows)? No, I didn't look into CKW 10, that's true. I skimmed through the description of Kermit 95 (from 2003) and that of C-Kermit 9 too quickly and didn't consider that CKW 10 is the full replacement for Kermit 95. >> In any event it seems it might be worth your time to contact the kermit >> developers as well as the putty developers. Yes, absolutely. Thank you for the advice. I will reach out to the Kermit project developers in addition to those of PuTTY. Thank you. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
phoebus phoebus wrote: > Hello, > > >> Clearly we don't know of any terminal > >> emulators that do what you want. (I assume you've already looked > >> at kermit, and found it lacking... yes? OK then.) > > I want to express my sincere gratitude for pointing me to this > project. I wasn't familiar with the Kermit terminal emulator before > but after looking at their website, I believe that Kermit 95's > feature set should address my needs. The features such as: > * Copy/paste, print, searching, and bookmarks in the scrollback > buffer > * Host-directed and local printing > * Versatile printer control, including bidirectional printers and > built-in Text/PostScript conversion seem to align with my > requirements. > > I also explored E-Kermit (Kermit for Embedding) since we were asked > if there was an emulator that could perform these functions in an > embedded environment. However, based on what it does not do, it > doesn't seem to be the solution I was hoping for. Regarding the > purely Linux/Unix C-Kermit, it appears to be less feature-rich > compared to Kermit 95, so it may not be the best fit for my > requirements. You don't mention it, but did you look at CKW (C-Kermit 10.0 for Microsoft Windows)? In any event it seems it might be worth your time to contact the kermit developers as well as the putty developers.
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On Sun, Jan 14, 2024 at 10:25:06AM +, phoebus phoebus wrote: > Hello, > > >> One viable approach is the one proposed by Stefan et al (modify an > >> existing terminal emulator) [...] > I fully endorse the approach proposed by Stefan et al, as well as the > implementation logic for the terminal emulator part. However, as a system > administrator and not a developer, I will seek out existing projects or > solutions that provide these features. > Thank you once again for your valuable assistance. Glad if I could contribute a grain of help. Keeping fingers crossed that you succeed in your endeavour. Every bit of free software out there helping people do their thing makes the world a bit better. Cheers -- t signature.asc Description: PGP signature
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >> One viable approach is the one proposed by Stefan et al (modify an >> existing terminal emulator). I'd tend to separate concerns and just >> write the application part as a separate process accepting a bidi >> connection to SSH, one to a terminal emulator, and one to the serial >> port (OK, some error and diagnostic logging too). The classical >> thing built around a select() loop, with some extended state >> automaton in it. I fully endorse the approach proposed by Stefan et al, as well as the implementation logic for the terminal emulator part. However, as a system administrator and not a developer, I will seek out existing projects or solutions that provide these features. Thank you once again for your valuable assistance. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >> Clearly we don't know of any terminal >> emulators that do what you want. (I assume you've already looked at >> kermit, and found it lacking... yes? OK then.) I want to express my sincere gratitude for pointing me to this project. I wasn't familiar with the Kermit terminal emulator before but after looking at their website, I believe that Kermit 95's feature set should address my needs. The features such as: * Copy/paste, print, searching, and bookmarks in the scrollback buffer * Host-directed and local printing * Versatile printer control, including bidirectional printers and built-in Text/PostScript conversion seem to align with my requirements. I also explored E-Kermit (Kermit for Embedding) since we were asked if there was an emulator that could perform these functions in an embedded environment. However, based on what it does not do, it doesn't seem to be the solution I was hoping for. Regarding the purely Linux/Unix C-Kermit, it appears to be less feature-rich compared to Kermit 95, so it may not be the best fit for my requirements. >> At this point, I don't think you're talking to the right mailing list. >> We're just Debian users. >> If you need new features to be added to an existing Free terminal >> emulator, or even to have a whole new one developed from the ground up, >> this is not the mailing list for that. My initial goal was to find an equivalent of a proprietary emulator for Linux, particularly on our preferred Debian platform. I completely agree that this mailing list is not the place to discuss adding features to an emulator or creating a new one from scratch. >> Find the project that comes >> closest to your needs, and talk to the developers of that project. I also agree that for the terminal emulator I want to enhance, I should locate the project and directly engage with their team. This is precisely what i'm trying to do with the PuTTY team. In any case, the Debian community through the constructive exchange has been tremendously helpful and beneficial in my search. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On Sat, Jan 13, 2024 at 09:32:44PM +, phoebus phoebus wrote: > Hello, > > I understand that the situation may seem complex and i apologize if my > previous messages did not provide a clear overview of the problem. Allow me > to summarize our current situation. > In this response, I will incorporate the various comments made by Greg, > Charles Tomas, and incorporate a significant portion of Greg's excellent > summary. [...] Thanks for the detailed explanation -- and no need to apologize. Elephants are complex beasts :-) This was to me at least a delightful example of trying to come to a common understanding "Ah, yes, you're right: this feels like a trunk!". Thank you for your patience, too. One viable approach is the one proposed by Stefan et al (modify an existing terminal emulator). I'd tend to separate concerns and just write the application part as a separate process accepting a bidi connection to SSH, one to a terminal emulator, and one to the serial port (OK, some error and diagnostic logging too). The classical thing built around a select() loop, with some extended state automaton in it. And this is where I disagree with Greg (what doesn't happen very often). Some of us do love elephants :-) Cheers -- t signature.asc Description: PGP signature
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
> Thank you for your suggestion. As I mentioned earlier, our development team > primarily focuses on the server-side application and is not competent to > modify the client-side emulator, which is crucial in our case. They have > already examined the PuTTY source code and confirmed that this type of > development is beyond their expertise. The description of what the terminal emulator is expected to do is reasonably simple that anyone who has a bit of familiarity with the implementation of a terminal emulator should be able to add such a feature fairly quickly. Admittedly, the bidirectional part means there can be tricky issue when the user hits keys at the same time as the printer sends information back, but I'd suggest you try and contact various terminal emulator teams to see if someone would be interested (I'm thinking of people who worked on PuTTY or derivatives (Le PuTTY and TuTTY seem quite relevant, for example), or things like libvterm, ...). Even if the corresponding doesn't necessarily make it upstream, it's probably a better investment than paying for the license of a proprietary product which will force you into the same problem again a few years down the road. Stefan
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On Sun, Jan 14, 2024 at 12:31:57AM +, phoebus phoebus wrote: > Yes, that's the basic concept, but it's even more intricate. The application > continuously monitors what it receives from the terminal with regular > interval checks (in milliseconds) and makes decisions based on rules. These > decisions include sending commands to the printer, analyzing the responses, > taking user actions, and even restricting user input in certain menu or > submenu areas of the screen. However, I have a high-level understanding of > this process as I'm not part of the application development team to delve > into the finer details. More elephant parts. *shakes head* At this point, I don't think you're talking to the right mailing list. We're just Debian users. Clearly we don't know of any terminal emulators that do what you want. (I assume you've already looked at kermit, and found it lacking... yes? OK then.) If you need new features to be added to an existing Free terminal emulator, or even to have a whole new one developed from the ground up, this is not the mailing list for that. Find the project that comes closest to your needs, and talk to the developers of that project.
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >> I take it that by "the proprietary software" you mean the proprietary >> terminal emulator running on the client PC. Yes, that's correct. "The proprietary software" refers to the proprietary terminal emulator running on the client PC. >> One thing you might be able to do quickly is establish an SSH tunnel >> between the PC and the server, then route the proprietary terminal >> emulator telnet traffic through the tunnel. That, at least, will get >> you a more secure connection between the PC and the server. We've actually tested that approach before, but it introduced several technical challenges, and even though we managed to resolve some of them, it added complexity to the maintenance process. Additionally, it's important to consider that our end-users are not IT professionals but individuals primarily focused on sales. We need to encapsulate the entire process in a way that's transparent to the user, involving opening a program that initiates an SSH session within a tunnel, followed by launching the proprietary emulator for a Telnet session within that tunnel. We're also revisiting our workstation authentication process to transmit information through it in order to identify different application sessions, as the application on the server appears to be originating from localhost. Furthermore, we're reevaluating the mechanism for checking the number of sessions originating from each workstation based on the assigned roles. We're addressing various technical aspects, but this solution was ultimately rejected by the project team as it was perceived as a workaround, not robust and fragile. It posed risks to the business in a critical part of our operations. >> If I understand things correctly, the server sends all sorts of >> information to the proprietary terminal emulator. Most of that gets >> displayed on the emulator. But, given one VT escape code, the emulator >> sends the subsequent data off to the printer, until it gets the other >> VT escape code. The printer may then return a response. Yes, that's the basic concept, but it's even more intricate. The application continuously monitors what it receives from the terminal with regular interval checks (in milliseconds) and makes decisions based on rules. These decisions include sending commands to the printer, analyzing the responses, taking user actions, and even restricting user input in certain menu or submenu areas of the screen. However, I have a high-level understanding of this process as I'm not part of the application development team to delve into the finer details. >> If that understanding is correct, I suggest you grab an existing open >> source terminal program that supports VT escape codes: >> >> 1) Modify how it handles those two escape codes. >> >> 2) Modify it to listen to the printer for responses, encode those >> appropriately, and ship them to the server. >> >> I haven't worked with VT escape sequences in decades. If I recall >> correctly, some escape sequences cause the terminal to send information >> back to the server. In that case, you may need to synchronize return >> information from the printer with other return information. Thank you for your suggestion. As I mentioned earlier, our development team primarily focuses on the server-side application and is not competent to modify the client-side emulator, which is crucial in our case. They have already examined the PuTTY source code and confirmed that this type of development is beyond their expertise. That's why we are exploring open-source solutions that offer a plug-and-play feature set or potentially an evolution of PuTTY. If we don't find a suitable open-source solution, we will consider commercial emulators that integrate this functionality. As a last resort, we might opt for a proprietary solution and pay for the licenses and maintenance required for the work done in that product. The suggestion you made to adapt an open-source terminal program to support VT escape codes is certainly relevant, but unfortunately, it goes beyond our current expertise and that of our team Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On Sat, 13 Jan 2024 21:32:44 + (UTC) phoebus phoebus wrote: > I have a client workstation with a proprietary terminal emulator > running on Windows. This PC is connected to a POS printer via a COM > serial port. The client workstation along with the printer and other > connected devices, forms the client-side of our Point of Sale (POS) > system. … > The printer model is a Thermal Line Dot Printing type and it supports > the ESC/POS command system, created by Epson, which provides > efficient and functional commands for communication with the printer. > For more information on ESC/POS, please refer to this site: > https://download4.epson.biz/sec_pubs/pos/reference_en/escpos/index.html This article was very helpful. > Our objective is to explore open-source solutions for this > configuration as we aim to replace the proprietary software. I take it that by "the proprietary software" you mean the proprietary terminal emulator running on the client PC. One thing you might be able to do quickly is establish an SSH tunnel between the PC and the server, then route the proprietary terminal emulator telnet traffic through the tunnel. That, at least, will get you a more secure connection between the PC and the server. If I understand things correctly, the server sends all sorts of information to the proprietary terminal emulator. Most of that gets displayed on the emulator. But, given one VT escape code, the emulator sends the subsequent data off to the printer, until it gets the other VT escape code. The printer may then return a response. If that understanding is correct, I suggest you grab an existing open source terminal program that supports VT escape codes: 1) Modify how it handles those two escape codes. 2) Modify it to listen to the printer for responses, encode those appropriately, and ship them to the server. I haven't worked with VT escape sequences in decades. If I recall correctly, some escape sequences cause the terminal to send information back to the server. In that case, you may need to synchronize return information from the printer with other return information. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >> I'd just suggest checking with the PuTTY team before hand if they'd be >> interested in adding the functionality. Sure, a ready-to-apply patch >> increases the chances, but this seems like a very specific feature that >> very few people seem to need, so they might not want to add extra >> complexity to the software. You raise a valid point, and I appreciate your input. Before proceeding with any development or prototype, it would indeed be wise to reach out to the PuTTY team to gauge their interest in adding this specific functionality. Understanding their perspective on its relevance and complexity is crucial. I've already made initial contact but I'm still waiting for their response. I'll continue to pursue this avenue in the hope of receiving a response and initiating a dialogue. Thank you for highlighting this aspect of the process. Best Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, I understand that the situation may seem complex and i apologize if my previous messages did not provide a clear overview of the problem. Allow me to summarize our current situation. In this response, I will incorporate the various comments made by Greg, Charles Tomas, and incorporate a significant portion of Greg's excellent summary. I have a client workstation with a proprietary terminal emulator running on Windows. This PC is connected to a POS printer via a COM serial port. The client workstation along with the printer and other connected devices, forms the client-side of our Point of Sale (POS) system. This client workstation is supported by various hardware devices, including barcode scanners and payment terminals. However, these barcode scanners and payment terminals are not within the scope of my current focus, which is to find open-source alternatives to proprietary solutions for our specific terminal emulator. The printer model is a Thermal Line Dot Printing type and it supports the ESC/POS command system, created by Epson, which provides efficient and functional commands for communication with the printer. For more information on ESC/POS, please refer to this site: https://download4.epson.biz/sec_pubs/pos/reference_en/escpos/index.html The client PC connects to the server via Telnet but now, as part of our project, it uses SSH for secure connections. **It initiates a connection to the server to establish an interactive session.** **At some point, the application will initiate a communication session to the "printer" and to the "other device" THROUGH the "printer", all tunneled THROUGH the telnet or ssh session using "bidirectional passthrough printing"**. Depending on the set of ASCII code sequences sent by the server, the terminal either displays characters on the screen or sends the command stream to the printer. In our case, it sends this stream to a serial port. All commands received by the printer begin with ESC (ASCII 27, HEX 1B) or GS (ASCII 29, HEX 1D), followed by another character specifying the command. Normal text elements are simply sent separated by line breaks to the printer. The passthrough printing concept is well explained in this guide by Anzio: https://www.anzio.com/resources/guide-anzios-passthrough-printing. Our server-side application, written in C, follows the same principle of code execution with the client workstation via the terminal emulator. Please note that our legacy proprietary terminal emulator is not the one provided by Anzio; however, in the context of considering a proprietary replacement solution, Anzio's solution is among those being evaluated. Our objective is to explore open-source solutions for this configuration as we aim to replace the proprietary software. I want to express my gratitude for your patience and valuable insights. Please let me know if this response now helps to clarify the situation. Best Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On 1/13/24 11:10, to...@tuxteam.de wrote: On Sat, Jan 13, 2024 at 08:55:22AM -0700, Charles Curley wrote: On Sat, 13 Jan 2024 09:59:48 -0500 Greg Wooledge wrote: The real problem here is that we're all blind men trying to grasp the elephant. A good summary of what we know so far. I suspect that the OP should question whether it's time to scrap the elephant entirely, and re-think the problem de novo. Remember that an elephant is a horse designed by a committee. The elephant would disagree. Ported back from the metaphor this means that there are two sides to this story and we might learn something new by trying to take up the OP's point of view. My guess was that the functionality exists in the Unix-y world, but the building blocks might be called differently. See, back then, Unix-y was "the mainframe" and PCs often played the terminals (reflected on the serial ports, back then when PCs had some: they have a terminal's gender). This was what led me to minicom (and friends): what did one use back then to talk to a modem? I go back even further than that, Tomas, on a color computer I used either supercom or vt220, a terminal emulator that I made out of Brian Marquettes vt100, middle to later 80's time. The color computers had an aftermarket os called os9, was a microware supplied mini-unix that ran on a machine with only 64k of memory, 50+ years ago. Anybody here remember that? The 6809 cpu in the coco was first with program counter independant code, put it anyplace in memory and it just ran, so we showed the pc's of the day a much shorter, faster way home. But I've Been Moved chose intel 8088's and dos and had a bigger advertising budget. That and nobody ever got fired for buying IBM. Sadly the OP hasn't had a look into that, so I won't know ;-) (To be fair: so many proposals to choose from, the OP has to prune things to come to an end). Cheers Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Charles Curley wrote: > On Sat, 13 Jan 2024 09:59:48 -0500 > Greg Wooledge wrote: > > > The real problem here is that we're all blind men trying to grasp > > the elephant. > > A good summary of what we know so far. I suspect that the OP should > question whether it's time to scrap the elephant entirely, and > re-think the problem de novo. Remember that an elephant is a horse > designed by a committee. AIUI a camel is a horse designed by committee (possibly said by Issigonis). An elephant is supposedly a mouse designed by committee (particularly an American committee IMHO :)
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On Sat, Jan 13, 2024 at 08:55:22AM -0700, Charles Curley wrote: > On Sat, 13 Jan 2024 09:59:48 -0500 > Greg Wooledge wrote: > > > The real problem here is that we're all blind men trying to grasp > > the elephant. > > A good summary of what we know so far. I suspect that the OP should > question whether it's time to scrap the elephant entirely, and re-think > the problem de novo. Remember that an elephant is a horse designed by a > committee. The elephant would disagree. Ported back from the metaphor this means that there are two sides to this story and we might learn something new by trying to take up the OP's point of view. My guess was that the functionality exists in the Unix-y world, but the building blocks might be called differently. See, back then, Unix-y was "the mainframe" and PCs often played the terminals (reflected on the serial ports, back then when PCs had some: they have a terminal's gender). This was what led me to minicom (and friends): what did one use back then to talk to a modem? Sadly the OP hasn't had a look into that, so I won't know ;-) (To be fair: so many proposals to choose from, the OP has to prune things to come to an end). Cheers -- t signature.asc Description: PGP signature
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On Sat, 13 Jan 2024 09:59:48 -0500 Greg Wooledge wrote: > The real problem here is that we're all blind men trying to grasp > the elephant. A good summary of what we know so far. I suspect that the OP should question whether it's time to scrap the elephant entirely, and re-think the problem de novo. Remember that an elephant is a horse designed by a committee. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On 14/01/24 03:59, Greg Wooledge wrote: I have dealt with terminals with passthrough printers before, but it was three decades ago, and I've certainly never heard of a printer communicating *back* to the host over this channel I've also set up passthrough printers on terminals - which were hanging off muxes ... it's a serial connection, so bidirectional commumination should be fine, and more recent printers would make use of that. And in fact, when we ran out of mux ports, we even hung an extra terminal off the passthrough port, so bidirectional worked :-) These were physical serial terminals, of course - I don't remember having to get a terminal emulator to do this. It also wasn't on Linux - some were on SCO, and the others might have been on some kind of mainframe - a government department. We weren't involved in that side of it. Richard
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On Sat, Jan 13, 2024 at 08:36:57AM +0100, to...@tuxteam.de wrote: > On Sat, Jan 13, 2024 at 01:20:46AM +, phoebus phoebus wrote: > > While 'ser2net' may be a valuable tool for certain purposes, it doesn't > > align with our specific requirements. Nevertheless, I'm grateful for the > > insight and knowledge you've shared. > > to me it's difficult to follow the discussion. Perhaps it is > because traditionally, in UNIX, the TTY functionality and > terminal emulators s are separated entities, whereas in the > DOS/Windows world both functionalities are often conflated. > > Have you had a look at minicom? The real problem here is that we're all blind men trying to grasp the elephant. Every time someone offers a suggestion, the OP responds with "No, that won't work, because..." and reveals another piece of the elephant. Unfortunately, at no time has the OP ever defined the entire problem. Here's what I've managed to piece together: 1) The OP currently has a working solution using proprietary software under Microsoft Windows, but would like an open source solution. 2) The problem involves at least four distinct pieces of equipment: * A server, accessed by telnet or by ssh (preferred). * A client PC, which accesses the server over the network. * A "printer" which is connected to the PC by serial(?) port. * Another device, not named, which is connected to the "printer" by some unnamed method. 3) Apparently, the client PC is supposed to initiate a connection to the server, to run some interactive application. 4) At some point, the application will initiate a communication session to the "printer" and to the "other device" THROUGH the "printer", all tunneled THROUGH the telnet or ssh session using "bidirectional passthrough printing". 5) This "bidirectional passthrough printing" (which I've never heard of) apparently allows the server application to perform data transfers between itself and the "other device", all while perhaps printing literal ink-on-paper on the "printer", all while still allowing the interactive application to run seamlessly on the client PC. I have dealt with terminals with passthrough printers before, but it was three decades ago, and I've certainly never heard of a printer communicating *back* to the host over this channel, let alone a printer having some other devices hanging off of it. (This makes me think the "printer" is not actually what we'd call a printer, but of course we haven't been told any of the details.)
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On 13/01/2024 11:00, phoebus phoebus wrote: I will now discuss this information with our project team to determine the best way to incorporate it. This includes considering presenting the idea to our management and potentially engaging a qualified third party to design a prototype. The goal would be to further develop these features beyond the initial stage, so that the PuTTY project team can seamlessly integrate them (ideally in the form of a ready-to-use patch). I'd just suggest checking with the PuTTY team before hand if they'd be interested in adding the functionality. Sure, a ready-to-apply patch increases the chances, but this seems like a very specific feature that very few people seem to need, so they might not want to add extra complexity to the software. -- Everything bows to success, even grammar. Eduardo M KALINOWSKI edua...@kalinowski.com.br
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >> Looking at >> https://www.chiark.greenend.org.uk/~sgtatham/putty/feedback.html#feedback-features >> suggests that you should try to design whatever features you require >> yourself in the first instance, and then submit it for consideration >> by the maintainers. And be prepared to implement it if required before >> submission to the project. I don't mean that you personally should do >> this, but rather that you should hire someone suitably qualified to do >> it. Specifically someone who is not part of the team, unless they >> volunteer. It sounds like their problem is lack of available effort. I genuinely appreciate these details and the clarification that I had overlooked. I will now discuss this information with our project team to determine the best way to incorporate it. This includes considering presenting the idea to our management and potentially engaging a qualified third party to design a prototype. The goal would be to further develop these features beyond the initial stage, so that the PuTTY project team can seamlessly integrate them (ideally in the form of a ready-to-use patch). >From my perspective, this approach offers distinct advantages over commercial >solutions in terms of licensing and maintenance costs. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
phoebus phoebus wrote: > Hello, > > >> > Currently, PuTTY is an option but its current version has > >> > limitations that make it insufficient for our operational use. > >> > >> > >> Commission the PuTTY authors to add the missing features or pay > >> someone else to do it if they aren't interested. > >> > >> https://www.chiark.greenend.org.uk/~sgtatham/putty/ > > > I have already tried to contact the PuTTY development team using the > email address pu...@projects.tartarus.org; however, I did not receive > a response. Originally, my request in that email was to explore the > possibility of commissioning the PuTTY authors or paying someone else > to add these features in case the development team was not interested. > > My goal in funding this project would be to have the code integrated > into the main PuTTY branch and become an integral part of official > releases, thus avoiding obsolescence. However, outside of the PuTTY > team, I am not certain of the best way to proceed to achieve this > goal. Therefore, I wonder if the address pu...@projects.tartarus.org > is the correct one to contact the project, and if anyone could > suggest a more appropriate contact address or any other suggestions > to advance this improvement proposal. Looking at https://www.chiark.greenend.org.uk/~sgtatham/putty/feedback.html#feedback-features suggests that you should try to design whatever features you require yourself in the first instance, and then submit it for consideration by the maintainers. And be prepared to implement it if required before submission to the project. I don't mean that you personally should do this, but rather that you should hire someone suitably qualified to do it. Specifically someone who is not part of the team, unless they volunteer. It sounds like their problem is lack of available effort. > Regards, > Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Trish, >> PuTTY is Simon Tatham's - >> https://www.chiark.greenend.org.uk/~sgtatham/. You might have more >> success there. Thank you for the suggestion. I have also utilized the information from the commit (https://git.tartarus.org/?p=simon/putty.git;a=commit;h=b846178443cf1a5dc7c5ea2079fd34fd465af497) mentioned on the indicated website and it corresponds to the email address found on Simon Tatham's website. However, it's worth noting that the email associated with Mastodon for the domain in .io does not appear to exist. I will rely on the email from the commit for now and I appreciate your assistance. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Thierry, > I have already tried to contact the PuTTY development team using the > email address pu...@projects.tartarus.org; however, I did not receive > a response. PuTTY is Simon Tatham's - https://www.chiark.greenend.org.uk/~sgtatham/. You might have more success there. -- Trish Fraser, VVMZ4 91L2V -35.67910, 142.66607 Sat 13 Jan 2024 20:12:46 AEDT GNU/Linux 1997-2023 #283226 counter.li.org andromeda up up 1 week, 1 day, 10 hours, 48 minutes Debian GNU/Linux 11 (bullseye) kernel 5.10.0-27-amd64 pgpBbKxJj_1EE.pgp Description: OpenPGP digital signature
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >> > Currently, PuTTY is an option but its current version has limitations >> > that make it insufficient for our operational use. >> >> >> Commission the PuTTY authors to add the missing features or pay someone >> else to do it if they aren't interested. >> >> https://www.chiark.greenend.org.uk/~sgtatham/putty/ I have already tried to contact the PuTTY development team using the email address pu...@projects.tartarus.org; however, I did not receive a response. Originally, my request in that email was to explore the possibility of commissioning the PuTTY authors or paying someone else to add these features in case the development team was not interested. My goal in funding this project would be to have the code integrated into the main PuTTY branch and become an integral part of official releases, thus avoiding obsolescence. However, outside of the PuTTY team, I am not certain of the best way to proceed to achieve this goal. Therefore, I wonder if the address pu...@projects.tartarus.org is the correct one to contact the project, and if anyone could suggest a more appropriate contact address or any other suggestions to advance this improvement proposal. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On Sat, Jan 13, 2024 at 01:20:46AM +, phoebus phoebus wrote: > Hello, > > >> I've always used 'ser2net' for that for of thing, mostly with single- > >> board computers attached via serial ports on a remote machine. But it > >> doesn't matter what the device is, it's a dumb pipe to transfer bytes > >> to/from a serial port on another computer. > > > Thank you for indicating the use of 'ser2net'. I appreciate your suggestion > and the information you provided. However, in our specific infrastructure, > the terminal emulator plays a central role due to the way our users access > the application and reauthenticate for printing purposes. This interaction is > seamless for our users and the terminal emulator serves as a crucial > component in managing the communication between the server and the various > devices, including the printer and others. > > While 'ser2net' may be a valuable tool for certain purposes, it doesn't align > with our specific requirements. Nevertheless, I'm grateful for the insight > and knowledge you've shared. Hi, to me it's difficult to follow the discussion. Perhaps it is because traditionally, in UNIX, the TTY functionality and terminal emulators s are separated entities, whereas in the DOS/Windows world both functionalities are often conflated. Have you had a look at minicom? You can give it a PTY at start (this would take care of the "serial over network" part, since your end will most probably a PTY) and you can give it a capture file (which might be what you're looking for, if I understood correctly). You run minicom "in" a terminal emulator, which may be xterm, the linux console or some of those fancy shmancy things desktop environments come with. Besides minicom there are other, less featureful, similar things. They don't count as "terminal emulators" in our strange unixy world, but they might be the missing piece you are looking for. Cheers -- t signature.asc Description: PGP signature
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Thierry writes: > Currently, PuTTY is an option but its current version has limitations > that make it insufficient for our operational use. Commission the PuTTY authors to add the missing features or pay someone else to do it if they aren't interested. https://www.chiark.greenend.org.uk/~sgtatham/putty/ -- John Hasler j...@sugarbit.com Elmwood, WI USA
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >> I've always used 'ser2net' for that for of thing, mostly with single- >> board computers attached via serial ports on a remote machine. But it >> doesn't matter what the device is, it's a dumb pipe to transfer bytes >> to/from a serial port on another computer. Thank you for indicating the use of 'ser2net'. I appreciate your suggestion and the information you provided. However, in our specific infrastructure, the terminal emulator plays a central role due to the way our users access the application and reauthenticate for printing purposes. This interaction is seamless for our users and the terminal emulator serves as a crucial component in managing the communication between the server and the various devices, including the printer and others. While 'ser2net' may be a valuable tool for certain purposes, it doesn't align with our specific requirements. Nevertheless, I'm grateful for the insight and knowledge you've shared. Best Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >> Suggestion: Make another description of the challenge. >> >> Describe it as a travelling route. Spend effort on telling >> what the endpoints were and are. Our current starting point as being a third-party terminal emulator provided by a licensed company. This emulator runs on an outdated version of Windows and older Wyse versions and supports only the Telnet protocol, limiting our ability to establish secure connections. Now, our mandatory choice, if no other alternative emerges is to upgrade our infrastructure by transitioning to newer Wyse clients equipped with more recent versions of Windows and migrating to the commercial emulator from the same company (or another) which supports the SSH protocol and Passthrough Printing. We aim to migrate to an open-source terminal emulator that supports the Passthrough Printing, thereby offering improved security and this remains our preferred path. Currently, PuTTY is an option but its current version has limitations that make it insufficient for our operational use. We have conducted research in our quest to find such an open-source emulator with full Passthrough Printing, but thus far, we have been unable to identify one that fully meets our needs. Best Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >> Is this also true of the Linux version of Putty? I've never used it but >> it's packaged in Debian. Also I wonder what it is you mean with >> "bidirectionally" here. Do you expect to read data from the printer and >> send it back? Yes, bidirectional communication is expected in both directions because behind this printer, several other devices are controlled through the printer, making the terminal a central point in the seamless interaction with the server for our users. What we aim to achieve is the ability to print directly to the COM port. While we are aware of commercial emulators that can accomplish this, we are exploring whether there are open-source alternatives that can provide the same functionality. Currently, this functionality is handled by a commercial emulator. >> Another thing I found with a quick search is screen. While screen is a >> terminal multiplexer, it has a user controllable setting printcmd for >> printing: >> >> "printcmd [cmd] >> >> If cmd is not an empty string, screen will not use the terminal >> capabilities "po/pf" if it detects an ansi print sequence ESC [ 5 i, but >> pipe the output into cmd. This should normally be a command like "lpr" >> or "'cat > /tmp/scrprint'". printcmd without a command displays the >> current setting. The ansi sequence ESC \ ends printing and closes the >> pipe. Warning: Be careful with this command! If other user have write >> access to your terminal, they will be able to fire off print commands." >> >> >From that description you should be able to set printcmd to for example >> cat > /dev/ttyUSB_whatever and the remote printing will go there. Screen does not have the capability to switch to transparent mode or specifically handle escape codes for printing natively, which it would receive from the application in order to pass to printcmd. Moreover, due to the continuous exchange based on the application's menus, managing this as an overlay to redirect the output to an external command could become quite complex. The printcmd feature in screen is primarily designed to redirect the output of the application to an external printing command. However, it is not intended to effectively handle bidirectional flows involving other devices. Thank you for the suggestion. Best Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
phoebus phoebus writes: > We have noticed that PuTTY allows "passthrough" printing but > unfortunately, it only works unidirectionally and requires the use of > a serial software printer which also supports only unidirectional > flow. While PuTTY can manage connections to devices via the serial > port bidirectionally, it does not provide a solution to manage > "passthrough" printing directly to the COM port. This configuration is > described in the PuTTY documentation > (https://documentation.help/PuTTY/config-printing.html). Is this also true of the Linux version of Putty? I've never used it but it's packaged in Debian. Also I wonder what it is you mean with "bidirectionally" here. Do you expect to read data from the printer and send it back? Another thing I found with a quick search is screen. While screen is a terminal multiplexer, it has a user controllable setting printcmd for printing: "printcmd [cmd] If cmd is not an empty string, screen will not use the terminal capabilities "po/pf" if it detects an ansi print sequence ESC [ 5 i, but pipe the output into cmd. This should normally be a command like "lpr" or "'cat > /tmp/scrprint'". printcmd without a command displays the current setting. The ansi sequence ESC \ ends printing and closes the pipe. Warning: Be careful with this command! If other user have write access to your terminal, they will be able to fire off print commands." >From that description you should be able to set printcmd to for example cat > /dev/ttyUSB_whatever and the remote printing will go there.
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >> Would it be correct to say that you don't care about the >> "terminal emulator" at all, and merely need a way for the Linux >> server to send data over the network to a serial port on a >> remote Debian machine which is attached to a printer? >> >> If so, I direct you to the sredird package. Thank you for suggesting this path. However, the terminal emulator plays a central role in our infrastructure because it is through this terminal emulator that users access the application and also have the ability to reauthenticate inside it for printing purposes. It's important to note that behind this printer, several other devices are controlled through the printer, making the terminal a central point in the seamless interaction with the server for our users. Therefore, the terminal emulator remains an integral component of our setup. Best regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >> It should be pretty easy to take an existing terminal emulator and add >> the corresponding functionality. While it might seem straightforward to enhance an existing terminal emulator with the required functionality, in practice, it involves a significant amount of custom development work. Unfortunately, we currently lack the necessary skills and resources to execute this successfully. Addressing this challenge would indeed require substantial development efforts, which can be quite challenging for our administrative system. As a result, I'm actively exploring alternative solutions that are more readily available, particularly open-source options, which align better with our specific needs. Best Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On Fri, 2024-01-12 at 06:08 -0500, Dan Ritter wrote: > Would it be correct to say that you don't care about the > "terminal emulator" at all, and merely need a way for the Linux > server to send data over the network to a serial port on a > remote Debian machine which is attached to a printer? > > If so, I direct you to the sredird package. I've always used 'ser2net' for that for of thing, mostly with single- board computers attached via serial ports on a remote machine. But it doesn't matter what the device is, it's a dumb pipe to transfer bytes to/from a serial port on another computer. -- Tixy
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
phoebus phoebus wrote: > Dear members of the Debian community, > > I am currently on the lookout for a terminal emulator on Debian that can > handle controlled printing from a remote server often referred to as > "passthrough" printing. Our specific requirement is the ability to select the > printing device using a specific method, either the physical COM port or the > virtual COM port (emulated by a USB device). > > To be more precise, we want the terminal emulator to transmit data exactly as > it is received from a remote server (which is a Linux server) when it > attempts to print data through a set of escape sequences to send text in > transparent mode. This transmission should be directed to the COM device > without any modifications. > > Our application runs on Linux and needs to communicate with a specialized > serial printer by sending data directly to it through a terminal emulator on > a client machine (with the printer connected to the client machine's serial > port). Would it be correct to say that you don't care about the "terminal emulator" at all, and merely need a way for the Linux server to send data over the network to a serial port on a remote Debian machine which is attached to a printer? If so, I direct you to the sredird package. -dsr-
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
On Fri, Jan 12, 2024 at 12:27:44AM +, phoebus phoebus wrote: > Dear members of the Debian community, > > I am currently on the lookout for a terminal emulator on Debian that > can handle controlled printing from a remote server often referred to > as "passthrough" printing. Our specific requirement is the ability to > select the printing device using a specific method, either the physical > COM port or the virtual COM port (emulated by a USB device). > > To be more precise, we want the terminal emulator to transmit data > exactly as it is received from a remote server (which is a Linux server) > when it attempts to print data through a set of escape sequences to > send text in transparent mode. This transmission should be directed > to the COM device without any modifications. > > We have noticed that PuTTY allows "passthrough" printing but > unfortunately, it only works unidirectionally and requires > the use of a serial software printer which also supports only > unidirectional flow. While PuTTY can manage connections to > devices via the serial port bidirectionally, it does not provide > a solution to manage "passthrough" printing directly to the COM > port. This configuration is described in the PuTTY documentation > (https://documentation.help/PuTTY/config-printing.html). > > Our application runs on Linux and needs to communicate with a > specialized serial printer by sending data directly to it through a > terminal emulator on a client machine (with the printer connected to > the client machine's serial port). > > The purpose of my request is to explore the possibility of moving > away from a third-party terminal emulator that runs on Windows and is > compatible with somewhat older hardware and operating systems. > > I have conducted research within the list of available > emulators on Debian but have not yet found a solution that > meets our requirements. Therefore, I am reaching out to > seek your assistance and suggestions. I have tried Tera Term > (https://osdn.net/projects/ttssh2/releases/) but it does not offer > the desired functionality. > > If you have any ideas or recommendations for a Debian terminal > emulator capable of bidirectional "passthrough" printing, I would > greatly appreciate hearing from you. > > Thank you in advance for your assistance and valuable suggestions. Suggestion: Make another description of the challenge. Describe it as a travelling route. Spend effort on telling what the endpoints were and are. > Best regards, Thierry Groeten Geert Stappers -- Silence is hard to parse signature.asc Description: PGP signature
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
> The purpose of my request is to explore the possibility of moving away from > a third-party terminal emulator that runs on Windows and is compatible with > somewhat older hardware and operating systems. It should be pretty easy to take an existing terminal emulator and add the corresponding functionality. Stefan
Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Dear members of the Debian community, I am currently on the lookout for a terminal emulator on Debian that can handle controlled printing from a remote server often referred to as "passthrough" printing. Our specific requirement is the ability to select the printing device using a specific method, either the physical COM port or the virtual COM port (emulated by a USB device). To be more precise, we want the terminal emulator to transmit data exactly as it is received from a remote server (which is a Linux server) when it attempts to print data through a set of escape sequences to send text in transparent mode. This transmission should be directed to the COM device without any modifications. We have noticed that PuTTY allows "passthrough" printing but unfortunately, it only works unidirectionally and requires the use of a serial software printer which also supports only unidirectional flow. While PuTTY can manage connections to devices via the serial port bidirectionally, it does not provide a solution to manage "passthrough" printing directly to the COM port. This configuration is described in the PuTTY documentation (https://documentation.help/PuTTY/config-printing.html). Our application runs on Linux and needs to communicate with a specialized serial printer by sending data directly to it through a terminal emulator on a client machine (with the printer connected to the client machine's serial port). The purpose of my request is to explore the possibility of moving away from a third-party terminal emulator that runs on Windows and is compatible with somewhat older hardware and operating systems. I have conducted research within the list of available emulators on Debian but have not yet found a solution that meets our requirements. Therefore, I am reaching out to seek your assistance and suggestions. I have tried Tera Term (https://osdn.net/projects/ttssh2/releases/) but it does not offer the desired functionality. If you have any ideas or recommendations for a Debian terminal emulator capable of bidirectional "passthrough" printing, I would greatly appreciate hearing from you. Thank you in advance for your assistance and valuable suggestions. Best regards, Thierry
