Using quarto inside WSL: not able to run simple bash command

[aborruso]

Hi,
I'm using quarto 0.9.307 and this simple qmd file

---
title: "demo"
format:
  html:
    code-fold: true
jupyter: python3
---

For a bash demonstration.

```{python}
!ls
```

These my capabilities

  "python": {
    "versionMajor": 3,
    "versionMinor": 9,
    "versionPatch": 2,
    "versionStr": "3.9.2 (default, Feb 28 2021, 17:03:44)  [GCC 10.2.1 20210110]",
    "conda": false,
    "execPrefix": "/usr",
    "executable": "/usr/bin/python3",
    "jupyter_core": "4.9.2",
    "nbformat": "5.3.0",
    "nbclient": "0.6.0",
    "ipykernel": "6.13.0",
    "pyLauncher": false,
    "kernels": [
      {
        "name": "bash",
        "language": "bash",
        "display_name": "Bash"
      },
      {
        "name": "python3",
        "language": "python",
        "display_name": "Python 3 (ipykernel)"
      },
      {
        "name": "zsh",
        "language": "zsh",
        "display_name": "Z shell"
      }
    ],
    "venv": true
  }

When I run I have the below errors. Is there a way to solve these?

Thank you

File ~/.local/lib/python3.9/site-packages/pexpect/pty_spawn.py:23, in _wrap_ptyprocess_err()
     22 try:
---> 23     yield
     24 except ptyprocess.PtyProcessError as e:

File ~/.local/lib/python3.9/site-packages/pexpect/pty_spawn.py:705, in spawn.isalive(self)
    704 with _wrap_ptyprocess_err():
--> 705     alive = ptyproc.isalive()
    707 if not alive:

File ~/.local/lib/python3.9/site-packages/ptyprocess/ptyprocess.py:715, in PtyProcess.isalive(self)
    714 if e.errno == errno.ECHILD:
--> 715     raise PtyProcessError('isalive() encountered condition ' +
    716             'where "terminated" is 0, but there was no child ' +
    717             'process. Did someone else call waitpid() ' +
    718             'on our process?')
    719 else:

PtyProcessError: isalive() encountered condition where "terminated" is 0, but there was no child process. Did someone else call waitpid() on our process?

During handling of the above exception, another exception occurred:

ExceptionPexpect                          Traceback (most recent call last)
Input In [2], in <cell line: 1>()
----> 1 get_ipython().system('ls')

File ~/.local/lib/python3.9/site-packages/ipykernel/zmqshell.py:633, in ZMQInteractiveShell.system_piped(self, cmd)
    631         self.user_ns["_exit_code"] = system(cmd)
    632 else:
--> 633     self.user_ns["_exit_code"] = system(self.var_expand(cmd, depth=1))

File ~/.local/lib/python3.9/site-packages/IPython/utils/_process_posix.py:153, in ProcessHandler.system(self, cmd)
    149 flush = sys.stdout.flush
    150 while True:
    151     # res is the index of the pattern that caused the match, so we
    152     # know whether we've finished (if we matched EOF) or not
--> 153     res_idx = child.expect_list(patterns, self.read_timeout)
    154     print(child.before[out_size:].decode(enc, 'replace'), end='')
    155     flush()

File ~/.local/lib/python3.9/site-packages/pexpect/spawnbase.py:372, in SpawnBase.expect_list(self, pattern_list, timeout, searchwindowsize, async_, **kw)
    370     return expect_async(exp, timeout)
    371 else:
--> 372     return exp.expect_loop(timeout)

File ~/.local/lib/python3.9/site-packages/pexpect/expect.py:169, in Expecter.expect_loop(self, timeout)
    167     return self.timeout()
    168 # Still have time left, so read more data
--> 169 incoming = spawn.read_nonblocking(spawn.maxread, timeout)
    170 if self.spawn.delayafterread is not None:
    171     time.sleep(self.spawn.delayafterread)

