xonsh looks very cool. Shell scripting languages are famously obtuse and underpowered, and we've thought about how to cleanly merge shell scripting with a real language. It's heartening to see an attempt at it.
Ambiguous syntax is a sticking point. For example, say the user runs this:
[ 1 ]
is this constructing a Python list with the value 1, or is it invoking /bin/[ with two arguments? It's ambiguous! It looks like xonsh interprets it the first way. Any thoughts on this issue?
A related issue is the relationship between bash functions and Python functions. I'd be very interested to see how xonsh approaches this.
Also, here's some unsolicited advise, from one non-POSIX shell maintainer to another: The claim that xonsh is "bash-compatible" is delicate. Full bash compatibility requires your shell to be insane. E.g.
echo foo | cd /
cd / | echo foo
In bash, only the second line will change your working directory. Or consider this command:
*
this finds the first (for some meaning of first) file in your directory and invokes it with all other files as arguments. I tried it: xonsh doesn't handle either of these "correctly," which is to say that xonsh isn't yet insane. That's good news! On the other hand, this means it's not really bash compatible.
IME nobody really cares about full bash compatibility. What they want is for their existing bash stuff to just work. Bash shebang scripts will just run in real bash, but that leaves shell-integration scripts: virtualenv, rbenv, etc. Supporting that stuff is one of the most common requests that the fish shell gets, and one of the most commonly cited reasons for not using fish.
Here's a piece of rbenv's bash integration: https://github.com/sstephenson/rbenv/blob/master/libexec/rbe... . It's short but there's a lot of features being used: set, shopt, IFS, functions, etc. If you're aiming for bash compatibility, that's your target!
In the meantime, I suggest changing the language to express that xonsh is bash-like, not bash-compatible. Otherwise users are going to be confused and disappointed.
I also do this. However, literally just hours ago, Greg Wooledge, author of The Bash Guide, posted the following to the GNU bug-bash mailing list.
> Errexit (a.k.a. set -e) is horrible, and you should not be using it in any new shell scripts you write. It exists solely for support of legacy scripts.
edit: I asked after this (for whatever reason, my email isn't yet showing in the archives; maybe it will appear later), and got an interesting response!
Wow, this looks amazing. I really want to try this out.
On my current contract, we've been moving away from Jenkins and towards Gitlab CI. I still work on an opensource project that uses Jenkins to build. The screenshots show a really good pipeline layout. It seems like it's similar in power to Gitlab CI, but also looks like it has way better visual representations and UI.
I'm glad the Jenkins team is still moving forward and developing plugins/tools like this.
xonsh looks very cool. Shell scripting languages are famously obtuse and underpowered, and we've thought about how to cleanly merge shell scripting with a real language. It's heartening to see an attempt at it.
Ambiguous syntax is a sticking point. For example, say the user runs this:
is this constructing a Python list with the value 1, or is it invoking /bin/[ with two arguments? It's ambiguous! It looks like xonsh interprets it the first way. Any thoughts on this issue?A related issue is the relationship between bash functions and Python functions. I'd be very interested to see how xonsh approaches this.
Also, here's some unsolicited advise, from one non-POSIX shell maintainer to another: The claim that xonsh is "bash-compatible" is delicate. Full bash compatibility requires your shell to be insane. E.g.
In bash, only the second line will change your working directory. Or consider this command: this finds the first (for some meaning of first) file in your directory and invokes it with all other files as arguments. I tried it: xonsh doesn't handle either of these "correctly," which is to say that xonsh isn't yet insane. That's good news! On the other hand, this means it's not really bash compatible.IME nobody really cares about full bash compatibility. What they want is for their existing bash stuff to just work. Bash shebang scripts will just run in real bash, but that leaves shell-integration scripts: virtualenv, rbenv, etc. Supporting that stuff is one of the most common requests that the fish shell gets, and one of the most commonly cited reasons for not using fish.
Here's a piece of rbenv's bash integration: https://github.com/sstephenson/rbenv/blob/master/libexec/rbe... . It's short but there's a lot of features being used: set, shopt, IFS, functions, etc. If you're aiming for bash compatibility, that's your target!
In the meantime, I suggest changing the language to express that xonsh is bash-like, not bash-compatible. Otherwise users are going to be confused and disappointed.