When readable-traceback is loaded from an rc file, any syntax error (e.g. typing { or echo {) causes an infinite loop that freezes the shell.
Cause
The __flush function in readable-traceback.xsh (line 40) contains:
rep = lambda s: '' if '__amalgam__.py' in s or 'readable-traceback.xsh' in s else s+'\n'
xonsh compiles '__amalgam__.py' in s or ... as a subprocess command rather than a Python expression. So every call to __flush tries to execute __amalgam__.py as a shell command.
When a syntax error occurs → _print_exception → backtrace.hook → __flush → subprocess __amalgam__.py → command not found → _print_exception → loop.
However, this doesn't happen if xontrib load readable-traceback is run in interactive mode, because then it doesn't replace ptk_shell.print_exception.
Reproduction
Without the xontrib:
@ {
xonsh: For full traceback set: $XONSH_SHOW_TRACEBACK = True
File "<stdin>", line 1
{
^
SyntaxError: EOF in multi-line statement
With it:
@ {
[infinite loop]
Traceback (most recent call last):
[nothing]
Tested on xonsh 0.22.8.
When
readable-tracebackis loaded from an rc file, any syntax error (e.g. typing{orecho {) causes an infinite loop that freezes the shell.Cause
The
__flushfunction inreadable-traceback.xsh(line 40) contains:xonsh compiles
'__amalgam__.py' in s or ...as a subprocess command rather than a Python expression. So every call to__flushtries to execute__amalgam__.pyas a shell command.When a syntax error occurs →
_print_exception→backtrace.hook→__flush→ subprocess__amalgam__.py→ command not found →_print_exception→ loop.However, this doesn't happen if
xontrib load readable-tracebackis run in interactive mode, because then it doesn't replaceptk_shell.print_exception.Reproduction
Without the xontrib:
@ { xonsh: For full traceback set: $XONSH_SHOW_TRACEBACK = True File "<stdin>", line 1 { ^ SyntaxError: EOF in multi-line statementWith it:
@ { [infinite loop] Traceback (most recent call last): [nothing]Tested on xonsh 0.22.8.