-
Notifications
You must be signed in to change notification settings - Fork 145
Fix error when TERM is unset or improperly set #137
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
Conversation
|
There's a longstanding bug in CPython which causes only the first call to setupterm() in a process to actually do anything. That's what the elaborate test refactor in blessed works around. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the patch! I'm mostly just concerned with the bare except, but if you can illuminate me on the other question, so much the better.
blessings/__init__.py
Outdated
| try: | ||
| setupterm(kind or environ.get('TERM', 'dumb'), | ||
| self._init_descriptor) | ||
| except: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we tighten this up to catch only the expected sorts of errors?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, I was worried that the exception thrown (_curses.error) was private, but I think I can catch it with curses.error which is documented.
| setupterm(kind or environ.get('TERM', 'unknown'), | ||
| self._init_descriptor) | ||
| try: | ||
| setupterm(kind or environ.get('TERM', 'dumb'), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does 'dumb' help, over how 'unknown' used to behave? I honestly can't figure out why I put 'unknown' in there in the first place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for me at least, unknown isn't a valid terminal in my term-info and causes a crash as well (which is caught in the except, but I'd rather avoid that if possible). While we can't guarantee that dumb will exist either, I think it has a much higher chance of working (as it's defined on pretty much everything).
|
Thank you! Mozilla's build system, for one, will be happy. :-) |
Link 1: https://bugzilla.mozilla.org/show_bug.cgi?id=1432867 Link 2: erikrose/blessings#137 Closes: https://bugs.gentoo.org/654316 Package-Manager: Portage-2.3.49, Repoman-2.3.10
|
This fix is not enough. When TERM is explicit set to "" (nothing, e.g. |
…ild-system-reviewers blessings.tigetstr is not part of its API. It happens to work because blessings imports curses using 'from curses import tigetstr'. Instead, we can just use terminal.normal, which contains the string we were going to get anyway. See erikrose/blessings#138 for more information. Let me know if there's a better way of resolving this. Hopefully with this + the patch I submitted to blessings (erikrose/blessings#137) firefox will build fine with TERM improperly set. Differential Revision: https://phabricator.services.mozilla.com/D5377 --HG-- extra : moz-landing-system : lando
…ild-system-reviewers blessings.tigetstr is not part of its API. It happens to work because blessings imports curses using 'from curses import tigetstr'. Instead, we can just use terminal.normal, which contains the string we were going to get anyway. See erikrose/blessings#138 for more information. Let me know if there's a better way of resolving this. Hopefully with this + the patch I submitted to blessings (erikrose/blessings#137) firefox will build fine with TERM improperly set. Differential Revision: https://phabricator.services.mozilla.com/D5377 UltraBlame original commit: f69ecb2abf86e239c528a27f394e88019bd7cdae
…ild-system-reviewers blessings.tigetstr is not part of its API. It happens to work because blessings imports curses using 'from curses import tigetstr'. Instead, we can just use terminal.normal, which contains the string we were going to get anyway. See erikrose/blessings#138 for more information. Let me know if there's a better way of resolving this. Hopefully with this + the patch I submitted to blessings (erikrose/blessings#137) firefox will build fine with TERM improperly set. Differential Revision: https://phabricator.services.mozilla.com/D5377 UltraBlame original commit: f69ecb2abf86e239c528a27f394e88019bd7cdae
…ild-system-reviewers blessings.tigetstr is not part of its API. It happens to work because blessings imports curses using 'from curses import tigetstr'. Instead, we can just use terminal.normal, which contains the string we were going to get anyway. See erikrose/blessings#138 for more information. Let me know if there's a better way of resolving this. Hopefully with this + the patch I submitted to blessings (erikrose/blessings#137) firefox will build fine with TERM improperly set. Differential Revision: https://phabricator.services.mozilla.com/D5377 UltraBlame original commit: f69ecb2abf86e239c528a27f394e88019bd7cdae
Closes #39.
This is an alternative, simpler solution than merging the blessed-integration branch, because that seems stalled.
If TERM is unset, we should default to a dumb term, as we cannot be sure colors are supported, which matches the behavior of less, for example.
If there is an error reading the TERM variable, we should fall back to not outputing any color, which mimics less again.
I tried to write some simple tests for this but the results seem to be cached, even across Terminal instances? Is this happening somehow, and is there a way to disable the cache?