Running any cell (containing any shell command or function definition) always produces non-zero exit status (+workaround)

[ackalker]

When I run any cell with Bash code in it with Bash kernel, it always returns a non-zero exit status.
The issue seems to be related to both issues #116, #115 and #107 as the workaround mentioned in those issues works for this one as well, but I haven't seen any garbled output so far.

In order to not have to include bind 'set enable-bracketed-paste off' at the beginning of each and every notebook using the Bash kernel, I've added the following kludgy hack to my ~/.bashrc for now:

[[ $(< /proc/$PPID/comm) == python* ]] && bind 'set enable-bracketed-paste off'

This should apply the workaround to any interactive Bash shell running as a child process of a Python process (assuming that process to be the Bash kernel in most cases), and not to any other interactive shell.

@takluyver Is there a better way to detect if the shell process is running in the Bash kernel? Any advice is very welcome.

[takluyver]

It seems like the interface between terminal emulator and shell is gradually expanding. bash_kernel is kind of a weird half-way house: we want less interactivity than running in a terminal emulator, but more than running a bash script. Bash doesn't really have a mode for this.

There's no good way to detect bash_kernel at the moment. I mentioned on #111 that I'm happy if someone wants to add one, though:

I'd be open to bash_kernel setting something like JUPYTER_BASH_KERNEL=1 so that things run from bash can detect it.

I dislike this kind of 'detect what's running you' feature in general, but this is all kind of a bodge anyway.

[ackalker]

Well, my Emacs sets INSIDE_EMACS=27.2,comint in shells started with M-x shell, GNU screen even has its own terminal type, TERM=screen, tmux sets TERM_PROGRAM=tmux, and Visual Studio Code sets TERM_PROGRAM=vscode, so it is not uncommon for programs to have something identifiable that they are running a shell session (and I'm happily relying on all these identifiers for my own shell functions). If bash_kernel could do something similar (like setting a non exported variable of some kind), it would make things a lot easier indeed.

Setting TERM_PROGRAM seems to have become the de facto standard, see this Stack Exchange answer:

TERM_PROGRAM is used in /etc/zshrc and /etc/bashrc to run commands that are specific to the terminal program you are using when they open a shell. By default, macOS supplies /etc/zshrc_Apple_Terminal and /etc/bashrc_Apple_Terminal which do some extra work to manage the current working directory and support suspending and resuming the terminal. If you use another terminal program, you can place a file at /etc/zshrc_$TERM_PROGRAM or /etc/bashrc_$TERM_PROGRAM and it will be executed when your terminal program opens a shell. You have to ensure that your terminal program sets a value for $TERM_PROGRAM of course

[ackalker]

A little bit more on TERM_PROGRAM and TERM_PROGRAM_VERSION from the tmux CHANGES file:

• Export TERM_PROGRAM and TERM_PROGRAM_VERSION like various other terminals.

[takluyver]

0.8 should fix this (thanks to PR #120).

As a separate matter, I'm still open to setting some environment variable to indicate that it's bash_kernel outside the terminal. I'm a bit puzzled about TERM vs TERM_PROGRAM - my modern Linux system still doesn't seem to set TERM_PROGRAM automatically or use it, so I don't know if that's mostly an Apple thing or just randomly hasn't reached Fedora yet. 🤷