-
Notifications
You must be signed in to change notification settings - Fork 735
GUACAMOLE-???: Terminal's OSC parser to not stop on unhandled characters #613
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
That ticket - GUAC-734 - comes from the old Glyptodon Jira issue tracker, before the project was part Apache community, so you won't find the ticket in the current Jira tracker. The change looks simple enough to me; however, I wonder what the implications of it may be in other situations. Right now it just echoes the character(s) out to the terminal. I'm not sure transparently ignoring them is 100% the right way to go. I'm thinking that:
@mike-jumper, thoughts? |
|
That ticket - GUAC-734 - comes from the old Glyptodon Jira issue tracker
I wonder if we can find it; just in case there was a particular reason
this was introduced -- though I don't expect there is, probably it
was an insignificant change due to a misunderstanding.
I'm thinking that:
* At the very least, the unknown characters should still be logged at at the `DEBUG` level (or perhaps the `WARN` level, if we're changing it to not even print the characters?).
Yeah it makes a lot of sense to log OSC sequences, including unknown ones.
But probably not one log statement per character, since the sequence only makes sense as a whole (and it can be hundreds of characters long).
So I'd log it only after receiving the sequence terminator.
a new configuration parameter for the protocols that use the terminal that allows toggling whether or not the characters are ignored
I don't expect that it will be a good idea to a add this config option, because turning it on will randomly break applications,
and it's not even really useful for debugging, because the prefix of the sequence *is* consumed.
So if you run a program that sneakily prints some escape sequence that's not supported by the terminal; printing a suffix is
1. noisy (because in these cases, users don't actually care that the escape sequence is not supported because it was printed behind their back)
2. not even enough to identify the sequence, because the prefix is missing, so it could be OSC, DCS, APC etc.
I don't think any terminal has this type of option.
|
** I haven't made a ticket yet because I'm still waiting for my JIRA account to be created ** untested; maybe someone else can test this by running the printf command below? As reported in fish-shell/fish-shell#11749, Guacamole's terminal fails to parse some OSC sequences. For example, running this command (in a shell like Bash): printf '\033]133;A;special_key=1\007' echoes part of the sequence which is incorrect. Almost every other terminal ignores such sequences, even if they don't handle them. This allows apps to add new features without probing for support (which is not always possible or reliable). This behavior was introduced in c56412f (GUAC-734: Return to echo after HTS. Return to echo on unexpected characters within OSC., 2014-06-11) for unknown reasons -- I don't know how to find that ticket (it's not GUACAMOLE-734).
56ecee8 to
2ae3f1b
Compare
|
let me know if this patch works for you, |
|
@krobelus Any success getting your Jira account? |
|
yes, I have an account. Should I create a ticket? |
Yep, exactly! Thanks! |
** I haven't made a ticket yet because I'm still waiting for my JIRA
account to be created
** untested; maybe someone else can test this by running the printf
command below?
As reported in fish-shell/fish-shell#11749,
Guacamole's terminal fails to parse some OSC sequences.
For example, running this command (in a shell like Bash):
echoes part of the sequence which is incorrect.
Almost every other terminal ignores such sequences, even if they
don't handle them. This allows apps to add new features without
probing for support (which is not always possible or reliable).
This behavior was introduced in c56412f (GUAC-734: Return to echo
after HTS. Return to echo on unexpected characters within OSC.,
2014-06-11) for unknown reasons -- I don't know how to find that ticket
(it's not GUACAMOLE-734).