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
