Ergonomica – A cross-platform shell written in Python(github.com)
github.com
Ergonomica – A cross-platform shell written in Python
https://github.com/ergonomica/ergonomica
8 comments
I would love to drop bash/zsh for some other python-based shell like xonsh. I tried it already a few times, and having access to the python language and built-ins right from the prompt is amazing. The way the found to mix both command prompt and python syntax seems really smart. Nevertheless, the effort to update all my (quite extensive) zsh setup, as well as the cognitive effort to re-educate my brain, is huge. So I want to have to do it only once. This means it should be A) a project that has chances to survive in the long term, so not dependent on a single developer, and B) that has chances to become the reference one, gathering most of the users/contributors.
I don't know about the current craving for such technologies -- if it is a good idea or not -- nor the place of xonsh in all this. My main concern with xonsh is a blog article (Nov 2015) [1], that implies some issues regarding the management and the direction of the project.
Does anyone have opinion/experience on these python-based shells, the existing alternatives, and more specifically about xonsh?
[1] http://www.skepticism.us/2015/11/xonsh-is-no-longer-a-possib...
I don't know about the current craving for such technologies -- if it is a good idea or not -- nor the place of xonsh in all this. My main concern with xonsh is a blog article (Nov 2015) [1], that implies some issues regarding the management and the direction of the project.
Does anyone have opinion/experience on these python-based shells, the existing alternatives, and more specifically about xonsh?
[1] http://www.skepticism.us/2015/11/xonsh-is-no-longer-a-possib...
Hi StreakyCobra, Anthony Scopatz here (one of the lead developers of xonsh). I'd like to say that I hope that xonsh is the solution for you and if there are tools or features that you need or would like to see, please always feel free to bring them up on our issue tracker [1] or gitter [2]. Pull requests are also always welcome.
Now as per the post about not being a zsh replacement that you mention, I'd like to give my perspective. That post was authored by an individual who had put in few pull requests [3,4] where he was attempting to:
1. Move the xonsh code base from PEP8 to Google Python Style Guide 2. Instist that the map() and filter() Python builtins were deprecated (they aren't) and that they shouldn't be used.
After getting feedback from us about how these and other style changes didn't conform to existing norms in the code base, he simply closed the PRs and then wrote that blog post. I am disappointed that this unnecessary attack on the xonsh project and me personally has created uncertainty around the project.
We really are trying to build a better shell for everyone. Everyone is invited and welcome to participate in that process. We strive to have an kind development and user community. It should be a pleasure not just to use xonsh, but also contribute to its creation.
Again if there are specific things, that you'd like to see, please let us know!
[1] https://github.com/xonsh/xonsh/issues [2] https://gitter.im/xonsh/xonsh [3] https://github.com/xonsh/xonsh/pull/508 [4] https://github.com/xonsh/xonsh/pull/512
Now as per the post about not being a zsh replacement that you mention, I'd like to give my perspective. That post was authored by an individual who had put in few pull requests [3,4] where he was attempting to:
1. Move the xonsh code base from PEP8 to Google Python Style Guide 2. Instist that the map() and filter() Python builtins were deprecated (they aren't) and that they shouldn't be used.
After getting feedback from us about how these and other style changes didn't conform to existing norms in the code base, he simply closed the PRs and then wrote that blog post. I am disappointed that this unnecessary attack on the xonsh project and me personally has created uncertainty around the project.
We really are trying to build a better shell for everyone. Everyone is invited and welcome to participate in that process. We strive to have an kind development and user community. It should be a pleasure not just to use xonsh, but also contribute to its creation.
Again if there are specific things, that you'd like to see, please let us know!
[1] https://github.com/xonsh/xonsh/issues [2] https://gitter.im/xonsh/xonsh [3] https://github.com/xonsh/xonsh/pull/508 [4] https://github.com/xonsh/xonsh/pull/512
Hi scopatz, thanks for taking time to comment here. I got the feeling from the other comments here that indeed this blog post was kind of a scam.
I played with xonsh a little bit yesterday and went trough the tutorial, so far I'm pleased with it. I changed it as my default shell for the fun today, but damn, it's hard to re-educate my muscle memory. I will have to do some changes in order to make it usable:
- Customize the VI binding (I have some weird keyboard layout)
- Replace my aliases, scripts, functions, and `source` command that are [ba|z]sh specific (like ranger-cd [1]). This will be time consuming.
- Find why `ranger` takes so much time to quit.
I also have kind of a weirdo bug, but I want to be sure to understand where it's coming from before opening an Issue: It slow as hell when I try to open a terminal, and I have a warning about branch-timeout. The problem is that my home repository is not a literally a git repository. I still have some dotfiles versioned as explained in [2], but if I call `git ` commands from the home it says it's not a git repository, so I don't get why this git-related timeout.
Anyway, I will see if I try to continue right away, or if I wait a few weeks for some holidays in order to find time for the transition.
Thanks for this software!
[1] https://gist.github.com/ha7ilm/37c4272b1df6fbfdb0df304642522...
[2] https://developer.atlassian.com/blog/2016/02/best-way-to-sto...
I played with xonsh a little bit yesterday and went trough the tutorial, so far I'm pleased with it. I changed it as my default shell for the fun today, but damn, it's hard to re-educate my muscle memory. I will have to do some changes in order to make it usable:
- Customize the VI binding (I have some weird keyboard layout)
- Replace my aliases, scripts, functions, and `source` command that are [ba|z]sh specific (like ranger-cd [1]). This will be time consuming.
- Find why `ranger` takes so much time to quit.
I also have kind of a weirdo bug, but I want to be sure to understand where it's coming from before opening an Issue: It slow as hell when I try to open a terminal, and I have a warning about branch-timeout. The problem is that my home repository is not a literally a git repository. I still have some dotfiles versioned as explained in [2], but if I call `git ` commands from the home it says it's not a git repository, so I don't get why this git-related timeout.
Anyway, I will see if I try to continue right away, or if I wait a few weeks for some holidays in order to find time for the transition.
Thanks for this software!
[1] https://gist.github.com/ha7ilm/37c4272b1df6fbfdb0df304642522...
[2] https://developer.atlassian.com/blog/2016/02/best-way-to-sto...
Regarding the blog post: Xonsh now has 125 contributors on GH, is tested by Travis, Circle & Appveyor, and is analysed by Lanscape (https://landscape.io/github/xonsh/xonsh/2936). I see the Landscape score is not that great, but also that lots of the errors reported are false positive.
So IMHO there are some serious QA efforts going on on Xonsh, and the concerns reported by the blog post you are citing are probably past history.
So IMHO there are some serious QA efforts going on on Xonsh, and the concerns reported by the blog post you are citing are probably past history.
Thanks for the review! Indeed it seems that this criticism is part of the history now.
I usually use iPython shell and prefix commands with '!' so it works as a shell command. It's pretty handy if you always have Python interpreter open. Not sure if this is what you want though.
It's a nice idea, I haven't thought of doing so. Maybe if I change the ipython prompt to something more fancy it can be a nice solution.
I'm a Zsh user who tried xon.sh for 3 months now and reverted to Zsh just a few days ago. Performance. I easily have ~20 shell instances running (under tmux), and having each one of them run python simply slowed down my computer. I got back to Zsh and while I miss some of xon.sh features (most notable one is calculating things just by typing "1+1"), everything feels so much snappier now.
Except for the performance problem (I'll probably not be concerned with my workflow), what are the pros/cons of xonsh for you? Some of my concerns are:
- Does having direct access to Python really make your work in command line faster/easier?
- Is there some paradigms that are more difficult to express in xonsh (redirect, pipes, …)
- Did you happen to encounter bugs, or made mistakes without intent to do it (like overwriting/removing files, …) ?
In other words, without the performance problem, would you continue to use xonsh and recommend it?
- Does having direct access to Python really make your work in command line faster/easier?
- Is there some paradigms that are more difficult to express in xonsh (redirect, pipes, …)
- Did you happen to encounter bugs, or made mistakes without intent to do it (like overwriting/removing files, …) ?
In other words, without the performance problem, would you continue to use xonsh and recommend it?
>Does having direct access to Python really make your work in command line faster/easier?
Easier for me to write custom commands/aliases. I'm sure I could come up with creative uses for it - just haven't taken the time to do so. Also, I'm not a super sed/awk user, so that's an example where knowing Python helps.
>Is there some paradigms that are more difficult to express in xonsh (redirect, pipes, …)
Haven't run across any. I think a few may be mentioned in the docs, though.
>Did you happen to encounter bugs, or made mistakes without intent to do it (like overwriting/removing files, …) ?
Bugs: Yes - only applicable for Windows. In Windows, environment variables are case-insensitive, but xonsh still treats them as case sensitive (as in setting ABC=5 and subsequently abc=7 ends up with two env vars) caused a problem with bat scripts I ran as part of a build process. Filed a bug - I'm sure they'll fix it.
Anything serious like overwriting/removing? Nope.
Caveat: I'm not a serious, power shell user. For me, just having a decent history, line editor, autocompletion was great. However, there is nothing that I'm used to in zsh in Linux that I clearly miss in xonsh. I'm sure I've thought a few minor things where it'll probably trivial for me to customize xonsh to get that zsh behavior...
Easier for me to write custom commands/aliases. I'm sure I could come up with creative uses for it - just haven't taken the time to do so. Also, I'm not a super sed/awk user, so that's an example where knowing Python helps.
>Is there some paradigms that are more difficult to express in xonsh (redirect, pipes, …)
Haven't run across any. I think a few may be mentioned in the docs, though.
>Did you happen to encounter bugs, or made mistakes without intent to do it (like overwriting/removing files, …) ?
Bugs: Yes - only applicable for Windows. In Windows, environment variables are case-insensitive, but xonsh still treats them as case sensitive (as in setting ABC=5 and subsequently abc=7 ends up with two env vars) caused a problem with bat scripts I ran as part of a build process. Filed a bug - I'm sure they'll fix it.
Anything serious like overwriting/removing? Nope.
Caveat: I'm not a serious, power shell user. For me, just having a decent history, line editor, autocompletion was great. However, there is nothing that I'm used to in zsh in Linux that I clearly miss in xonsh. I'm sure I've thought a few minor things where it'll probably trivial for me to customize xonsh to get that zsh behavior...
Thanks for the feedback. I think I'll give it a go!
I've been using it for a few months on Windows - mostly because I wanted a bash-like shell on Windows.
No problems so far. Quite happy with it. The ability to do custom stuff in Python is an obvious benefit.
On Linux I use zsh. The only reason I do not replace it with xonsh is that I don't have the time to do so. My zsh setup is fairly plain - I could never learn advanced bash/zsh shell usage - way too magical for me.
If I had the time, I'd probably just switch my Linux prompt to xonsh. xonsh is much easier to learn than zsh.
I cannot really comment on the performance. Have not noticed issues so far, but frankly, I do not need a high performing shell.
As for that blog post, he made some good points, but there was a lot of pettiness over his contributions that were rejected. I know many people don't like filter, but he has to realize that many Python programmers do like filter - including myself.
No problems so far. Quite happy with it. The ability to do custom stuff in Python is an obvious benefit.
On Linux I use zsh. The only reason I do not replace it with xonsh is that I don't have the time to do so. My zsh setup is fairly plain - I could never learn advanced bash/zsh shell usage - way too magical for me.
If I had the time, I'd probably just switch my Linux prompt to xonsh. xonsh is much easier to learn than zsh.
I cannot really comment on the performance. Have not noticed issues so far, but frankly, I do not need a high performing shell.
As for that blog post, he made some good points, but there was a lot of pettiness over his contributions that were rejected. I know many people don't like filter, but he has to realize that many Python programmers do like filter - including myself.
To be honest, the author of that blog post seems like he's kinda being a bit of a dick.
> I submitted several lint cleanup pull requests. Getting each one accepted was a challenge. Primarily because the project owner isn’t really interested in having lint clean code.
Having read through the PRs he filed[1], the "challenge" the author faced was to do with his needlessly changing things around to match Google style guide, which the project doesn't actually observe. (There's a lot of comments of the form "as a former Google employee, my shit doesn't stink" in there, as it happens.) In fact, most of them were merged straight away except his last one[2], where he'd changed existing code away from the project's preferred style, been asked not to, then threw a tanty and closed the issue.
> for d in filter(os.path.isdir, path):
This and the other example he gives are both from that last issue, which leads me to think this blog post was part of the aforementioned tanty. (It was published on the same day, too.) Let's be honest, if the worst issue you can find with a codebase is that it uses filter() instead of a generator expression, it's probably a pretty good codebase.
> All you have to do is Google “python map filter deprecated”.
Yes, do, and you'll find they aren't. The BDFL doesn't like them, but that's not the same thing.
> I noticed that the directions for running the unit tests did not test the code in my local git repository — it tested the code installed by pip. ... Anthony told me he wrote the directions to specifically test the installed code, not the code in his git repository and he didn’t understand why anyone would test their uncommitted code.
I can't find the issue where he raises this, or where the maintainer says that. Perhaps the author isn't familiar with `pip install -e`? All of the other issues in that first 'P.S.' paragraph appear to be fixed, some by him even.
tl;dr This doesn't seem like a damning criticism of fundamental project management issues so much as a tantrum being thrown by someone because they couldn't walk in to a project and impose their stylistic preferences on everyone else.
[1]: https://github.com/xonsh/xonsh/search?utf8=%E2%9C%93&q=is%3A... [2]: https://github.com/xonsh/xonsh/pull/512
> I submitted several lint cleanup pull requests. Getting each one accepted was a challenge. Primarily because the project owner isn’t really interested in having lint clean code.
Having read through the PRs he filed[1], the "challenge" the author faced was to do with his needlessly changing things around to match Google style guide, which the project doesn't actually observe. (There's a lot of comments of the form "as a former Google employee, my shit doesn't stink" in there, as it happens.) In fact, most of them were merged straight away except his last one[2], where he'd changed existing code away from the project's preferred style, been asked not to, then threw a tanty and closed the issue.
> for d in filter(os.path.isdir, path):
This and the other example he gives are both from that last issue, which leads me to think this blog post was part of the aforementioned tanty. (It was published on the same day, too.) Let's be honest, if the worst issue you can find with a codebase is that it uses filter() instead of a generator expression, it's probably a pretty good codebase.
> All you have to do is Google “python map filter deprecated”.
Yes, do, and you'll find they aren't. The BDFL doesn't like them, but that's not the same thing.
> I noticed that the directions for running the unit tests did not test the code in my local git repository — it tested the code installed by pip. ... Anthony told me he wrote the directions to specifically test the installed code, not the code in his git repository and he didn’t understand why anyone would test their uncommitted code.
I can't find the issue where he raises this, or where the maintainer says that. Perhaps the author isn't familiar with `pip install -e`? All of the other issues in that first 'P.S.' paragraph appear to be fixed, some by him even.
tl;dr This doesn't seem like a damning criticism of fundamental project management issues so much as a tantrum being thrown by someone because they couldn't walk in to a project and impose their stylistic preferences on everyone else.
[1]: https://github.com/xonsh/xonsh/search?utf8=%E2%9C%93&q=is%3A... [2]: https://github.com/xonsh/xonsh/pull/512
Thanks. Back in the time I read it I also tried to look at issues to verify the criticism, but I was not experienced enough to fully understand all the topics involved in the discussions.
Existing alternative is obviously PowerShell. With 10+ years in production its obvious choice in Windows and it gets better every day on Unix like systems.
All those alternatives that use some mainstream language not designed originally as a shell language (xonsh [python], rash [ruby], this [python], rhino [javascript], whatever) so far didn't hold water - the shell is not an afterthought, it needs upfront design and its own language.
All those alternatives that use some mainstream language not designed originally as a shell language (xonsh [python], rash [ruby], this [python], rhino [javascript], whatever) so far didn't hold water - the shell is not an afterthought, it needs upfront design and its own language.
got a link for rash?
https://github.com/adamwiggins/rush
Its rush, a typo. I do not recommend it for serious usage, its more or less failed PoC. On the other hand, its basically the same as ergonomica, and I would prefer ruby to python when shell is in question, given that white space thingie.
It looks like there was a recent activity maintainer tho, see a PR, but its abandoned again: https://github.com/adamwiggins/rush/pull/19
Its rush, a typo. I do not recommend it for serious usage, its more or less failed PoC. On the other hand, its basically the same as ergonomica, and I would prefer ruby to python when shell is in question, given that white space thingie.
It looks like there was a recent activity maintainer tho, see a PR, but its abandoned again: https://github.com/adamwiggins/rush/pull/19
Looks like the blog post you linked to has been removed...unintentionally.
See this screenshot:
https://s32.postimg.org/c88tck939/derp.png
https://s32.postimg.org/c88tck939/derp.png
It appears that the article that you linked to has been defaced? http://web.archive.org/web/20160426011748/http://www.skeptic... is an archive link before the defacement occurred.
author here—the idea for this shell would be to have something that worked like python, but was more ergonomica(a :) ). Something like what rajathagasthya suggested (using iPython as your terminal) is also very cool, and so is xonsh. Take it or leave it, it's a different style of shell that I figured I'd try making.
wow this is great!
Watching the screen share it's apparent they don't use efficient terminal movements.
Ctrl-A/E,end of line beginning of line, and Alt-B/F, move forward and backward by word are your friend.
Lots of innocent keyboards abused for no reason.
Ctrl-A/E,end of line beginning of line, and Alt-B/F, move forward and backward by word are your friend.
Lots of innocent keyboards abused for no reason.
Screen share is so irritating with author continuing deleting phrases that I lost interest ASAP.
Just pressing Enter at the end would have been a lot less irritating.
That was the first thing I noticed too. No CTRL+U? It looks like a cool project, but I'll hold off until there are better navigation options (unless there already are, and the video producer simply wasn't using them).
[deleted]
haha thanks i'm a real keyboard n00b
Huh, neat project, but it points me towards asciicinema, which is a really neat service/idea I've never heard of before. What a good lil niche service.
Their name is actually spelled asciinema, which they really should not have chosen. I keep misreading it as 'ascii enema' :\
A better alternative is ttyrec + tty-player which doesn't depend on a third party service to host your data.
https://github.com/ergonomica/ergonomica/wiki/Installation the installation is somewhat weird.
The 'Homepage' link to https://mtklabs.github.io/ergonomica 404s.
This one works: https://ergonomica.github.io/
[deleted]
[deleted]
hmm, it's pretty strange. I don't understand why it was implemented in Python, not in JavaScript.
python's `os` and `subprocess` molecules, basically. Javascript was designed for the web, not to be run locally on a computer (that's why there isn't a clear "import file" directive). I also like Python more :).
OK, I will bite. Why JavaScript? What would it bring to an interactive environment that Python does not?
When it comes to Linux machines and servers, it has been a long time since I've seen one that didn't have some form of Python already installed on it by default. I don't think I can say the same for nodejs.
How much does it converge / diverge w/ Xonsh (http://xon.sh/)?
Besides the obvious fact that Xonsh is (from what I can tell at first glance) a Python-like shell scripting language, and Ergo a bash-like shell language written in Python.