File ~/.local/lib/python3.9/site-packages/pexpect/pty_spawn.py:463, in spawn.read_nonblocking(self, size, timeout)
    460     incoming = super(spawn, self).read_nonblocking(size)
    461 except EOF:
    462     # Maybe the child is dead: update some attributes in that case
--> 463     self.isalive()
    464     raise
    465 while len(incoming) < size and select(0):

File ~/.local/lib/python3.9/site-packages/pexpect/pty_spawn.py:705, in spawn.isalive(self)
    703 ptyproc = self.ptyproc
    704 with _wrap_ptyprocess_err():
--> 705     alive = ptyproc.isalive()
    707 if not alive:
    708     self.status = ptyproc.status

File /usr/lib/python3.9/contextlib.py:135, in _GeneratorContextManager.__exit__(self, type, value, traceback)
    133     value = type()
    134 try:
--> 135     self.gen.throw(type, value, traceback)
    136 except StopIteration as exc:
    137     # Suppress StopIteration *unless* it's the same exception that
    138     # was passed to throw().  This prevents a StopIteration
    139     # raised inside the "with" statement from being suppressed.
    140     return exc is not value

File ~/.local/lib/python3.9/site-packages/pexpect/pty_spawn.py:25, in _wrap_ptyprocess_err()
     23     yield
     24 except ptyprocess.PtyProcessError as e:
---> 25     raise ExceptionPexpect(*e.args)

ExceptionPexpect: isalive() encountered condition where "terminated" is 0, but there was no child process. Did someone else call waitpid() on our process?
ExceptionPexpect: isalive() encountered condition where "terminated" is 0, but there was no child process. Did someone else call waitpid() on our process?

[cderv]

That does not help, but I confirm I get the same error on WSL, windows 10 too

ExceptionPexpect: isalive() encountered condition where "terminated" is 0, but there was no child process. Did someone else call waitpid() on our process?

[aborruso]

That does not help, but I confirm I get the same error on WSL, windows 10 too

Probably this problem is related to the one I have trying to use a native bash kernel in a computation cell.

[aborruso]

That does not help, but I confirm I get the same error on WSL, windows 10 too

Do you think that I should open an issue?

[aborruso]

If I run vscode from WSL bash terminal, via Visual Studio Code Remote - WSL extension, I have no error and it works.

I had to install ipykernel.

[jjallaire]

That document works fine for me. It seems that there is some interaction between bash and wsl that is causing problems (but I have no idea what it is nor any clue about how to debug it).

[cderv]

@aborruso maybe this is because WSL bash means windows WSL bash which is usually here C:\Windows\System32\bash.exe and this is a different bash that bash_kernel can handle probably. I see some related question in takluyver/bash_kernel#62 where it seems Windows is not really supported for bash kernel, and where there is solution for Windows user to use WSL bash when not in WSL.

It is working indeed in VSCODE so they may have found a way to tweak the configuration for this. I don't find any relevant clue for now, and also don't really know what could be the issue in Quarto. I'll try to have another look as I am on windows on how we are calling the jupyter kernel.

[aborruso]

@cderv I have no problem using WSL, jupyter and a bash kernel.
Below some images.

I have problem only using it starting from quarto.

Thank you

[cderv]

Ok I think I found something - It could be from our Daemon feature for Jupyter kernel: https://quarto.org/docs/computations/python.html#kernel-daemon

Try rendering a document setting daemon: false

---
title: "demo"
format:
  html:
    code-fold: true
jupyter: python3
execute:
  daemon: false
---

For a bash demonstration.

```{python}
!ls
```

it works for me.

So this could be something related to this daemon feature in Quarto. @jjallaire is this a clue that would help debugging ?
I'll look at this part of the codebase.

[cderv]

Could also be run this way with your original document

quarto render test.qmd --no-execute-daemon

[aborruso]

@cderv you are great, it works!!
I think it's very useful to add a note in the documentation.

Now I would like to find a solution also for bash kernel.

Thank you again

[jjallaire]

@cderv Can you think of a way we could proactively detect this condition and not create the daemon by default?

[cderv]

