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
