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...
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 }]
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.
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? :)
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.
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.
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 ':'?
> 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 ':')?
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.
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?
