Replies: 3 comments 1 reply
-
|
Could you please give step by step list of commands to reproduce this? (example). |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
I'm on FreeBSD here, so docker is out for the moment. I can try tomorrow on my laptop though. Until then, I reproduced this in a freshly installed FreeBSD jail by doing the following (and you should be able to do the same in a simple FreeBSD VM): # pkg install -y python3 py39-gdbm py39-sqlite3 py39-tkinter py39-pipx mise
[...]
# vi /usr/local/lib/python3.9/site-packages/pipx/main.py
Change Line 31 from
from pipx.version import __version__
to
from pipx.version import version as __version__
apparently there is a bug in FreeBSD package build infrastructure re: setuptools
# pipx install "xonsh[full]"
[...]
# $HOME/.local/bin/xonsh
xonsh # captured=!(mise activate xonsh) # this will output directly to the terminal below instead of capturing into "captured"
from os import environ
from xonsh.built_ins import XSH
def listen_prompt(): # Hook Events
execx($(/usr/local/bin/mise hook-env -s xonsh))
XSH.builtins.events.on_pre_prompt(listen_prompt) # Activate hook: before showing the prompt
xonsh # captured
CommandPipeline(
stdin=None,
stdout=None,
stderr=None,
pid=38623,
returncode=0,
args=['mise', 'activate', 'xonsh'],
alias=None,
stdin_redirect=['<stdin>', 'r'],
stdout_redirect=['<stdout>', 'a'],
stderr_redirect=['<stderr>', 'r'],
timestamps=[1711496533.3542247, 1711496536.2758603],
executed_cmd=['mise', 'activate', 'xonsh'],
input='',
output='',
errors=None
)
xonsh # !(ls).output
''
xonsh # cap = !(ls)
xonsh # cap.output
''
xonsh # cap
CommandPipeline(
stdin=<_io.BytesIO object at 0xcada8c265e0>,
stdout=<_io.BytesIO object at 0xcada8c26360>,
stderr=<_io.BytesIO object at 0xcada8c26450>,
pid=41255,
returncode=0,
args=['ls'],
alias=['ls', '-G'],
stdin_redirect=['<stdin>', 'r'],
stdout_redirect=[9, 'wb'],
stderr_redirect=[11, 'w'],
timestamps=[1711496613.5009933, 1711496633.665368],
executed_cmd=['ls', '-G'],
input='',
output='.cshrc\n.profile\nbin\nboot\nCOPYRIGHT\ndev\netc\nlib\nlibexec\nmedia\nmnt\nnet\nproc\nrescue\nroot\nsbin\nsys\ntmp\nusr\nvar\n',
errors=None
)
xonsh # cap.output
'.cshrc\n.profile\nbin\nboot\nCOPYRIGHT\ndev\netc\nlib\nlibexec\nmedia\nmnt\nnet\nproc\nrescue\nroot\nsbin\nsys\ntmp\nusr\nvar\n' |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Here's the docker run showing the # docker run -it --rm python:3.12-slim bash
root@6cbf00d41a45:/# pip install pipx
Collecting pipx
Downloading pipx-1.5.0-py3-none-any.whl.metadata (17 kB)
Collecting argcomplete>=1.9.4 (from pipx)
Downloading argcomplete-3.2.3-py3-none-any.whl.metadata (16 kB)
Collecting packaging>=20 (from pipx)
Downloading packaging-24.0-py3-none-any.whl.metadata (3.2 kB)
Collecting platformdirs>=2.1 (from pipx)
Downloading platformdirs-4.2.0-py3-none-any.whl.metadata (11 kB)
Collecting userpath!=1.9.0,>=1.6 (from pipx)
Downloading userpath-1.9.2-py3-none-any.whl.metadata (3.0 kB)
Collecting click (from userpath!=1.9.0,>=1.6->pipx)
Downloading click-8.1.7-py3-none-any.whl.metadata (3.0 kB)
Downloading pipx-1.5.0-py3-none-any.whl (72 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 72.0/72.0 kB 525.6 kB/s eta 0:00:00
Downloading argcomplete-3.2.3-py3-none-any.whl (42 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 42.6/42.6 kB 339.3 kB/s eta 0:00:00
Downloading packaging-24.0-py3-none-any.whl (53 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 53.5/53.5 kB 5.4 MB/s eta 0:00:00
Downloading platformdirs-4.2.0-py3-none-any.whl (17 kB)
Downloading userpath-1.9.2-py3-none-any.whl (9.1 kB)
Downloading click-8.1.7-py3-none-any.whl (97 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 97.9/97.9 kB 3.5 MB/s eta 0:00:00
Installing collected packages: platformdirs, packaging, click, argcomplete, userpath, pipx
Successfully installed argcomplete-3.2.3 click-8.1.7 packaging-24.0 pipx-1.5.0 platformdirs-4.2.0 userpath-1.9.2
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
root@6cbf00d41a45:/# pipx install "xonsh[full]"
installed package xonsh 0.15.1, installed using Python 3.12.2
These apps are now globally available
- xonsh
- xonsh-cat
- xonsh-uname
- xonsh-uptime
⚠ Note: '/root/.local/bin' is not on your PATH environment variable. These apps will not be globally accessible until your PATH is updated. Run `pipx ensurepath` to
automatically add it, or manually modify your PATH in your shell's config file (i.e. ~/.bashrc).
done! ✨ 🌟 ✨
root@6cbf00d41a45:/# ~/.local/bin/xonsh
Welcome to the xonsh shell 0.15.1
~ This fix was trickier than expected ~
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Create ~/.xonshrc file manually or use xonfig to suppress the welcome message
Start from commands:
xonfig web # Run the configuration tool in the browser to create ~/.xonshrc
xonfig tutorial # Open the xonsh tutorial in the browser
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
<user>@6cbf00d41a45 / # !(ls).output
''
<user>@6cbf00d41a45 / # a=!(ls)
<user>@6cbf00d41a45 / # a.outout
xonsh: For full traceback set: $XONSH_SHOW_TRACEBACK = True
AttributeError: 'CommandPipeline' object has no attribute 'outout'. Did you mean: 'output'?
<user>@6cbf00d41a45 / [1] # a.output
''
<user>@6cbf00d41a45 / # type(a)
xonsh.procs.pipelines.CommandPipeline
<user>@6cbf00d41a45 / # a.output
''
<user>@6cbf00d41a45 / # a
CommandPipeline(
stdin=<_io.BytesIO object at 0x7ffb750a3c40>,
stdout=<_io.BytesIO object at 0x7ffb750a3c90>,
stderr=<_io.BytesIO object at 0x7ffb750a3ce0>,
pid=61,
returncode=0,
args=['ls'],
alias=['ls', '--color=auto', '-v'],
stdin_redirect=['<stdin>', 'r'],
stdout_redirect=[12, 'wb'],
stderr_redirect=[14, 'w'],
timestamps=[1712345771.374156, 1712345797.337962],
executed_cmd=['ls', '--color=auto', '-v'],
input='',
output='bin\nboot\ndev\netc\nhome\nlib\nlib64\nmedia\nmnt\nopt\nproc\nroot\nrun\nsbin\nsrv\nsys\ntmp\nusr\nvar\n',
errors=None
)
<user>@6cbf00d41a45 / # a.output
'bin\nboot\ndev\netc\nhome\nlib\nlib64\nmedia\nmnt\nopt\nproc\nroot\nrun\nsbin\nsrv\nsys\ntmp\nusr\nvar\n'
<user>@6cbf00d41a45 / # |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Thank you for details! This is known issue - #3394 |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I'm currently working on making xonsh support in
misebetter. Short primer if you don't knowmise: Likeasdf,pyenvet. al. it manages multiple versions of various tools like python, ruby, zig, neovim, etc. You can choose e.g. what version of python3 is executed by default using various methods like config files in your $HOME, config files in a projects directory, or, and that is the key part here, by setting an environment variable.If I have a variable named MISE_PYTHON_VERSION set to '3.11.8', a pre-prompt xonsh hook updates my $PATH to include that version up front.
For this, I can use
mise shell python@3.1.18. This wasn't implemented for xonsh though, so I looked into it, trying to see if I can port this from other shells. Now, mise is written in Rust, and I don't know rust, but the way mise is constructed as I understand it is, is that it needs "activation" for some of its features likemise shellto work. During activation, an alias namedmiseis created, shadowing themisebinary. That's how it was done in other shells, I just decided to port that approach, so if there is an easier way to do this, I'm open to it.Now, that alias just checks what subcommand you want to run, and anything that's not "shell" (or "activate", but we can ignore that here) just gets turned over to the actual binary, which is accessed by either
command mise, or bywhich -s miseto get the path to the binary. The idea is then to capture that binaries stdout/stderr and return it, essentially being a do-nothing proxy.If the subcommand however is "shell", it would capture the output of the binary, and
execxit. That's because the output of the regular binary for the "shell" subcommand is essentially just a string of xonsh/python that imports xonsh.built_ins.XSH and adds to XSH.env the environment variables it needs. So when that then getsexecx'd, the variables are set. That's how it accesses the shells environment.Now, there where already comments in the code about problems with colourizing output. As I understand it, if we proxy to the actual binary, that binary doesn't see a TTY attached to its stdout, so it thinks it's not writing to a shell output, and doesn't add the nice colors. That's why at some points,
subprocess.runis used instead. That was my original implementation of the "shell" subcommand, justsubprocess.runthe actual binary, and it seemed to work. Even with colors! Yay!Then i realised I couldn't
grepthe output. It would just always output everything while throwing an error. After a long time of going crazy, I realised the error came from the fact that in a pipeline likemise list-all | grep pyth, thegrepnever received any input before being told that the pipeline is done.mise list-allsomehow outputs directly to the terminal, bypassing the shells stdout/stderr. This at first happened because I forgot to add thestdout=subprocess.PIPEto therun, which works in capturing the now colorless output. I then experimented quite a bit, and to my surprise, replacingsubprocess.runwith subprocess capturing with!(mise ls)returns aCommandPipelineobject whose 'output' is the empty string, again printing directly to the terminal?! I'm very confused by all of this.As a sidenote: while investigating this and experimenting, i have also seen strange errors like
!(ls).outputbeing empty, buta=!(la)followed bya.outputsometimes works. Sometimes it doesn't work, until I first access the object once by itself (simply typinga<ENTER>), thena.outputsuddenly has the expected content.In addition, this seems to destabalize and sometimes crashes xonsh itself at seemingly random points with various roughly file I/O related errors:
or
or
I verified this all in a
xonsh --no-rcshell with no xontribs loaded. (Except manuallyxontrib load rtx;rtxbeing the old name ofmise)Xonsh installed via pipx on python3.11.8 on FreeBSD 14
Now, because of the aforementioned
!(ls).outputissue, and because I couldn't find any indication thatmisedoes anything other than normal stdout/stderr, (and because I think even if it where amiseissue, a shell should not crash from it) I think this is an issues in xonsh, but I have no idea how to further debug this.edit
Same behaviour if I replace
!(ls)withxonsh.procs.specs.run_subproc([['ls']], captured='object')!/edit
I didn't open an issue for now as I'd like to see if anyone has a bit more insight, or can point to something obvious I'm overlooking.
Beta Was this translation helpful? Give feedback.
All reactions