xonsh always returns zero when used as the shell in vim/neovim

[meatballs]

Expected Behavior

If I run a command within vim/neovim and that command fails, I should see a non-zero return code in v:shell_error.

Current Behavior

If the shell for vim/neovim to use is xonsh, v:shell_error always contains zero.

Steps to Reproduce

open vim/neovim

:set shell=bash
:!rm non-existent-file
/usr/bin/rm cannot remove 'non-existent-file': No such file or directory

shell returned 1

Press ENTER or type command to continue
:echo(v:shell_error)
1

:set shell=xonsh
:!rm non-existent-file
/usr/bin/rm cannot remove 'non-existent-file': No such file or directory

Press ENTER or type command to continue
:echo(v:shell_error)
0

xonfig

+------------------+-----------------+
| xonsh | 0.9.8 |
| Python | 3.7.5 |
| PLY | 3.11 |
| have readline | True |
| prompt toolkit | 2.0.10 |
| shell type | prompt_toolkit2 |
| pygments | 2.3.1 |
| on posix | True |
| on linux | True |
| distro | ubuntu |
| on darwin | False |
| on windows | False |
| on cygwin | False |
| on msys2 | False |
| is superuser | False |
| default encoding | utf-8 |
| xonsh encoding | utf-8 |
| encoding errors | surrogateescape |
+------------------+-----------------+

Further Info

This works fine outside vim/neovim within a terminal running xonsh:

!(rm non-existent-file)
/usr/bin/rm: cannot remove 'non-existent-file': No such file or directory
CommandPipeline(stdin=<_io.BytesIO object at 0x7f056e858d10>, stdout=<_io.BytesIO object at 0x7f056e858d70>, stderr=<_io.BytesIO object at 0x7f056e858dd0>, pid=32062, returncode=1, args=['rm', 'non-existent-file'], alias=None, stdin_redirect=['<stdin>', 'r'], stdout_redirect=[9, 'wb'], stderr_redirect=[11, 'w'], timestamps=[1576055751.5550349, 1576055751.5620785], executed_cmd=['/usr/bin/rm', 'non-existent-file'], input=, output=, errors=/usr/bin/rm: cannot remove 'non-existent-file': No such file or directory)

It even works fine within a vim/neovim terminal when xonsh is the shell:
open vim/neovim

:set shell=xonsh
:terminal
!(rm non-existent-file)
/usr/bin/rm: cannot remove 'non-existent-file': No such file or directory
CommandPipeline(stdin=<_io.BytesIO object at 0x7fb79b2af410>, stdout=<_io.BytesIO object at 0x7fb79b2af470>, stderr=<_io.BytesIO object at 0x7fb79b2af4d0>, pid=31794, returncode=1, args=['rm', 'non-existent-file'], alias=None, stdin_redirect=['<stdin>', 'r'], stdout_redirect=[7, 'wb'], stderr_redirect=[9, 'w'], timestamps=[1576055686.1392198, 1576055686.1452942], executed_cmd=['/usr/bin/rm', 'non-existent-file'], input=, output=, errors=/usr/bin/rm: cannot remove 'non-existent-file': No such file or directory)

Possibly related to #3309

Update

Confirmed as showing identical behaviour on OSX (description above is from Ubuntu).

[gforsyth]

Huh -- thanks for reporting @meatballs -- I agree that this is probably related to #3309. I'll try to take a look soon.

[meatballs]

If you're able to give me a clue as to where I might start, I'm happy to look into this too.

[N-Coder]

Any program executing code in the users shell and reacting depending on the return code will always get return code 0 (in my case a Match Exec entry in .ssh/config always matching, no matter the actual return code of the executed code).

This is also easy to reproduce with xonsh/0.9.11:

$ xonsh -c "echo 'hello' | grep 'world'"; _.rtn                                                                                                                                                                              
0
$ bash -c "echo 'hello' | grep 'world'"; _.rtn                                                                                                                                                                               
1
$ bash -c "exit 0"; _.rtn
0
$ bash -c "exit 1"; _.rtn
1
$ bash -c "exit 123"; _.rtn
123
$ xonsh -c "exit 0"; _.rtn

0
$ xonsh -c "exit 1"; _.rtn

0
$ xonsh -c "exit 123"; _.rtn

0

If you want to forward the return code, you need to use the quite verbose import sys; sys.exit(![command]). Maybe using the same semantics as bash (http://tldp.org/LDP/abs/html/exit-status.html) could be helpful?

[meatballs]

#3309 was fixed by #3465 but that hasn't fixed this problem.

[meatballs]

Fantastic! Thanks all.