There would probably be a way to detect this is run in WSL terminal. However, I tested on Linux in RStudio Cloud (that the only other Linux environment I have access to), and it errors the same, not only at command line, but also in rendering using Button in Job pane.

This means we would need to detect when bash engine is used in the document and not usual python engine. I don't know yet how we can detect this, I need to have a look into we information we can access.

[jjallaire]

Some more related commentary: https://stackoverflow.com/questions/48539900/using-bash-commands-in-jupyter-notebook

It we had a regex that could determine that a cell uses a bash command then we could use that to disable the daemon.

Note that there are other scenarios that still might not work if the constraint is that the Jupyter kernel has to be launched from a bash shell (e.g. RStudio Jobs and VS Code Output are used for Quarto Preview and neither of those starts from a bash shell)

[jjallaire]

It does seem to work in the VS Code Output pane (at least on OS X).

These are the conditions that trigger the use of the deamon: https://github.com/quarto-dev/quarto-cli/blob/main/src/core/platform.ts#L60-L62

We also prevent the use of the daemon if we are running on CI: https://github.com/quarto-dev/quarto-cli/blob/main/src/execute/jupyter/jupyter.ts#L231

If the problem is WSL then we just need an environment variable to detect that and we can mask it out.

[aborruso]

Two tips:

https://stackoverflow.com/a/38859331/757714

https://www.scivision.dev/python-detect-wsl/

[cderv]

If the problem is WSL then we just need an environment variable to detect that and we can mask it out.

I am not sure the problem is WSL only. See #728 (comment)

[jjallaire]

Thanks! I don't have ready access to a WSL instance. Could you let me know what the contents of both of these files is when running under WSL:

/proc/sys/kernel/osrelease
/proc/version

Also, could you let me know what all of the environment variables are within the notebook when running by including this cell:

import os
os.environ

[aborruso]

Thank you @jjallaire

/proc/sys/kernel/osrelease

"4.19.104-microsoft-standard"

/proc/version

"Linux version 4.19.104-microsoft-standard (oe-user@oe-host) (gcc version 8.2.0 (GCC)) #1 SMP Wed Feb 19 06:37:35 UTC 2020"

import os
os.environ

environ{'HOSTTYPE': 'x86_64',
        'LANG': 'en_US.UTF-8',
        'PATH': '///',
        'TERM': 'xterm-color',
        'WSLENV': 'WT_SESSION::WT_PROFILE_ID',
        'WT_SESSION': '58fcab4d-1721-48c7-9f5c-cae85842ef90',
        'WT_PROFILE_ID': '{7f586916-8357-53d4-bb2b-ca96f639898a}',
        'WSL_INTEROP': '/run/WSL/5305_interop',
        'NAME': 'DESKTOP-7NVNDNF',
        'HOME': '/home/aborruso',
        'USER': 'aborruso',
        'LOGNAME': 'aborruso',
        'SHELL': '/usr/bin/zsh',
        'WSL_DISTRO_NAME': 'WLinux',
        'SHLVL': '1',
        'DISPLAY': '172.17.80.1:0',
        'WSL2': '1',
        'NO_AT_BRIDGE': '1',
        'WIN_HOME': '/mnt/c/Users/aborr',
        'HOMEBREW_PREFIX': '/home/linuxbrew/.linuxbrew',
        'HOMEBREW_CELLAR': '/home/linuxbrew/.linuxbrew/Cellar',
        'HOMEBREW_REPOSITORY': '/home/linuxbrew/.linuxbrew/Homebrew',
        'MANPATH': '/home/linuxbrew/.linuxbrew/share/man::',
        'INFOPATH': '/home/linuxbrew/.linuxbrew/share/info:',
        'DBUS_SESSION_BUS_ADDRESS': 'unix:abstract=/tmp/dbus-sfXmJskhv8,guid=941bb1df87e8ce91764d407d626861c9',
        'GOROOT': '/usr/local/go',
        'GOPATH': '/home/aborruso/go/',
        'N_PREFIX': '/home/aborruso/n',
        'RBENV_SHELL': 'zsh',
        'ZSH': '/home/aborruso/.oh-my-zsh',
        'PAGER': 'cat',
        'LESS': '-R',
        'LSCOLORS': 'Gxfxcxdxbxegedabagacad',
        'LD_LIBRARY_PATH': '/usr/local/lib:',
        'VISUAL': 'nano',
        'EDITOR': 'nano',
        'JENA_HOME': '/home/aborruso/bin/apache-jena-4.0.0',
        'GO111MODULE': 'on',
        'DENO_INSTALL': '/home/aborruso/.deno',
        'feedp_INSTALL': '/home/aborruso/bin/feedpushr',
        'GIT_PYTHON_REFRESH': 'quiet',
        'PYDEVD_USE_FRAME_EVAL': 'NO',
        'JPY_PARENT_PID': '5816',
        'CLICOLOR': '1',
        'GIT_PAGER': 'cat',
        'MPLBACKEND': 'module://matplotlib_inline.backend_inline'}

