Setting xtrace (set -x / set -o xtrace) results in exit code 1 for subsequent cells

[tchamberlin]

Setting the xtrace option (e.g. via set -x) results in an exit code of 1 for that cell, and subsequently-executed cells.

Here is the contents of the notebook:

echo foo  # exits with code 0
set -x  # exits with code 1
echo foo  # exits with code 1

And a screenshot of the same notebook:

As a sanity check, here's what this looks like in a "standard" bash shell (bash 5.2.9 in terminator 2.1.1):

$ echo foo; echo $?
foo
0
$ set -x; echo $?
+ echo 0
0
$ echo foo; echo $?
+ echo foo
foo
+ echo 0
0

No non-zero exit codes.

And for the sake of completeness, from $ help set:

-x Print commands and their arguments as they are executed.

Is there any known explanation for, or workaround to, this?

Environment details:

$ cat /etc/fedora-release 
Fedora release 37 (Thirty Seven)
$ python --version
Python 3.11.0
$ jupyter --version
Selected Jupyter core packages...
IPython          : 8.6.0
ipykernel        : 6.18.1
ipywidgets       : not installed
jupyter_client   : 7.4.7
jupyter_core     : 5.1.0
jupyter_server   : 1.23.3
jupyterlab       : 3.5.0
nbclient         : 0.7.0
nbconvert        : 7.2.5
nbformat         : 5.7.0
notebook         : 6.5.2
qtconsole        : not installed
traitlets        : 5.5.0
$ pip show bash_kernel | grep Version
Version: 0.8.0

Thanks

[kdm9]

Hmm, this seems related to the issues fixed in #120. I don't have time today to dig in, but thanks for the bug report and I'll take a look ASAP (next week)

[abbbe]

@kdm9 , I wonder if you had a chance to look into this issue, I find 'set -x' very useful for troubleshooting, pity it cannot be seamlessly used in the notebooks. It appears bash_kernel 0.9.1 still behaves the same.

[kdm9]

I did, and unfortunately I couldn't work out a way around this, at least not a general one. The problem is that bash_kernel sets a very specific PS1 (prompt format), and anything that fiddles with that including set -x or conda or whatever needs to be worked around. Detecting conda is pretty easy, but simply adding a plus to every line of input is not a high-signal enough pattern to reliably detect only the set -x lines.

one thing we could in theory do is to optionally echo back the command that is passed to bash, which would have a similar effect. This would, a), be fairly pointless as it would just be the cell content and not the as-executed bash interpolation thereof, and b), would need to be configured kernel-wide unlike set -x

I'm more than happy to hear any other solution though. Do you know if the + that is used by set -x is configurable? if so, we can set it to something silly like BASH_KERNEL_SETX_PROMPT or something, and then regex those back into plusses, on the assumption that no other tool or real data output would start its line with that prompt.

[kdm9]

OK, after some further R-ing of TFM, I've remembered that we could do exactly what I suggest above by setting PS4='BASH_KERNEL_PS4_SETX__' or something, and then replacing that with + somewhere here-ish.

I'm on a bunch of grant application deadlines at the minute, but PRs are more than welcome, otherwise pester me again in December and hopefully I'll have an hour to implement and test this.

[abbbe]

Sure, I could put some work into this, but to say the truth I have not yet managed to wrap my head around the problem... I understand things could get screwed if something (conda) changes PS1, but it is not what 'set -x' does. To my knowledge it merely adds extra stderr traffic...

bash-3.2$ set | grep PS
GROUPS=()
PS1='\s-\v\$ '
PS2='> '
PS4='+ '
bash-3.2$
bash-3.2$
bash-3.2$ set -x
bash-3.2$
bash-3.2$ set | grep PS
+ set
+ grep PS
GROUPS=()
PS1='\s-\v\$ '
PS2='> '
PS4='+ '

What do I miss?

[takluyver]

I think I can see what's going on. bash_kernel uses echo $? after executing a cell to check if the code in the cell errored or not. It expects the first line of output from echo $? to be parseable as an int, and if that's not the case, it uses exit code 1.

bash_kernel/bash_kernel/kernel.py

Lines 226 to 229 in 2db865d

	try:
	exitcode = int(self.bashwrapper.run_command('echo $?').rstrip().split("\r\n")[0])
	except Exception as exc:
	exitcode = 1

With xtrace turned on, the first line of output it gets is + echo 0. It would be easy enough to recognise that, but the ability for someone to set PS4 to an arbitrary string makes it a bit messier, so it might make sense for bash_kernel to set it to something known, as @kdm9 suggests. But AIUI we only need to account for this in the echo $? output - in the 'real' output it can just be displayed as is - so maybe unsetting PS4 and relying on the default + marker is OK, rather than setting it to a special value.

[abbbe]

Mystery solved).

Couple more options come to mind:

• only interpret the last line from the output of "echo $?"
• do "echo BASH_KERNEL_EXITCODE=$?"

[takluyver]

The choice of the first line was part of @kdm9's hardening against conda prompt stuff in #125. I'm not completely sure why it's needed, but I assume switching to the last line could cause problems in that scenario. I think having a distinctive marker with the exit code is probably a reasonable alternative, though.

Other than the change to use only the first line, that bit of code is basically unchanged since bash_kernel was started in 2014. 🙂

[abbbe]

bash-3.2$ set -x
bash-3.2$ sh -c "exit 123"
+ sh -c 'exit 123'
bash-3.2$ { echo $?; } 2>/dev/null
123

PS. Credit goes to GPT-4 ;)

[abbbe]

Seems to solve the problem for me :)