21–30 of 63 posts
I genuinely wish there was an alternative that could gain enough traction to reach critical mass and hopefully start shipping with operating systems. I've never bothered to learn bash because it was always so damned confusing, and I just couldn't get over the idiosyncrasies when playing around with it. I wouldn't mind putting in time to learn something new and actually user-friendly.
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 ]
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
*
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.
Is there a way to switch explicitly between Python and Bash mode? The "ls -l" example makes me pretty worried that this could mess up basic bash scripts that already work just by defining a variable like "ls" and forgetting about it, or forgetting where it's defined. It's a great idea, but there's a lot of room for stuff breaking that worries me.
You can use an uncaptured subprocess to run a command explicitly in bash mode. I'm unsure how you think xonsh would break a bash script, though. When you run a script in xonsh it's still going to be interpreted by whatever is declared in the script's shebang. Just like you can run a perl script from bash, you can run a bash script from xonsh. E.G. $ ls='foo' $ cat test.sh #!/bin/bash ls ~ $ print(ls) foo $ ./test.sh…
I'm a lead dev on the fish shell ( http://fishshell.com ) 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…
I'd like to point out though, that the goal is not to have bash-compatibility. As you point out, bash does some insane things and that is exactly what I want to avoid with xonsh. I should be able to give xonsh to a programming newbie and they should not experience any gotchas once they know the language.
I have been pretty careful to say BASHwards-compatibility in the docs and elsewhere, for exactly the reasons you mention. The goal isn't to be bash with some python-isms, but to be python with the useful parts of the shell syntax. Like any good technology, it should interface as well as it can (ie when not insane to do so) with the previous technologies. For example, read in the bashrc or take advantage of the bash completion functionality. That is what BASHwards was meant to mean. @ngoldbaum seems to have submitted the link here, under 'bash-compatibility.' Oh well. This probably is proof enough that I should change the 'BASHwards' language elsewhere. Thanks for the tip.
Keep doing great things with fish!
curl -O https://raw.githubusercontent.com/pypa/pip/master/contrib/ge...
sudo python3.4 get-pip.py
sudo mv /usr/local/bin/pip /usr/local/bin/pip3 # optional, adjust line below if ommited
sudo pip3 install xonsh
------
then:
chsh -s /usr/local/bin/xonsh
EDIT: Just realized I forgot a step. You have to edit /etc/shells to add /usr/local/bin/xonsh to change your shell to it using chsh.
I genuinely wish there was an alternative that could gain enough traction to reach critical mass and hopefully start shipping with operating systems. I've never bothered to learn bash because it was always so damned confusing, and I just couldn't get over the idiosyncrasies when playing around with it. I wouldn't mind putting in time to learn something new and actually user-friendly.
Have you looked at fish? It is in the package repositories everywhere, I think.
I'm a lead dev on the fish shell ( http://fishshell.com ) 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…
echo foo | cd /
cd / | echo foo
In bash, only the second line will change your working
directory.
I'm a lead dev on the fish shell ( http://fishshell.com ) 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…
I'm a lead dev on the fish shell ( http://fishshell.com ) 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…
echo foo | cd / cd / | echo foo In bash, only the second line will change your working directory. Um... in Bash, neither of those change your working directory (unless `shopt -s lastpipe` is set, in which case: the first does).