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
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
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
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
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
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
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:
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
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
> 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
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,
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
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
> 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
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
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.
[...]
>
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
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
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
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
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
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]
>
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
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
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
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
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
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
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
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
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
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
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
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:
> > > > >
>
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
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
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
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
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
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
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
> 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
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?
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
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
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
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
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
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
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
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
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
> 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
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
>
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
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,
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
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
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
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
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
>
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
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
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
> >
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
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
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
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
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,
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.
>>
>>
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
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.
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
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
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
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
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
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
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?
>
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
>
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
> 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
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
83 matches
Mail list logo