[cderv]

I check on some other linux environment like RStudio Cloud or RStudio workbench internally and this also errors the same when we execute with daemon. Passing --no-execute-daemon rendered correctly the document.

I don't think this is a WSL only problem. It could be related to bash_kernel or simply pexpect. I found similar log of error in their issue board: pexpect/pexpect#379

@aborruso does this really require bash_kernel ?

---
title: "demo"
format:
  html:
    code-fold: true
jupyter: python3
---

For a bash demonstration.

```{python}
!ls
```

I did not know about any of this before looking into this issue. I understand the the ! syntax is from IPython directly to execute shell command (https://jakevdp.github.io/PythonDataScienceHandbook/01.05-ipython-and-shell-commands.html). It seems to work on Jupyter without having bash_kernel installed.

However, you need to have it install if you want to use bash as a jupyter kernel, which you discussed in #604

So if we remove the bash_kernel layer, only the pexpect friction stay with the quarto daemon feature. There is probably a conflict between the two which lead to current incompatibility. Not sure yet if this could be improved.

About some solution to deactivate daemon by default,

Regarding regex, it seems like IPython shell command can be off the following

!echo "printing from the shell"

directory = !pwd

However, there are also shell-magic command (%cd %cat, %cp, %env, %ls, %man, %mkdir, %more, %mv, %pwd, %rm, and %rmdir) and % can be removed if automagic is on. Less easy for regex.

Regarding the use of bash_kernel, it is easier to detect as engine binding needs to be specified in that case, either in YAML or in first code chunk.

---
title: "demo"
format:
  html:
    code-fold: true
jupyter: bash
---

For a bash demonstration.

```{bash}
echo "hello world!"
```

[aborruso]

@cderv Using python3 kernel and ! or %%bash I have no problem, thank you to your great tip.

But if I use the example below

---
title: "demo"
format:
  html:
    code-fold: true
jupyter: bash
---

For a bash demonstration.

```{bash}
echo "hello world!"
```

and running quarto preview bash.qmd --no-execute-daemon

I have this error

Starting Jupyter kernel...Done

Executing 'bash.ipynb'
  Cell 1/1...

An error occurred while executing the following cell:
------------------
echo "hello world!"
------------------


: 1

It would be great for me to use natively bash kernel, but now, thank to you, I have an alternative python3 kernel way to do it in quarto.

[cderv]

The remaining issue is related directly to the other discussion #604

[aborruso]

The remaining issue is related directly to the other discussion #604

I do not know, if it's useful for debug. I have this error in RStudio

[cderv]

Your example above is somehow using knitr to execute the document. Not sure why.
This is working correctly for me.

---
title: "demo"
format:
  html:
    code-fold: true
jupyter: python3
execute: 
  daemon: false
---

For a bash demonstration.

```{python}
!ls
```

We'll push a fix soon for this issue regarding magic command. Please wait a bit then update everything once it is out.

[jjallaire]

Fix to make magic commands automatically not use the daemon is here: 537cf3c