Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #265809 > unrolled thread

Seeking a Terminal Emulator on Debian for "Passthrough" Printing

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.

Contents

  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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#266352 — Re: Seeking a Terminal Emulator on Debian for "Passthrough"Printing

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#266367 — Re: Seeking a Terminal Emulator on Debian for "Passthrough"Printing

On 1/21/24 01:46, tomas@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

[toc] | [prev] | [next] | [standalone]

#266397 — 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

[toc] | [prev] | [next] | [standalone]

#266357

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/ZZRrBqSut2fNubHa@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.

[toc] | [prev] | [next] | [standalone]

#266441

[Multipart message — attachments visible in raw view] — view raw

On Sun, Jan 21, 2024 at 10:44:35PM +0000, 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

[toc] | [prev] | [next] | [standalone]

#266450

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)?

[toc] | [prev] | [next] | [standalone]

#266454

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#266455

> 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

[toc] | [prev] | [next] | [standalone]

#266460

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#266486 — 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

[toc] | [prev] | [next] | [standalone]

#266563

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.

[toc] | [prev] | [next] | [standalone]

#266522

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.

[toc] | [prev] | [next] | [standalone]

#266525

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.

[toc] | [prev] | [next] | [standalone]

#266562

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.

[toc] | [prev] | [next] | [standalone]

#266566

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.

[toc] | [prev] | [next] | [standalone]

#266603

On Sun, Jan 21, 2024 at 10:44:35PM +0000, 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.

[toc] | [prev] | [next] | [standalone]

#266239

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, 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?

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.

[toc] | [prev] | [next] | [standalone]

#266346 — 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

[toc] | [prev] | [next] | [standalone]

#266339 — 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

[toc] | [prev] | [next] | [standalone]

#266338 — 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

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | linux.debian.user

csiph-web