4 ms·

I'm a lead dev on the fish shell (http://fishshell.com http://fishshell.com) xonsh looks very cool. Shell scripting languages are famously obtuse and underpowe

I'm a lead dev on the fish shell (http://fishshell.com 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 /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/rbenv-hooks 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.

eddieplan9 12y ago
> 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. shameless plug, but I made a utility to solve the problem: https://github.com/edc/bass https://github.com/edc/bass So you can write `bass source /usr/local/bin/virtualenvwrapper.sh ';' mkvirtualenv env1`, which of course can be shortened with a function.
- CADBOT 12y ago
  I'm testing this out later this week... if it works... you're my new hero!
scopatz42 12y ago
Thanks for posting this @ridiculous_fish! I am the main author of xonsh, and I really appreciate fish. Its awesome and I am certainly going to borrow ideas :). I agree that making shell languages into 'real' languages is strong goal that we should all have. And like with real languages, many can co-exist happily. 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!
- geoelectric 12y ago
  FYI, I interpreted "BASH-wards compatible" as "BASH-compatible" as well. The subtlety seems a little lost on me.
- dragonwriter 12y ago
  "BASHwards" is a bad word to use for this, since the natural interpretation is that it is a combination of "backwards" and "BASH" meaning thatn xonsh is an "upgrade" that is backwards-compatible with BASH. It seems to be more intended to be not backward-compatible, but to have some attention to minimizing the pain of transition, which is valuable, but needs different language to communicate.
LukeShu 12y ago
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).
- ridiculous_fish 12y ago
  Whoops, you're right! Egg on my face.
danbmil99 12y ago
you two should get a room, and fail to emerge until you are ready to bless the world with one shell to rule them all (and in the darkness bind them)
ngoldbaum 12y ago
I'm pretty sure it said "BASHwards-compatible" when I submitted the story to HN, so I guess one of the admins changed the title.
pjmlp 12y ago
> Shell scripting languages are famously obtuse and underpowered, and we've thought about how to cleanly merge shell scripting with a real language. It was called REPL (Interlisp-D, Lisp Machine, Cedar, Oberon), Workspace (Smalltalk), but then UNIX won.
lmm 12y ago
> 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. I used tclsh for a while. IMO a shell language needs the "function arg1 arg2" function-application syntax to fit with the way programs are called. Fortunately that style seems to be getting more popular - Haskell does it and to a certain extent so does Scala.

eddieplan9 12y ago

> 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. shameless plug, but I made a utility to solve the problem: https://github.com/edc/bass https://github.com/edc/bass So you can write `bass source /usr/local/bin/virtualenvwrapper.sh ';' mkvirtualenv env1`, which of course can be shortened with a function.

CADBOT 12y ago
I'm testing this out later this week... if it works... you're my new hero!

scopatz42 12y ago

Thanks for posting this @ridiculous_fish! I am the main author of xonsh, and I really appreciate fish. Its awesome and I am certainly going to borrow ideas :). I agree that making shell languages into 'real' languages is strong goal that we should all have. And like with real languages, many can co-exist happily. 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!

geoelectric 12y ago
FYI, I interpreted "BASH-wards compatible" as "BASH-compatible" as well. The subtlety seems a little lost on me.
dragonwriter 12y ago
"BASHwards" is a bad word to use for this, since the natural interpretation is that it is a combination of "backwards" and "BASH" meaning thatn xonsh is an "upgrade" that is backwards-compatible with BASH. It seems to be more intended to be not backward-compatible, but to have some attention to minimizing the pain of transition, which is valuable, but needs different language to communicate.

LukeShu 12y ago

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).

ridiculous_fish 12y ago
Whoops, you're right! Egg on my face.

danbmil99 12y ago

you two should get a room, and fail to emerge until you are ready to bless the world with one shell to rule them all (and in the darkness bind them)

ngoldbaum 12y ago

I'm pretty sure it said "BASHwards-compatible" when I submitted the story to HN, so I guess one of the admins changed the title.

pjmlp 12y ago

> Shell scripting languages are famously obtuse and underpowered, and we've thought about how to cleanly merge shell scripting with a real language. It was called REPL (Interlisp-D, Lisp Machine, Cedar, Oberon), Workspace (Smalltalk), but then UNIX won.

lmm 12y ago

> 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. I used tclsh for a while. IMO a shell language needs the "function arg1 arg2" function-application syntax to fit with the way programs are called. Fortunately that style seems to be getting more popular - Haskell does it and to a certain extent so does Scala.