FWIW (as the original author of xonsh), xonsh does have a strict separation of Python and subprocess syntax. Users can always choose to write in fully formal xonsh, it is just that most users choose to use the default convenience mechanisms that xonsh provides.
Thanks for the clarification. I read an interview with you, and there was some discussion of the difficulties in parsing things like "ls -lR", and whether to interpret that as an ls command with flags, or a subtraction. (If I'm remembering correctly.)
If a xonsh user does want to do strict separation, how does that work? Syntactically, how do you separate shell code from Python code?
It means that it is not fully sh-lang compatible (i.e. a true unix shell), but is as compatible as reasonably achievable while maintaining full compatibility with Python 3.
posix sh mandates certain constructs work. For example:
x=foo; x=${x%o}; echo $x # prints 'fo'
Supporting that is non-trivial in python. There's no quotes around the strings, '%' is kinda weird there, etc.
Of course, in python you can just say:
x="foo"; x=x[0:2]
... but those are not compatible with each other. colon does different things in posix sh than python, and it would be quite complicated to reconcile it.
I'll also point out the parent poster, when they wrote "sh-lang", meant "the superset of posix-sh that zsh/bash users expect", because at this point quite a few bash features are expected to work in most sh-like shells.
Naturally, both xonsh and sh (and all other shells pretty much) are turing complete and can execute programs, which makes them all equally capable.
Having equivalent capabilities does not mean things are compatible though. I recommend reading up on what a POSIX shell is, and then reading fish and xonsh's arguments why they're not POSIX compliant (spread through various locations)
Python variables are scoped as normal, so the security story for xonsh is the same as for Python. We are always open to suggestions and PRs to harden the code base as needed.
Can you please open an issue detailing the problem? https://github.com/xonsh/xonsh/issues I'd love to help make this work. I believe that the emacs folks have something that works for them
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!
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.
