#12263 closed defect (fixed)
Unset TERM when running sage non-interactively
| Reported by: | jdemeyer | Owned by: | leif |
|---|---|---|---|
| Priority: | major | Milestone: | sage-4.8 |
| Component: | scripts | Keywords: | |
| Cc: | Merged in: | sage-4.8.rc0 | |
| Authors: | Jeroen Demeyer | Reviewers: | Volker Braun |
| Report Upstream: | Workaround found; Bug reported upstream. | Work issues: | |
| Branch: | Commit: | ||
| Dependencies: | Stopgaps: |
Status badges
Description (last modified by )
Because of either a readline or a Python bug, sometimes control characters are output by Python. For example, on my Gentoo Linux system:
jdemeyer@arcanis:~$ sage --python -c 'import readline' |cat -t ^[[?1034hjdemeyer@arcanis:~$
This breaks doctests at #12249 for sage-run. The easiest solution is to unset the TERM environment variable when running sage-run or sage-eval. This will effectively disable readline.
Upstream (readline): http://lists.gnu.org/archive/html/bug-readline/2007-08/msg00004.html
Apply 12263_unset_TERM.patch to the scripts repository.
Attachments (1)
Change History (10)
comment:1 Changed 9 years ago by
- Description modified (diff)
- Report Upstream changed from N/A to Workaround found; Bug reported upstream.
Changed 9 years ago by
comment:2 Changed 9 years ago by
- Description modified (diff)
- Status changed from new to needs_review
comment:3 Changed 9 years ago by
- Status changed from needs_review to positive_review
comment:4 Changed 9 years ago by
- Merged in set to sage-4.8.rc0
- Resolution set to fixed
- Reviewers set to Volker Braun
- Status changed from positive_review to closed
comment:5 follow-up: ↓ 6 Changed 9 years ago by
"My Gentoo Linux system" isn't very precise.
Note that (also Sage's) readline uses some termcap library, i.e. some "arbitrary" equivalent installed / found on a user's system, which apparently leads to improper output of control sequences (intended to be handled by the terminal) in some (mis-)configurations; cf. also this Python bug report.
Unsetting TERM unfortunately doesn't "effectively disable readline", but may trigger other bugs, like the one reported here. Using TERM=unknown (or none) or something like that instead would perhaps avoid both.
comment:6 in reply to: ↑ 5 ; follow-up: ↓ 7 Changed 9 years ago by
Replying to leif:
Unsetting
TERMunfortunately doesn't "effectively disable readline", but may trigger other bugs, like the one reported here. UsingTERM=unknown(ornone) or something like that instead would perhaps avoid both.
I don't think that is a good solution, because we need Sage to work with TERM unset. Imagine for example somebody wants to run sage from a cron script, then TERM would not be set. Also, TERM is not set when you run something like
ssh mysagebox "sage script.sage"
comment:7 in reply to: ↑ 6 Changed 9 years ago by
comment:8 follow-up: ↓ 9 Changed 9 years ago by
Out of curiosity, do you really get an unset TERM in cron jobs and non-interactive ssh sessions? On all of the systems I've tried, it's always 'dumb'.
For context, this is readline outputting the "meta mode on"/"smm" sequence to enable 8 bit mode. This is signalled by the "km" termcap flag, viewable using 'infocmp', where you can also directly see the "smm" sequence.
comment:9 in reply to: ↑ 8 Changed 9 years ago by
Replying to wjp:
Out of curiosity, do you really get an unset TERM in cron jobs and non-interactive ssh sessions? On all of the systems I've tried, it's always 'dumb'.
Are you sure there is an environment variable "TERM" in the cases you mention? It seems to me that bash sets a non-exported variable TERM=dumb if there is no environment variable TERM. You can see this with "declare -p TERM". In a normal shell, I get for example
$ declare -p TERM declare -x TERM="xterm"
(the -x means exported)
With a non-interactive ssh session:
$ ssh sage.math.washington.edu "declare -p TERM" declare -- TERM="dumb"
(no -x, so not exported, i.e. not an environment variable)
Looks good!