bash_kernel
bash_kernel copied to clipboard
Exception ": 1" raised on every cell in Jupyter bash kernel
Hello,
First, I'd like to thank the developers and community for producing and supporting this software.
Issue: On every cell I run in the Jupyter bash kernel, an exception is raised. The exception carries the text ": 1". I'm unable to figure out what this means or how to prevent the exception from being raised.
The cell executes successfully despite the exception, as long as I click through one cell at a time. I'm unable to use the "Run all cells" function in JupyterLab, or use Papermill to run entire notebooks in an automated fashion, because it stops after the first exception.
Background: I think this may be related to Conda, If a cell is executed while inside a Conda environment, an exception is raised with ": 1 (my_environment_name)" and as I understand this is expected behavior for Conda.
Years ago on a previous machine, I was able to prevent this issue or a similar issue from occurring by 1) Installing JupyterLab through the Ubuntu repository with apt
, 2) Preventing Conda from automatically launching the base environment in new sessions, and 3) Launching JupyterLab from outside of Conda.
However, this same approach is not working on this new machine.
Ubuntu 22.04 bash_kernel 0.7.2 jupyter-lab 3.3.4
Call for help: This issue is preventing me from running Jupyter notebooks on a high-throughput scale using Papermill, which is important for my workflow. What is the cause of this exception? Is it expected behavior? How can it be avoided?
Thank you!
It's certainly not expected behaviour, but bash_kernel is a bit fragile about things like this, because it's really running bash in an invisible terminal, sending commands to it and collecting the output. We don't want to completely isolate it from the user's normal shell settings, because you may want things like aliases and shell functions to work.
Specifically, bash doesn't really have exceptions, so we fake them by asking 'did the last command fail?', i.e. this code:
https://github.com/takluyver/bash_kernel/blob/68c922de28fb09bbb8cbe46b9717525e7afb619a/bash_kernel/kernel.py#L158-L161
Normally, the last command should be the contents of the cell you just ran. But if there's a command being run for PS1 or PROMPT_COMMAND or something, then that might be the last command instead, so we're asking the question about the wrong thing. I probably don't know all the things that could interfere with this, but have a look at your environment variables inside a bash_kernel session and see if there are any likely culprits.
Thank you for your detailed response, takluyver.
After learning a bit about PROMPT_COMMAND and PS1, I don't think I need either, and removing them is fine if needed.
printenv
showed that I have:
PS1=[PEXP\[\]ECT_PROMPT>
I then attempted to disable PS1 by commenting out all PS1 lines in my .bashrc
. However, when I launch a new bash_kernel
instance and again printenv
, I still see it.
Can you suggest a further tweak or experiment to disable PS1 and nail down whether PS1 is the culprit? Thanks for your time and attention to this.
I'm sorry if this shouldn't be considered an issue with bash_kernel
and is instead an issue with my system. This isn't clear to me, but I will note bash_kernel
was one of the very first things I installed on this Ubuntu 22.04 LTS machine and I began having this issue right away, so I think it's likely to affect other systems.
Worth noting, this issue did not happen when Ubuntu 20.04 LTS was installed on the same machine.
That PS1 is fine - in fact, it's part of how bash_kernel works, so if you did manage to get rid of it, it would break - it needs to recognise the input prompt to tell where the output finishes.
Can you check PROMPT_COMMAND and PS1 after activating a conda environment, to see if conda sets those? If there's nothing suspicious there, you could also try envzigzag to see what other environment variables conda changes (it's a silly little tool I made - run envzig
, activate the environment, run envzag
).
It appears conda is not changing PS1 or PROMPT_COMMAND
gmobot@gmobot-Precision-5820-Tower:~$ echo $PS1
${debian_chroot:+($debian_chroot)}\u@\h:\w\$
gmobot@gmobot-Precision-5820-Tower:~$ echo $PROMPT_COMMAND
gmobot@gmobot-Precision-5820-Tower:~$ conda activate base
(base) gmobot@gmobot-Precision-5820-Tower:~$ echo $PS1
(base) ${debian_chroot:+($debian_chroot)}\u@\h:\w\$
(base) gmobot@gmobot-Precision-5820-Tower:~$ echo $PROMPT_COMMAND
Thanks for making envzigzag
available. As this shows, conda is changing the below envars.
gmobot@gmobot-Precision-5820-Tower:~$ envzig
gmobot@gmobot-Precision-5820-Tower:~$ conda activate base
(base) gmobot@gmobot-Precision-5820-Tower:~$ envzag
Added [in zag, not zig]:
CONDA_DEFAULT_ENV=base
CONDA_PREFIX=/home/gmobot/anaconda3
CONDA_PROMPT_MODIFIER=(base)
Changed:
CONDA_SHLVL=
├zig: 0
└zag: 1
PATH=
├zig: /home/gmobot/.local/bin:/home/gmobot/anaconda3/condabin:/home/gmobot/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
└zag: /home/gmobot/anaconda3/bin:/home/gmobot/.local/bin:/home/gmobot/anaconda3/condabin:/home/gmobot/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
However, I'm not sure what role conda may be playing in this issue with the exceptions appearing. I have had a similar issue happen on another machine when bash_kernel
is launched from within a conda env, and because of this on all machines I now run conda config --set auto_activate_base false
so it instead launches outside of conda. I checked my .condarc
to make sure this is successful. I also launch jupyter-lab
from outside of a conda env.
As an aside, the workflow I intend to run does involve entering and exiting conda
envs, but is supposed to begin outside of one. We don't enter any environments until long after the first notebook cell, and exceptions from the very start of the notebook on every cell.
Do these results provide any clues and do you have further suggestions? Thanks so much for your time. Please let me know anything else that would be helpful to diagnose this.
I just ran into this myself today, and I don't use conda at all. Here's how I create my env:
On Fedora 35:
python -m venv ~/foo
source ~/foo/bin/activate
pip install jupyterlab bash_kernel
python -m bash_kernel.install
jupyter lab --no-browser --ip=0.0.0.0 --notebook-dir=~/notebooks
And as soon as I start a bash kernel and start running it, I get the exact same behavior as the OP. I even tried env -i TERM=$TERM ~/foo/bin/jupyter lab --no-browser --ip=0.0.0.0 --notebook-dir=~/notebooks
to remove everything from my environment, and the problem still happens.
You can easily reproduce this in a docker:
docker run -it --rm -p 8888:8888 fedora:35
python -m venv /foo
source /foo/bin/activate
pip install jupyterlab bash_kernel
python -m bash_kernel.install
jupyter lab --allow-root --no-browser --ip=0.0.0.0 --notebook-dir=~
~Hmmmm... I just realized classic mode: jupyter notebook --allow-root --no-browser --ip=0.0.0.0 --notebook-dir=~
works without the : 1
problem. Is this a jupyter labs only problem?~ It also fails in jupyter notebook classic, only it doesn't print the : 1
, but it's still only allowing you to run one cell at a time.
Is this a duplicate of #120?
Very likely, sorry I didn't spot that. I've just released version 0.8 with that PR merged - @naglemi can you see if that fixes things?
I was also experiencing this issue on version 0.7.2 and no longer see this on version 0.8.0.
Thanks!