Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #265809 > unrolled thread
| Started by | phoebus phoebus <frphoebus@yahoo.fr> |
|---|---|
| First post | 2024-01-12 01:40 +0100 |
| Last post | 2024-01-22 15:30 +0100 |
| Articles | 20 on this page of 70 — 23 participants |
Back to article view | Back to linux.debian.user
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Seeking a Terminal Emulator on Debian for "Passthrough" Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-12 01:40 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Stefan Monnier <monnier@iro.umontreal.ca> - 2024-01-12 02:00 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-12 14:30 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Geert Stappers <stappers@stappers.nl> - 2024-01-12 07:30 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-13 02:00 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing John Hasler <john@sugarbit.com> - 2024-01-13 03:50 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-13 09:50 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Trish Fraser <trish@thefrasers.org> - 2024-01-13 10:40 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-13 12:10 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing debian-user@howorth.org.uk - 2024-01-13 14:00 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-13 15:10 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing hw <hw@adminart.net> - 2024-01-15 20:10 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Stefan Monnier <monnier@iro.umontreal.ca> - 2024-01-15 20:30 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing <tomas@tuxteam.de> - 2024-01-15 21:10 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing hw <hw@adminart.net> - 2024-01-16 11:50 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing David Wright <deblis@lionunicorn.co.uk> - 2024-01-18 06:10 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing hw <hw@adminart.net> - 2024-01-18 12:30 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Greg Wooledge <greg@wooledge.org> - 2024-01-18 13:20 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing hw <hw@adminart.net> - 2024-01-18 15:30 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough"Printing gene heskett <gheskett@shentel.net> - 2024-01-21 02:00 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough"Printing <tomas@tuxteam.de> - 2024-01-21 07:50 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough"Printing gene heskett <gheskett@shentel.net> - 2024-01-21 13:50 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough"Printing "Roy J. Tellason, Sr." <roy@rtellason.com> - 2024-01-21 19:40 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Max Nikulin <manikulin@gmail.com> - 2024-01-21 11:10 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing <tomas@tuxteam.de> - 2024-01-22 07:00 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Max Nikulin <manikulin@gmail.com> - 2024-01-22 16:10 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing <tomas@tuxteam.de> - 2024-01-22 16:30 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Stefan Monnier <monnier@iro.umontreal.ca> - 2024-01-22 16:40 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing <tomas@tuxteam.de> - 2024-01-22 18:50 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough"Printing gene heskett <gheskett@shentel.net> - 2024-01-23 04:00 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Max Nikulin <manikulin@gmail.com> - 2024-01-24 18:10 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Max Nikulin <manikulin@gmail.com> - 2024-01-23 18:10 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing David Wright <deblis@lionunicorn.co.uk> - 2024-01-23 18:20 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Max Nikulin <manikulin@gmail.com> - 2024-01-24 17:50 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing David Wright <deblis@lionunicorn.co.uk> - 2024-01-24 20:50 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Michael Stone <mstone@debian.org> - 2024-01-26 06:50 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing David Wright <deblis@lionunicorn.co.uk> - 2024-01-19 03:00 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-21 02:40 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-20 23:20 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-20 23:00 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-20 22:20 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-20 21:20 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing "tomas@tuxteam.de" <tomas@tuxteam.de> - 2024-01-21 07:50 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-20 20:00 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Dan Ritter <dsr@randomstring.org> - 2024-01-12 12:30 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Tixy <tixy@yxit.co.uk> - 2024-01-12 13:20 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-13 02:30 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing <tomas@tuxteam.de> - 2024-01-13 08:40 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Greg Wooledge <greg@wooledge.org> - 2024-01-13 16:10 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Richard Hector <richard@walnut.gen.nz> - 2024-01-13 16:50 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Charles Curley <charlescurley@charlescurley.com> - 2024-01-13 17:00 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing <tomas@tuxteam.de> - 2024-01-13 17:10 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing gene heskett <gheskett@shentel.net> - 2024-01-13 19:20 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Larry Martell <larry.martell@gmail.com> - 2024-01-14 20:00 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing debian-user@howorth.org.uk - 2024-01-13 17:20 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Charles Curley <charlescurley@charlescurley.com> - 2024-01-13 23:50 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Greg Wooledge <greg@wooledge.org> - 2024-01-14 01:50 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing debian-user@howorth.org.uk - 2024-01-14 14:40 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Stefan Monnier <monnier@iro.umontreal.ca> - 2024-01-14 06:30 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing <tomas@tuxteam.de> - 2024-01-14 08:20 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing "tomas@tuxteam.de" <tomas@tuxteam.de> - 2024-01-14 11:40 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-12 14:50 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2024-01-12 15:00 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-12 17:10 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Loïc Grenié <loic.grenie@gmail.com> - 2024-01-15 11:20 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing phoebus phoebus <frphoebus@yahoo.fr> - 2024-01-15 18:20 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Loïc Grenié <loic.grenie@gmail.com> - 2024-01-15 23:20 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Eduardo M KALINOWSKI <eduardo@kalinowski.com.br> - 2024-01-22 14:20 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Stefan Monnier <monnier@iro.umontreal.ca> - 2024-01-22 15:00 +0100
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing Eduardo M KALINOWSKI <eduardo@kalinowski.com.br> - 2024-01-22 15:30 +0100
Page 1 of 4 [1] 2 3 4 Next page →
| From | phoebus phoebus <frphoebus@yahoo.fr> |
|---|---|
| Date | 2024-01-12 01:40 +0100 |
| Subject | Seeking a Terminal Emulator on Debian for "Passthrough" Printing |
| Message-ID | <HVdKx-2sXl-7@gated-at.bofh.it> |
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
[toc] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2024-01-12 02:00 +0100 |
| Message-ID | <HVe3T-2t3L-1@gated-at.bofh.it> |
| In reply to | #265809 |
> 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
[toc] | [prev] | [next] | [standalone]
| From | phoebus phoebus <frphoebus@yahoo.fr> |
|---|---|
| Date | 2024-01-12 14:30 +0100 |
| Subject | Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing |
| Message-ID | <HVpLI-2Avo-7@gated-at.bofh.it> |
| In reply to | #265810 |
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
[toc] | [prev] | [next] | [standalone]
| From | Geert Stappers <stappers@stappers.nl> |
|---|---|
| Date | 2024-01-12 07:30 +0100 |
| Message-ID | <HVjdf-2woa-5@gated-at.bofh.it> |
| In reply to | #265809 |
[Multipart message — attachments visible in raw view] — view raw
On Fri, Jan 12, 2024 at 12:27:44AM +0000, 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
[toc] | [prev] | [next] | [standalone]
| From | phoebus phoebus <frphoebus@yahoo.fr> |
|---|---|
| Date | 2024-01-13 02:00 +0100 |
| Subject | Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing |
| Message-ID | <HVAxr-2GPS-1@gated-at.bofh.it> |
| In reply to | #265814 |
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
[toc] | [prev] | [next] | [standalone]
| From | John Hasler <john@sugarbit.com> |
|---|---|
| Date | 2024-01-13 03:50 +0100 |
| Message-ID | <HVCfT-2HSR-9@gated-at.bofh.it> |
| In reply to | #265858 |
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 john@sugarbit.com Elmwood, WI USA
[toc] | [prev] | [next] | [standalone]
| From | phoebus phoebus <frphoebus@yahoo.fr> |
|---|---|
| Date | 2024-01-13 09:50 +0100 |
| Subject | Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing |
| Message-ID | <HVHSh-2LxO-3@gated-at.bofh.it> |
| In reply to | #265864 |
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 putty@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 putty@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
[toc] | [prev] | [next] | [standalone]
| From | Trish Fraser <trish@thefrasers.org> |
|---|---|
| Date | 2024-01-13 10:40 +0100 |
| Subject | Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing |
| Message-ID | <HVIEF-2M92-1@gated-at.bofh.it> |
| In reply to | #265872 |
[Multipart message — attachments visible in raw view] — view raw
Thierry, > I have already tried to contact the PuTTY development team using the > email address putty@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
[toc] | [prev] | [next] | [standalone]
| From | phoebus phoebus <frphoebus@yahoo.fr> |
|---|---|
| Date | 2024-01-13 12:10 +0100 |
| Subject | Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing |
| Message-ID | <HVK3L-2Nch-1@gated-at.bofh.it> |
| In reply to | #265873 |
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
[toc] | [prev] | [next] | [standalone]
| From | debian-user@howorth.org.uk |
|---|---|
| Date | 2024-01-13 14:00 +0100 |
| Subject | Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing |
| Message-ID | <HVLMd-2O6L-5@gated-at.bofh.it> |
| In reply to | #265872 |
phoebus phoebus <frphoebus@yahoo.fr> 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 putty@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 putty@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
[toc] | [prev] | [next] | [standalone]
| From | phoebus phoebus <frphoebus@yahoo.fr> |
|---|---|
| Date | 2024-01-13 15:10 +0100 |
| Subject | Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing |
| Message-ID | <HVMRX-2OY2-1@gated-at.bofh.it> |
| In reply to | #265878 |
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
[toc] | [prev] | [next] | [standalone]
| From | hw <hw@adminart.net> |
|---|---|
| Date | 2024-01-15 20:10 +0100 |
| Message-ID | <HWAvn-3jzC-3@gated-at.bofh.it> |
| In reply to | #265858 |
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 +0000, 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 >
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2024-01-15 20:30 +0100 |
| Message-ID | <HWAOJ-3jGg-1@gated-at.bofh.it> |
| In reply to | #265996 |
> 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
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2024-01-15 21:10 +0100 |
| Message-ID | <HWBrs-3k9o-7@gated-at.bofh.it> |
| In reply to | #265996 |
[Multipart message — attachments visible in raw view] — view raw
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
[toc] | [prev] | [next] | [standalone]
| From | hw <hw@adminart.net> |
|---|---|
| Date | 2024-01-16 11:50 +0100 |
| Message-ID | <HWPb3-3spW-1@gated-at.bofh.it> |
| In reply to | #266004 |
On Mon, 2024-01-15 at 20:32 +0100, tomas@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 ...
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2024-01-18 06:10 +0100 |
| Message-ID | <HXsP7-3QMU-11@gated-at.bofh.it> |
| In reply to | #266053 |
On Tue 16 Jan 2024 at 11:47:53 (+0100), hw wrote: > On Mon, 2024-01-15 at 20:32 +0100, tomas@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.
[toc] | [prev] | [next] | [standalone]
| From | hw <hw@adminart.net> |
|---|---|
| Date | 2024-01-18 12:30 +0100 |
| Message-ID | <HXyKR-3UhS-3@gated-at.bofh.it> |
| In reply to | #266168 |
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, tomas@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?
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2024-01-18 13:20 +0100 |
| Message-ID | <HXzxf-3UOE-5@gated-at.bofh.it> |
| In reply to | #266185 |
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".
[toc] | [prev] | [next] | [standalone]
| From | hw <hw@adminart.net> |
|---|---|
| Date | 2024-01-18 15:30 +0100 |
| Message-ID | <HXBz3-3W1T-5@gated-at.bofh.it> |
| In reply to | #266189 |
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.
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2024-01-21 02:00 +0100 |
| Subject | Re: Seeking a Terminal Emulator on Debian for "Passthrough"Printing |
| Message-ID | <HYulP-4sWb-5@gated-at.bofh.it> |
| In reply to | #266197 |
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
[toc] | [prev] | [next] | [standalone]
Page 1 of 4 [1] 2 3 4 Next page →
Back to top | Article view | linux.debian.user
csiph-web