Interesting but I haven't seen any killer feature yet that makes me want to get accustomed to this shell. Command level completion for arguments has existed in zsh, aliases being a sort of dictionary is kind of interesting but not too useful (just some familiar syntactic sugar). Mutliline input isn't new, csh can do it, bash can do it, so can zsh. Admittedly the ability to duck type and evaluate numerical expressions with "let" is kind of nice but nothing too special. Regexes for globbing files might be a new one, certainly a useful one that I'd otherwise be writing special awk or python to handle.
But we use shells because of their ubiquity, not because of how nice scripting languages they are (they aren't). So I don't see myself ever using xonsh – I'm already glad when a system has bash and I don't have to figure out what "posix /bin/sh compliant" is supposed to mean this week.
I've longed for a language that can run both pipelines of commands with the conciseness of UNIX shells and have control structures and arithmetic as elegantly as Python...
TCL works nice as a shell and is very elegant as a programming language. The famous equivalence of code and data is visible here, while still syntactically looking pretty normal.
Scheme (via https://scsh.net/about/about.html) is also worth looking into. S-exp based syntax looks strange at first, but you get used to it rather quickly.
Emacs Eshell is very similar to xonsh, but with Emacs Lisp instead of Python.
On Windows PowerShell is also a choice. It's both a shell and a sane, procedural programming language, with full access to dotNET.
On the other hand, jq (https://stedolan.github.io/jq/) is just a DSL, but it turns out it's ok for doing more advanced work if you're familiar with functional programming.
Not to mention, almost every language with a REPL can be made into a shell/programming environment given enough library support. For example Python with IPython is a very decent shell and I think OCaml with utop could also be.
Not to get off on too much of a tangent, but you may be interested in concatenative programming languages. They’re a variety of stack-based programming languages with a functional flavour, in which the default style is a sort of data pipeline. For example, in Factor[1]:
! Just some imports.
USING: accessors smtp ;
! Create a new email object.
<email>
! That object is piped implicitly to these setter words.
! E.g., >>from: ( email new-address -- email )
"alice@example.com" >>from
{ "bob@example.com" } >>to
"Coffee?" >>subject
"You pick the time and place." >>body
! Pipe that object on to the “send-email” word.
send-email
Note how no local variables are necessary for simply plumbing data around—although of course you can use them if you want.
The weirdest thing is probably that arithmetic in most concatenative languages is written in postfix, which you may find off-putting. But it’s no worse than Lisp’s prefix notation, and has some other benefits.
Factor also has an excellent interactive environment; the whole thing feels like a Lispy Smalltalk.
Prefix/postfix/infix refer to the order in which you write operations and their operands—equivalently you can think of preorder/postorder/inorder traversals of the syntax tree.
AST +
/ \
* 5
/ \
2 3
Infix 2 * 3 + 5
2 times 3 plus 5.
Prefix + * 2 3 5
Lisp (+ (* 2 3) 5)
The sum of the product of 2 and 3, and 5.
Postfix 2 3 * 5 +
With 2 and 3, multiply. Then with 5, add.
You can do this with Tcl ! I wrote an extension called "pipethread" to make UNIX shell pipelining more natural. It uses threads instead of processes but otherwise operates pretty similarly.
Example: set lsOutput [pipethread::pipe exec ls | exec tac | foreach line { puts $outchan "[string length $line]:$line" } | { gets $inchan line; puts $outchan $line }]
For me, this is a shell that retains all the interactive command structures I know from sh (e.g. job control and redirection), and adds sane globbing and looping. As long as it retains familiarity with what I already know and use, it doesn't need a killer feature for me because switching costs are low.
To be fair, the flattering comparison table should come with things like "Natively supported by the OS" or "Large community support", for which xonsh would obviously be at a disadvantage compared to other shells.
While I have little basis for technical disagreement with your statement, I still think the attitude of "not used much - can't adopt it" is detrimental to FOSS in general and to high-touch "hand tools" such as shells in particular. How else will we discover new stuff if we won't venture out into the unknown? :)
But this all depends on the OS; OS X only gives you an old version of BASH as the default shell and OpenBSD (and possibly other BSDs) require installing BASH through the ports tree.
OSX also comes with zsh. I haven't looked in a while, but last time I checked, the version of zsh was significantly newer than the version of BASH, because of the GPL issues around Bash.
Totally agree that the comparison table is flattering. The purpose of the front page for a project is to make it look good. This is one of the few places a project has that opportunity. Happy to update it if you notice any thing wrong or would like to see additional rows or columns.
Looks good, but can you take more time in the asciinema showcase? The typed variables section for example goes so fast that I can barely read the results, never mind get into the process behind it!
I've made a lot of use of the pause button, but it would be great to just be given a little more time to think.
On the other hand - it's a fast homepage intro. A rapid showcase to get you interested and make you want to investigate further.
I also used the pause in a couple of places (which is OK, that's what it's there for), and I almost certainly wouldn't have bothered watching it if it had been any longer.
I personally think this is an excellent example of a landing page. It contains a brief text summary of what the thing is and why you'd want to use it, a quick demo of what it does, and then links to further information.
The domain at the end of the video (http://xonsh.org) doesn't seem to point to your site (http://xon.sh) (and doesn't work, either…). Just FYI, that if you share the video, you might want to share the link, too.
(or, for xon.sh, it may be time to update the video. I presumed you moved to the fancier domain at some point.)
I'm baffled with the effort people put for writing _g_ and not writing _it_. Now I'm incredibly fond of path completion, but I guess it shouldn't be the shell to do that, but the terminal, because the function is generic, i.e. whathever shell one uses, it is beneficial. Emacs/Comint does that, and it's comfortable and predictable.
> I guess it shouldn't be the shell to do that, but the terminal
How would this work over SSH? What if you're using a temporary shell as another user? Also, the terminal really shouldn't have to know what is going on in the shell in order to work reliably. Tools like tmux, screen… should not have to perform directory completion.
There can be a single pathcompd service that does ipc too. Or maybe that can be left to readline, etc. I don't see why a command interpreter should do line editing/path completion in and of itself.
I'm not really well-versed in what happens when you replace a shell and then run your programs with it, but can someone ELI5 how does this get away with making 'env variables typed'.
How is the program like 'ls' going to see a variable that is an array when originally it was a string delimited with ':'?
It will see a string delimited with ':'. The point is that while inside xonsh, your variable is typed, and then xonsh hands the env in the expected way to the subprocesses.
So basically it goes back to string from array by simply unconditionally joining it on a ':'? I guess that makes some sense... But isn't this convention (delimited by ':') only for PATH?
The convention holds for other lists too (usually lists of directories). The important thing is that there is a similar but different convention on Windows (';' is used), and xonsh abstracts that away in the same way Python does.
> How is the program like 'ls' going to see a variable that is an array when originally it was a string delimited with ':'?
There are two things here: the command 'ls' that you type on your shell and the executable named 'ls' located in "/bin/ls" (or wherever) which can list directories.
Most shells, when encounter a command X (say, 'ls') they see their 'context' to see if 'X' is defined. If yes, they will execute it. If not, they will assume that the X is an executable and try to execute it.
That's what happening here.
Yes, that I get. I was asking how is the translation from shell to inside of a program happen. On linux, I presume it's done via getenv(3), which means that it can only support strings. The post below says that it simply joins on a ':'. Is that safe for all or even most cases (except obviously PATH, which is delimited by ':')?
Looks really good, it's Yet Another Fantastic Shell!
I'd love to use it, really. But as long as it's not shipped by default with a popular Linux releases, I will not.
My customers, Telcos, don't approve any "non standard" software in their server rooms.
Personally, I just don't get what it solves that can't be solved with shells and programming languages pre-installed on every machine already. From a personal workstation/development box shell (I used GNU Emacs for dev/mail/usenet for over a decade), I can understand but for servers this may not be appropriate.
It is "cool" but I'd argue that most geeks don't even fully understand installed tools on their current machines, so this is "interesting" at best. It was someone's project to learn programming?
Interesting but I haven't seen any killer feature yet that makes me want to get accustomed to this shell. Command level completion for arguments has existed in zsh, aliases being a sort of dictionary is kind of interesting but not too useful (just some familiar syntactic sugar). Mutliline input isn't new, csh can do it, bash can do it, so can zsh. Admittedly the ability to duck type and evaluate numerical expressions with "let" is kind of nice but nothing too special. Regexes for globbing files might be a new one, certainly a useful one that I'd otherwise be writing special awk or python to handle.
> Regexes for globbing files might be a new one
Regexes in particular are new AFAIK, but zsh's extended globbing is already extremely powerful: http://www.refining-linux.org/archives/37/ZSH-Gem-2-Extended...
Bash also comes close, iirc.
But we use shells because of their ubiquity, not because of how nice scripting languages they are (they aren't). So I don't see myself ever using xonsh – I'm already glad when a system has bash and I don't have to figure out what "posix /bin/sh compliant" is supposed to mean this week.
I think the big plus is that you can use a proper programming language in the shell.
I've longed for a language that can run both pipelines of commands with the conciseness of UNIX shells and have control structures and arithmetic as elegantly as Python...
That language is Ruby.
Well, there are some other as well.
TCL works nice as a shell and is very elegant as a programming language. The famous equivalence of code and data is visible here, while still syntactically looking pretty normal.
Scheme (via https://scsh.net/about/about.html) is also worth looking into. S-exp based syntax looks strange at first, but you get used to it rather quickly.
Emacs Eshell is very similar to xonsh, but with Emacs Lisp instead of Python.
On Windows PowerShell is also a choice. It's both a shell and a sane, procedural programming language, with full access to dotNET.
Tulip (https://github.com/tulip-lang/tulip) express goals are to be good for both shell work and programming.
On the other hand, jq (https://stedolan.github.io/jq/) is just a DSL, but it turns out it's ok for doing more advanced work if you're familiar with functional programming.
Not to mention, almost every language with a REPL can be made into a shell/programming environment given enough library support. For example Python with IPython is a very decent shell and I think OCaml with utop could also be.
Not to get off on too much of a tangent, but you may be interested in concatenative programming languages. They’re a variety of stack-based programming languages with a functional flavour, in which the default style is a sort of data pipeline. For example, in Factor[1]:
Note how no local variables are necessary for simply plumbing data around—although of course you can use them if you want.
The weirdest thing is probably that arithmetic in most concatenative languages is written in postfix, which you may find off-putting. But it’s no worse than Lisp’s prefix notation, and has some other benefits.
Factor also has an excellent interactive environment; the whole thing feels like a Lispy Smalltalk.
[1]: http://factorcode.org/
>arithmetic in most concatenative languages is written in postfix
Postfix? I'm assuming a typo here but not sure what you meant.
Edit: Ah, I'm guessing it was supposed to be postscript. Makes more sense now.
Looks like an interesting language style though, I've been looking for a language that has the bash style piping baked into the language.
Prefix/postfix/infix refer to the order in which you write operations and their operands—equivalently you can think of preorder/postorder/inorder traversals of the syntax tree.
Ahh, understood now. I figured postscript as it's also a concatinative programming language.
I read postfix as in the mail server not as a synonym of suffix, thanks for the clarification.
> synonym of suffix
Antonym, actually. Prefixes are literally on the other end of things than suffixes are ;)
He's talking about postfix, not prefix. It's closer to being a synonym of suffic.
Oh shit, true. My mistake. Sorry!
You can do this with Tcl ! I wrote an extension called "pipethread" to make UNIX shell pipelining more natural. It uses threads instead of processes but otherwise operates pretty similarly.
Example: set lsOutput [pipethread::pipe exec ls | exec tac | foreach line { puts $outchan "[string length $line]:$line" } | { gets $inchan line; puts $outchan $line }]
Usage: https://chiselapp.com/user/rkeene/repository/pipethread/arti...
For me, this is a shell that retains all the interactive command structures I know from sh (e.g. job control and redirection), and adds sane globbing and looping. As long as it retains familiarity with what I already know and use, it doesn't need a killer feature for me because switching costs are low.
To be fair, the flattering comparison table should come with things like "Natively supported by the OS" or "Large community support", for which xonsh would obviously be at a disadvantage compared to other shells.
While I have little basis for technical disagreement with your statement, I still think the attitude of "not used much - can't adopt it" is detrimental to FOSS in general and to high-touch "hand tools" such as shells in particular. How else will we discover new stuff if we won't venture out into the unknown? :)
I agree completely, I'm just saying it's a factor that should be considered, like many others, when making a comparisons with other shells.
Python doesn't have large community support?
> "Natively supported by the OS"
But this all depends on the OS; OS X only gives you an old version of BASH as the default shell and OpenBSD (and possibly other BSDs) require installing BASH through the ports tree.
OSX also comes with zsh. I haven't looked in a while, but last time I checked, the version of zsh was significantly newer than the version of BASH, because of the GPL issues around Bash.
Totally agree that the comparison table is flattering. The purpose of the front page for a project is to make it look good. This is one of the few places a project has that opportunity. Happy to update it if you notice any thing wrong or would like to see additional rows or columns.
Zsh has a plugin for syntax highlighting: https://github.com/zsh-users/zsh-syntax-highlighting
Personally, I think fish is at least as much of a pun as plumbum.
The comparison table however demonstrates its bias accurately, with metrics like "pun in name".
Its there for humor, not a serious comparison tool. And I can respect that.
Beautiful. Absolutely beautiful.
Also nice to see it respects XDG basedir.
I'll be trying it out today. I've been using zsh for a very, very long time and it's been really hard to get me to switch off it. This looks exciting.
My only concern is with ease of installation, especially on eg. debian servers. But that's out of the hands of the project :/
Ditto. Using backticks for Python regex globbing is immediately appealing.
Looks good, but can you take more time in the asciinema showcase? The typed variables section for example goes so fast that I can barely read the results, never mind get into the process behind it!
I've made a lot of use of the pause button, but it would be great to just be given a little more time to think.
On the other hand - it's a fast homepage intro. A rapid showcase to get you interested and make you want to investigate further.
I also used the pause in a couple of places (which is OK, that's what it's there for), and I almost certainly wouldn't have bothered watching it if it had been any longer.
I personally think this is an excellent example of a landing page. It contains a brief text summary of what the thing is and why you'd want to use it, a quick demo of what it does, and then links to further information.
> On the other hand - it's a fast homepage intro. A rapid showcase to get you interested and make you want to investigate further.
But does it work? Here was what happened for me:
- The first section disappeared too fast.
- I thought that was odd and waited for the second section.
- The second section disappeared too fast.
- I closed the tab.
The domain at the end of the video (http://xonsh.org) doesn't seem to point to your site (http://xon.sh) (and doesn't work, either…). Just FYI, that if you share the video, you might want to share the link, too.
(or, for xon.sh, it may be time to update the video. I presumed you moved to the fancier domain at some point.)
The xonsh Xontrib [1] open pull request sounds handy, allowing devs to extend the functionality of xonsh beyond what is provided by default.
As an example, gitsome [2] is powered by xonsh and might have benefitted from Xontrib.
I've found that xonsh + prompt-toolkit [3] is a nice combo that helps autocomplete the following:
* Shell commands
* Files and directories
* Environment variables
* Man pages
* Python (REPL too)
[1]: https://github.com/scopatz/xonsh/pull/829
[2]: https://github.com/donnemartin/gitsome
[3]: https://github.com/jonathanslenders/python-prompt-toolkit
Earlier discussion: https://news.ycombinator.com/item?id=9207738
The feature set is very interesting, but I tried it out on my machine, and it's just too slow for me. I'm sticking with ZSH.
I'm baffled with the effort people put for writing _g_ and not writing _it_. Now I'm incredibly fond of path completion, but I guess it shouldn't be the shell to do that, but the terminal, because the function is generic, i.e. whathever shell one uses, it is beneficial. Emacs/Comint does that, and it's comfortable and predictable.
> I guess it shouldn't be the shell to do that, but the terminal
How would this work over SSH? What if you're using a temporary shell as another user? Also, the terminal really shouldn't have to know what is going on in the shell in order to work reliably. Tools like tmux, screen… should not have to perform directory completion.
There can be a single pathcompd service that does ipc too. Or maybe that can be left to readline, etc. I don't see why a command interpreter should do line editing/path completion in and of itself.
I'm not really well-versed in what happens when you replace a shell and then run your programs with it, but can someone ELI5 how does this get away with making 'env variables typed'.
How is the program like 'ls' going to see a variable that is an array when originally it was a string delimited with ':'?
It will see a string delimited with ':'. The point is that while inside xonsh, your variable is typed, and then xonsh hands the env in the expected way to the subprocesses.
So basically it goes back to string from array by simply unconditionally joining it on a ':'? I guess that makes some sense... But isn't this convention (delimited by ':') only for PATH?
Most path arrays are :-concatenated on unixes (RPATH, LD_PRELOAD, etc...), so the convention holds for the majority case.
There might be a way to specify the serialization of your array somewhere, but I can't find it in the doc.
https://docs.python.org/2/library/os.html#os.pathsep
The convention holds for other lists too (usually lists of directories). The important thing is that there is a similar but different convention on Windows (';' is used), and xonsh abstracts that away in the same way Python does.
> How is the program like 'ls' going to see a variable that is an array when originally it was a string delimited with ':'?
There are two things here: the command 'ls' that you type on your shell and the executable named 'ls' located in "/bin/ls" (or wherever) which can list directories. Most shells, when encounter a command X (say, 'ls') they see their 'context' to see if 'X' is defined. If yes, they will execute it. If not, they will assume that the X is an executable and try to execute it. That's what happening here.
Perhaps the following silly script helps?
HTH
Yes, that I get. I was asking how is the translation from shell to inside of a program happen. On linux, I presume it's done via getenv(3), which means that it can only support strings. The post below says that it simply joins on a ':'. Is that safe for all or even most cases (except obviously PATH, which is delimited by ':')?
Looks really good, it's Yet Another Fantastic Shell!
I'd love to use it, really. But as long as it's not shipped by default with a popular Linux releases, I will not. My customers, Telcos, don't approve any "non standard" software in their server rooms.
Sounds very useful. I'll give this a try right now on my personal machine and maybe even use it for some build scripts at work later if I like it.
That's lovely! Would really love some docs on how developers can extend this!
Am I missing something to enable smart autocomplete?
$ git c<tab> completes to a folder, starting with c.
$ git cl<tab> does nothing.
(OS X, installed with pip.)
I have this for starters: https://gist.github.com/BYK/66dfd985491b483bd140
It is nice to have new projects in the world.
Personally, I just don't get what it solves that can't be solved with shells and programming languages pre-installed on every machine already. From a personal workstation/development box shell (I used GNU Emacs for dev/mail/usenet for over a decade), I can understand but for servers this may not be appropriate.
It is "cool" but I'd argue that most geeks don't even fully understand installed tools on their current machines, so this is "interesting" at best. It was someone's project to learn programming?
I may be being negative, but "meh".
Looks very useful, I think it's time to replace my zsh.
How does this compare to cmder on Windows?
Not at all, they're completely different things.