## For community
⬇️ **Please click the 👍 reaction instead of leaving a `+1` or 👍
comment**
---------
Co-authored-by: Andy Kipp <anki-code@users.noreply.github.com>
<!---
Thanks for opening a PR on xonsh!
Please do this:
1. Include a news file with your PR
(https://xon.sh/devguide.html#changelog).
2. Add the documentation for your feature into `/docs`.
3. Add the example of usage or before-after behavior.
4. Mention the issue that this PR is addressing e.g. `#1234`.
-->
## For community
⬇️ **Please click the 👍 reaction instead of leaving a `+1` or 👍
comment**
---------
Co-authored-by: a <1@1.1>
This is continuation for introduced before
`$XONSH_SUBPROC_OUTPUT_FORMAT` (#5377) so news file is not needed.
### Motivation
Having `output_format` in spec and in pipeline allows to switch output
format in `SpecModifierAlias` and during non-blocking work e.g.
```xsh
p=!(echo '1\n2\n3')
p.output_format = 'list_lines'
p.out
# ['1','2','3']
```
```xsh
from xonsh.procs.specs import SpecModifierAlias
class SpecModifierOutputLinesAlias(SpecModifierAlias):
def on_modifer_added(self, spec):
spec.output_format = 'list_lines'
aliases['xlines'] = SpecModifierOutputLinesAlias()
$(xlines echo '1\n2\n3')
# ['1','2','3']
```
## For community
⬇️ **Please click the 👍 reaction instead of leaving a `+1` or 👍
comment**
---------
Co-authored-by: a <1@1.1>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
### Motivation
This is fix for introduced before
`$XONSH_SUBPROC_OUTPUT_FORMAT='list_lines'` so news file is not needed.
We should return the list for single line output to avoid unintended
reading the string.
### Before
```xsh
$XONSH_SUBPROC_OUTPUT_FORMAT='list_lines'
mkdir -p /tmp/list_lines
cd /tmp/list_lines
touch 123
du $(ls)
# 0 123
for f in $(ls):
print(f)
# 1
# 2
# 3
touch 321
for f in $(ls):
print(f)
# 123
# 321
```
### After
```xsh
$XONSH_SUBPROC_OUTPUT_FORMAT='list_lines'
mkdir -p /tmp/list_lines
cd /tmp/list_lines
touch 123
du $(ls)
# 0 123
for f in $(ls):
print(f)
# 123
touch 321
for f in $(ls):
print(f)
# 123
# 321
```
## For community
⬇️ **Please click the 👍 reaction instead of leaving a `+1` or 👍
comment**
Co-authored-by: a <1@1.1>
I'm going to revert #5423 because it was regress -
https://github.com/xonsh/xonsh/issues/5466 - and we need to fix parser
instead of resolver.
## For community
⬇️ **Please click the 👍 reaction instead of leaving a `+1` or 👍
comment**
---------
Co-authored-by: a <1@1.1>
It's needed to put spec modifier to the end of resolving.
## For community
⬇️ **Please click the 👍 reaction instead of leaving a `+1` or 👍
comment**
Co-authored-by: a <1@1.1>
Show std if `$XONSH_TRACE_SUBPROC=3`.
### Motivation
* It's very helpful if you want to understand how subproc is working.
* It's helpful to trace `SpecModifierAlias`.
* It's helpful to trace cases like #2618
## For community
⬇️ **Please click the 👍 reaction instead of leaving a `+1` or 👍
comment**
---------
Co-authored-by: a <1@1.1>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
previously, this succeeded in CI, but always failed locally with the
following error:
```xsh
_____________________________________________________________________ test_raise_subproc_error_with_show_traceback[True] _____________________________________________________________________
monkeypatch = <_pytest.monkeypatch.MonkeyPatch object at 0x76f6ba8882e0>, interactive = True
@skip_if_on_windows
@pytest.mark.parametrize("interactive", [True, False])
def test_raise_subproc_error_with_show_traceback(monkeypatch, interactive):
out, err, ret = run_xonsh(
"$COLOR_RESULTS=False\n$RAISE_SUBPROC_ERROR=False\n$XONSH_SHOW_TRACEBACK=False\nls nofile",
interactive=interactive,
single_command=True,
)
assert ret != 0
> assert re.match("ls.*No such file or directory\n", out)
E assert None
E + where None = <function match at 0x76f6bcd0cd30>('ls.*No such file or directory\n', "\x1b]0;ls | jyn@pop-os: ~/src/xonsh | xonsh\x07ls: cannot access 'nofile': No such file or directory\n")
E + where <function match at 0x76f6bcd0cd30> = re.match
tests/test_integrations.py:1190: AssertionError
```
the problem was that the following string was prepended before the error
message:
```
\x1b]0;ls | jyn@pop-os: ~/src/xonsh | xonsh\x07l
```
that in turn came from
[`BaseShell.settitle`](66c0490d37/xonsh/base_shell.py (L570)),
which always prepends at least the escape codes even when TITLE is set
to an empty string.
avoid this issue by mimicking a dumb terminal in tests, in which case
`settitle` doesn't add any title at all.
see
https://xonsh.zulipchat.com/#narrow/stream/435069-xonsh-dev/topic/Running.20tests.20locally
for more context.
<!---
Thanks for opening a PR on xonsh!
Please do this:
1. Include a news file with your PR
(https://xon.sh/devguide.html#changelog).
2. Add the documentation for your feature into `/docs`.
3. Add the example of usage or before-after behavior.
4. Mention the issue that this PR is addressing e.g. `#1234`.
-->
## For community
⬇️ **Please click the 👍 reaction instead of leaving a `+1` or 👍
comment**
with pip 22, i was getting extremely strange errors like this one:
```
$ pip install '.[dev]'
Processing /home/jyn/src/xonsh
Installing build dependencies ... done
Getting requirements to build wheel ... done
Preparing metadata (pyproject.toml) ... done
WARNING: unknown 0.0.0 does not provide the extra 'dev'
Building wheels for collected packages: UNKNOWN
Building wheel for UNKNOWN (pyproject.toml) ... done
Successfully installed UNKNOWN-0.0.0
$ pytest
tests/test_lib/test_subprocess.xsh:10: in <module>
from xonsh.pytest.tools import ON_WINDOWS
E ModuleNotFoundError: No module named 'xonsh.pytest'
```
see
https://xonsh.zulipchat.com/#narrow/stream/435069-xonsh-dev/topic/install.20xonsh.20for.20development.20without.20sudo.20rights
for more context.
<!---
Thanks for opening a PR on xonsh!
Please do this:
1. Include a news file with your PR
(https://xon.sh/devguide.html#changelog).
2. Add the documentation for your feature into `/docs`.
3. Add the example of usage or before-after behavior.
4. Mention the issue that this PR is addressing e.g. `#1234`.
-->
## For community
⬇️ **Please click the 👍 reaction instead of leaving a `+1` or 👍
comment**
### Motivation
When interact with default prompt I noticed that`env_name` has no color
and when you type command or see the output it mix with `env_name`
visually. Prompt is not highlighted when `env_name` has default color.
### Before
Output and env_name are visually mixed:
<img width="900" alt="image"
src="https://github.com/xonsh/xonsh/assets/1708680/c843388e-6e72-4fba-ab0f-6cd3fb023cd2">
### After
Output and env_name are visually distinct:
<img width="918" alt="image"
src="https://github.com/xonsh/xonsh/assets/1708680/09f45cd8-63d1-479a-bfab-c8063cf03aeb">
## For community
⬇️ **Please click the 👍 reaction instead of leaving a `+1` or 👍
comment**
---------
Co-authored-by: a <1@1.1>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
### Motivation
* We have no recommended way to force subprocess command be
(un)threadable
* #4214
* #2119
* #5003
* It's interesting opportunity to have a way to modify specs and CP
using `SpecModifierAlias`.
### Before
```xsh
!(ssh host -T "echo 1")
# output='' # EXPECTED: 1
__xonsh__.commands_cache.threadable_predictors['ssh'] = lambda *a, **kw: True
!(ssh host -T "echo 1")
```
### After
```xsh
xthread
# Mark command as threadable.
!(xthread ssh host -T "echo 1")
# output='1'
```
Closes:
* Closes#4214
* Closes#2119
* Partially closes#5003
Implementation of `SpecModifierAlias` will help in:
* #2618
JFYI #5413
## For community
⬇️ **Please click the 👍 reaction instead of leaving a `+1` or 👍
comment**
---------
Co-authored-by: a <1@1.1>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Co-authored-by: Gil Forsyth <gforsyth@users.noreply.github.com>
Closes#3394
### Motivation
After reading [the history of threading and
operators](https://github.com/xonsh/xonsh/issues/5444) I realized that
this was intended, to make the `!()` operator non-blocking. So let's
write about this in tutorial.
### Next steps
In the future we need to solve these points:
* Confusion around `.output` and `.out`.
* Show good cases where non-blocking is doing perfect work to people. Or
remove the non-blocking functionality [to remove
threading](https://github.com/xonsh/xonsh/discussions/4710).
## For community
⬇️ **Please click the 👍 reaction instead of leaving a `+1` or 👍
comment**
---------
Co-authored-by: a <1@1.1>
Co-authored-by: Gil Forsyth <gforsyth@users.noreply.github.com>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
<!---
Thanks for opening a PR on xonsh!
Please do this:
1. Include a news file with your PR
(https://xon.sh/devguide.html#changelog).
2. Add the documentation for your feature into `/docs`.
3. Add the example of usage or before-after behavior.
4. Mention the issue that this PR is addressing e.g. `#1234`.
-->
## For community
⬇️ **Please click the 👍 reaction instead of leaving a `+1` or 👍
comment**
Co-authored-by: a <1@1.1>
### Motivation
If `dircolors` utility is wrong by any reason you can't start xonsh
shell. This should not be stopper.
### Before
```xsh
cd /tmp
echo '#!/bin/qwe' > dircolors && chmod +x dircolors
echo '$PATH.append("/tmp")' > rc
xonsh --no-env --rc /tmp/rc
# OSError: [Errno 8] Exec format error: 'dircolors'
# Xonsh encountered an issue during launch
```
### After
It's working.
## For community
⬇️ **Please click the 👍 reaction instead of leaving a `+1` or 👍
comment**
---------
Co-authored-by: a <1@1.1>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
### Motivation
This PR just clean the code in `procs/specs.py` without changes the
logic: group the code into functions. This is needed to the next feature
PR #5443.
## For community
⬇️ **Please click the 👍 reaction instead of leaving a `+1` or 👍
comment**
---------
Co-authored-by: a <1@1.1>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
### Motivation
Closes#5003
### The case
Core utils in Nix are symlinks to one binary file that contains all
utils:
```xsh
docker run --rm -it nixos/nix bash
which echo
# /nix/store/k6h0vjh342kqlkq69sxjj8i5y50l6jfr-coreutils-9.3/bin/echo
ls -la /nix/store/k6h0vjh342kqlkq69sxjj8i5y50l6jfr-coreutils-9.3/bin/
# b2sum -> coreutils
# base32 -> coreutils
# ...
# All tools are symlinks to one binary file - `coreutils`.
```
When
[`default_predictor_readbin`](61bda708c9/xonsh/commands_cache.py (L392))
read `coreutils` it catches `(b'isatty', b'tcgetattr', b'tcsetattr')`
and return `threadable=False` forever.
The list of Nix coreutils tools are exactly the same as in [brew
coreutils](https://formulae.brew.sh/formula/coreutils). So I can check
the real predicts on distinct binaries and see that only 2 tools among
106 are unthreadable and they already covered by
`default_threadable_predictors` (If it's wrong please add unthreadable
tools to the
[default_threadable_predictors](61bda708c9/xonsh/commands_cache.py (L518))):
```xsh
brew install coreutils
ls /opt/homebrew/opt/coreutils/libexec/gnubin/ | wc -l
# 106
for t in p`/opt/homebrew/opt/coreutils/libexec/gnubin/.*`:
if not (th := __xonsh__.commands_cache.predict_threadable([t.name])):
print($(which @(t.name)), th)
# /opt/homebrew/opt/coreutils/libexec/gnubin/cat False
# /opt/homebrew/opt/coreutils/libexec/gnubin/yes False
defaults = __import__('xonsh').commands_cache.default_threadable_predictors().keys()
defaults['cat']
# <function xonsh.commands_cache.predict_false>
defaults['yes']
# <function xonsh.commands_cache.predict_false>
```
So the rest of we need is to check the symlink and apply default
prediction if the tools is the symlink to coreutils. This implements
this PR. Test included.
## For community
⬇️ **Please click the 👍 reaction instead of leaving a `+1` or 👍
comment**
---------
Co-authored-by: a <1@1.1>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Merge this after https://github.com/xonsh/xonsh/pull/5437
## For community
⬇️ **Please click the 👍 reaction instead of leaving a `+1` or 👍
comment**
---------
Co-authored-by: a <1@1.1>
Reading stop signals from the process and update the process state.
### The issue
Technically. In a couple of places that critical for processing signals
we have `os.waitpid()`. The function behavior is pretty unobvious and
one of things is processing return code after catching the signal. We
had no good signal processing around this and this PR fixes this. See
also `proc_untraced_waitpid` function description.
From user perspective. For example we have process that is waiting for
user input from terminal e.g. `python -c "input()"` or `fzf`. If this
process will be in captured pipeline e.g. `!(echo 1 | fzf | head)` it
will be suspended by OS and the pipeline will be in the endless loop
with future crashing and corrupting std at the end. This PR fixes this.
### The solution
Technically. The key function is `proc_untraced_waitpid` - it catches
the stop signals and updates the process state.
From user perspective. First of all we expect that users will use
captured object `!()` only for capturable processes. Because of it our
goal here is to just make the behavior in this case stable.
In this PR we detect that process in the pipeline is suspended and we
need to finish the command pipeline carefully:
* Show the message about suspended process.
* Keep suspended process in `jobs`. The same behavior we can see in
bash. This is good because we don't know what process suspended and why.
May be experienced user will want to continue it manually.
* Finish the CommandPipeline with returncode=None and suspended=True.
### Before
```xsh
!(fzf) # or !(python -c "input()")
# Hanging / Exceptions / OSError / No way to end the command.
# After exception:
$(echo 1)
# OSError / IO error
```
### After
```xsh
!(fzf) # or `!(ls | fzf | head)` or `!(python -c "input()")`
# Process ['fzf'] with pid 60000 suspended with signal 22 SIGTTOU and stay in `jobs`.
# This happends when process start waiting for input but there is no terminal attached in captured mode.
# CommandPipeline(returncode=None, suspended=True, ...)
$(echo 1)
# Success.
```
Closes#4752#4577
### Notes
* There is pretty edge case situation when the process was terminated so
fast that we can't catch pid alive and check signal
([src](67d672783d/xonsh/jobs.py (L71-L80))).
I leave it as is for now.
### Mentions
#2159
## For community
⬇️ **Please click the 👍 reaction instead of leaving a `+1` or 👍
comment**
---------
Co-authored-by: a <1@1.1>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Co-authored-by: Gil Forsyth <gforsyth@users.noreply.github.com>
### Motivation
Development tools like PyCharm send SIGINT before SIGKILL in case of
reload app. Saving history on SIGINT is the last chance to save history
in this case.
I understand that history will be flushed on Ctrl+C (SIGINT) but it
looks like no bad consequences of this. In addition history saving will
be more stable.
### Before
```xsh
# Development in PyCharm
xonsh --no-rc
echo cmd
# Ctrl+RR of Ctrl+DD to restart.
# Command history lost.
```
### After
```xsh
# Development in PyCharm
xonsh --no-rc
echo cmd
# Ctrl+R Ctrl+R for restart
# Command history is here.
```
Closes#2657
### Env
Use `$XONSH_HISTORY_SIGINT_FLUSH=False` to switch it off.
## For community
⬇️ **Please click the 👍 reaction instead of leaving a `+1` or 👍
comment**
---------
Co-authored-by: a <1@1.1>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
### Motivation
There is no way to access to the CommandPipeline of executed command in
uncaptured mode. This causes:
* No chance to get return code in one universal way.
* Barrier to trace and inspection.
### Before
```xsh
$(ls nofile)
# No way to access to the CommandPipeline of executed command.
```
### After
```xsh
$(ls nofile)
__xonsh__.last.rtn # In interactive or not interactive.
# 2
```
```xsh
# Sugar sir:
last = type('LastCP', (object,), {'__getattr__':lambda self, name: getattr(__xonsh__.last, name) })()
ls nofile
last.rtn
# 2
```
JFYI #5342
## For community
⬇️ **Please click the 👍 reaction instead of leaving a `+1` or 👍
comment**
---------
Co-authored-by: a <1@1.1>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
### Motivation
Closes#4636
In fact`Env` manages two lists: explicitly set values and Xettings. When
we operate with env we have no detyping for Xettings. The `detype_all`
function doint detyping for all possible env variables.
### Before
```xsh
# No way to get all detyped variables e.g.
'PROMPT' in __xonsh__.env.detype()
# False
```
### After
```xsh
'PROMPT' in __xonsh__.env.detype_all()
# True
```
## For community
⬇️ **Please click the 👍 reaction instead of leaving a `+1` or 👍
comment**
---------
Co-authored-by: a <1@1.1>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
### Before
```xsh
echo 1
echo 2
# <<Crash>>
# No json history
```
### After
Closes#2657
```xsh
echo 1
echo 2
# <<Crash>>
# In json history
# echo 1
# echo 2
```
## For community
⬇️ **Please click the 👍 reaction instead of leaving a `+1` or 👍
comment**
---------
Co-authored-by: a <1@1.1>
When cls.f is partial it's better to show full specification.
## For community
⬇️ **Please click the 👍 reaction instead of leaving a `+1` or 👍
comment**
---------
Co-authored-by: a <1@1.1>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Because we downgraded ptk in https://github.com/xonsh/xonsh/pull/5403
### Before
```xsh
xonsh --no-rc
# /Users/pc/.local/mamba-envs/lib/python3.12/site-packages/prompt_toolkit/application/application.py:961: DeprecationWarning: There is no current event loop
# loop = asyncio.get_event_loop()
#@
```
### After
```xsh
xonsh --no-rc
#@
```
## For community
⬇️ **Please click the 👍 reaction instead of leaving a `+1` or 👍
comment**
---------
Co-authored-by: a <1@1.1>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
### Before
Case 1: Handler catches the exit signal and do not pass it forward. As
result xonsh could be suspended by OS or crash. Also exit code is wrong.
See repeatable examples with SIGHUP in
https://github.com/xonsh/xonsh/issues/5381#issuecomment-2097961804.
Case 2: From bash/zsh as login shell run xonsh. Then send quit signal to
xonsh. The terminal state will be broken: disabled SIGINT, mouse pointer
produces mouse state codes.
### After
Case 1: Xonsh exit normally with right exit code. Fixed#5381#5304#5371.
Case 2: After exiting with right exit code the state of the terminal is
good.
## For community
⬇️ **Please click the 👍 reaction instead of leaving a `+1` or 👍
comment**
---------
Co-authored-by: a <1@1.1>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
