Open horeah opened 1 year ago
@santagada I believe you are a Linux/shell user -- I would really appreciate your feedback on this one.
Indeed it seems interesting, having most features of fish without changing your shell syntax. But I would say there's still plenty to do to make PyCMD even more awesome.
By the way, PyCMD has been my daily driver for a long time, I forget how good it is until I have to use a machine without it.
In a WSL/Ubuntu shell I cloned the repo into ~/PyCmd and checked out 'mesh'. When I manually run it via python3.11 ~/PyCmd/PyCmd.py
then everything works ok. But when I place python3.11 ~/PyCmd/PyCmd.py
at the bottom of ~/.bashrc
, in order to use it as the default shell, then PyCmd endlessly loops printing all output vertically thus only one character per line:
W
e
l
c
o
m
e
t
o
P
y
C
m
d
<
n
o
b
u
i
l
d
d
a
t
e
>
-
x
6
4
!
[
u
f
o
@
H
P
4
7
0
]
~
>
Maybe somebody has an idea about this behavior?
/EDIT:
It actually works when placing it into ~/.profile
instead, which would be more correct anyway.
Running commands that produce a lot of output is much slower compared to a typical shell; this is because the output is intercepted by PyCmd and therefore processed in Python
I was curious and also did some measuring. With PyCmd it was indeed 4 times slower on Linux compared to bash w/o PyCmd.
But how come that PyCmd is not slower on Windows at all compared to a classic Windows terminal w/o PyCmd?
On Windows the test command dir /s /b C:\Windows\*
took 30 seconds, no matter if with or without PyCmd.
In a WSL/Ubuntu shell I cloned the repo into ~/PyCmd and checked out 'mesh'. When I manually run it via python3.11 ~/PyCmd/PyCmd.py then everything works ok. But when I place python3.11 ~/PyCmd/PyCmd.py at the bottom of ~/.bashrc, in order to use it as the default shell, then PyCmd endlessly loops printing all output vertically thus only one character per line
The mechanism for wrapping bash is kind of hacky, PyCmd actually creates a customized bashrc based on the user's bashrc and passes it to a newly started bash; this is not very robust, and can create weird behavior as you just noticed. I'm not entirely happy with the whole thing, but bash is devilishly hard to control from an outside program so I have to accept whatever way I was able to come up with :) -- at least for now.
I was curious and also did some measuring. With PyCmd it was indeed 4 times slower on Linux compared to bash w/o PyCmd.
I am surprised that you only see a 4x slowdown -- in my tests, I sometimes see up to 20x (e.g. for commands which produce large amounts of output with very little processing or I/O, such as find /usr/lib
). I am currently testing an improvement that makes it twice as fast; this is still far from great, but since PyCmd is targeted at interactive usage it is not a huge problem in practice (running find /usr/lib
in an interactive session is not something people do often; for most interactive commands, the output-printing overhead is negligible compared to the actual "work" that the command performs).
But how come that PyCmd is not slower on Windows at all compared to a classic Windows terminal w/o PyCmd? On Windows the test command dir /s /b C:\Windows* took 30 seconds, no matter if with or without PyCmd.
The explanation is that the mechanism of wrapping around cmd.exe is completely different (just as hacky, but in a different way) from the mechanism used for wrapping around bash. Both could probably be improved, but it would take a lot of work and I cannot afford to spend that much time :(
As an experiment, PyCmd can now also run on Linux (or WSL) as a front-end for bash; this issue is for collecting and tracking related feedback.
Rationale: while shells focused on user interaction do exist in the Linux world (e.g. fish, and also zsh in some regards) and they are way more advanced than PyCmd, there are still a few areas that PyCmd/Linux covers better (at least in my opinion):
There are a lot of things that are currently not working or need to be improved, of course; the most important ones are listed here:
One can try it out using release bundle "20230424-linux64", or by checking out branch "mesh" -- note that I consider this a "private" branch for now and might be still amending/rebasing; if someone wants to contribute, some prior coordination will be needed.