XonSH has been my main shell for a solid two years now. The concept is awesome, but unfortunately it has many flaws.
* Nesting bash and python scripts makes performance terrible compared to using python's subprocess module directly. I have a xonsh script at [0], with an equivalent written in straight bash. The python scripts ends in less than a second, the xonsh script takes ages.
- As a sub-problem of the above: You can't ctrl+c while in a python function in xonsh. That stinks.
* $(program) returns a string that ends with a \n. In bash, when the program returns a single line, the \n gets stripped.
* It sometimes has problems with certain interactive programs. My last experience with this was sudoedit starting neovim in xonsh caused neovim to crash. XonSH -> Neovim works. Bash -> Sudoedit -> neovim works. but Xonsh -> Sudoedit -> Neovim doesn't.
And that's just a small list of my biggest gripes that I keep running into. I really hope to see the project improve though! Despite all the bugs, it's still my favorite shell by a mile.
I use zsh daily but type `xonsh` any time I do something in the shell that would normally require a google.
“Uh ok so I have this JSON file. When I pipe this to `jq` I forget: to pivot an array of objects to an object keyed by array[x].id is it like `to_entries` then chain it to `map`? Uhh let’s look at the docs...”
However in Python I can write that function at the speed of thought. It may be a couple more lines of code but I’m also 100% confident in the output.
Like I understand some people can legitimately program in bash [0]. But I just can’t bring myself to practice. Why would anyone inflict this language on themselves?
bummer
ctrl+c does eventually work several seconds later (about 10x slower) which is still a deal breaker as it could be disastrous when you need to abort a mistyped command or for scripts that give you a few seconds to abort before it does something the destructive step...
Sounds neat. However, the fact that `ls -l` either subtracts two numbers or calls a shell command, depending on whether there exist valriables 'ls' and 'l' in the Pythom environment, looks like a security nightmare waiting to happen. What if I create a python object 'ls' deep inside a script that does Evil when subtracted from?
Python variables are scoped as normal, so the security story for xonsh is the same as for Python. We are always open to suggestions and PRs to harden the code base as needed.
Sometimes I wonder which languages people use for system tools. I mean, it is hard enough that C programs (with dynamic linking) break sometimes, but building a shell on top of Python seems like a particualar bad choice to me (similar to building a package manager with python).
In my opinion, such few-dependency, high-importance tools should linked statically.
I think that anyone who is trying to imagine "the next shell" owes it to themselves to try PowerShell.
It's .NET based and very, very different from the sh lineage, but I absolutely love its ability to use objects instead of strings as the underlying transmission medium between "processes". E.g. ls gives you file descriptors, ps gives you process descriptors, etc.
> building a shell on top of Python seems like a particualar bad choice to me
can you say why? Python's stdlib handles a lot of cross-platforminess, Python is mostly easy to write, and is available as or more easily than a C compiler on many platforms.
So I just tried it and it's surprisingly usable (I am always somehow skeptical about non-Bash shells). It even takes into account my ~/.inputrc, so kudos.
However, I struggled a little bit with
$ time ls
where the output of `time` is mangled in-between the output of `ls` - this may be related to STDOUT and STDERR buffering?
I've always been thinking there can be a better shell like having a split pane to show the list of command options with descriptions as you start typing in the command or show snippets of a preset of command options that does task X as in search by use case instead of going to stackoverflow every time.
I think the way people handle shell, as in typing commands on a dumb shell, has not improved for decades and I don't know why. The only thing they help without explicitly asking is with autocompletion.
I really like fish. It doesn't open a split pane, but it can show lists of command switches in tab complete based on man pages.
I'm really tempted to try xnosh again as my daily driver for a few weeks though. I like the idea of typing out arbitrary Python code without spawning up IPython.
The problems people seem to be stating about xonsh were similar to a lot of the early bugs with Fish, but those things tend to go away once more people start using the shell and reporting issues.
I hope we got a whole new generation of usable shells with xonsh, oil and fish.
ehh.. I keep wanting to call it "nosh" or spell it "xnosh" but I'm sure if it catches on people will remember. Plus it's easy to use with a search engine, unlike "Go" or "Rust."
I will say I prefer names that can be searched for on their own (e.g. with Go people typically search for "Go lang").
And as much as I love Void Linux, it's better named than all the xbps-* package manager commands.
Note, while you should feel free to use any interactive shell you like, you should only write scripts with POSIX sh. A friend of mine is working on another shell, mrsh, which aims to be POSIX-sh-as-a-library and will serve as the basis for building more sophisticated interactive shells on a POSIX base, if anyone is interested in that:
I have a better idea: don't write scripts in shell language at all. They're terrible at basically everything. Instead, use a scripting language, like Python, Ruby, or Perl. They have control flow that make sense, are not riddled with subtle bugs due to legacy and compatibility reasons, and are simply easier to wield.
Shell scripts are a maintenance nightmare - even when used for personal scripts. They should be avoided at all cost.
While that's true for portability (there's obviously reasons why nearly all distros ship with a POSIX sh compatible shell at /bin/sh), for simple tasks on my own system, oftentimes I simply want to get the job done without banging my head against a wall dealing with all the idiosyncrasies of sh. For internal use, I think this project excels for automation and administration tasks. Of course, I probably wouldn't ship anything written in xonsh-python, but I'd totally use it to, say, back up my dotfiles to a git repo automatically.
Sounds amazing. If it ever gets a relatively active plugin ecosystem like zsh or fish, I'd definitely switch. Being able to write shell functions in Python would be very refreshing.
If they want bigger adoption, dedicating a bunch of people who do nothing but port zsh and fish plugins would probably go a long way.
Since the start of the project there has been a desire to point out that most things that work in Bash also work in Xonsh.
The motto started out as "BASHwards-compatible", but that was unsatisfactory because on one hand it sounds like nonsense, and on the other hand, it's not actually compatible with Bash. So that devolved over time into what we have now.
Awesome that it uses repl.it embed. But leaves so much to be desired. I'm the repl.it ceo and have a few things in the works to make this experience so much better:
1. caching pypi installs between instances
2. using a real terminal emulator which means you'll get to use xon.sh (or any shell) in it's full glory
Still a nice surprise to see repl.it embedded in the wild.
Xonsh is awesome! Execute Python directly on the command line?! Sign me up!
Sadly it doesn't play well with all of my three thousand various vim plugins, so I still haven't been able to use it as my daily shell. Hopefully someday!
Can you please open an issue detailing the problem? https://github.com/xonsh/xonsh/issues I'd love to help make this work. I believe that the emacs folks have something that works for them
Anybody switched from fish shell to this? What is your experience? I like fish shell because the preconfiguration is pretty good. Same on xon.sh or config hell like zsh?
Ugh. I have so many conflicting opinions on this question.
So, Xonsh is superior in the manipulation of shell objects. I felt super at home changing the shell prompt and configuring/extending the default Xonsh functionality. This is all because it's literally a superset of Python.
Fish however, blows Xonsh out of the water when it comes to autocomplete and navigation. Xonsh's autocomplete / suggestions are very very weak in comparison to fish's. You feel bogged down when trying to navigate directories quickly with Xonsh. I wrote a small blog post about it here [0]
There was a piece of software I was trying to write that was meant to be Xonsh but with Fish's autocomplete [1], but really didn't succeed and have slightly abandoned it for the time being. But maybe I'll pick it back up soon.
[+] [-] roblabla|7 years ago|reply
* Nesting bash and python scripts makes performance terrible compared to using python's subprocess module directly. I have a xonsh script at [0], with an equivalent written in straight bash. The python scripts ends in less than a second, the xonsh script takes ages.
* $(program) returns a string that ends with a \n. In bash, when the program returns a single line, the \n gets stripped.* It sometimes has problems with certain interactive programs. My last experience with this was sudoedit starting neovim in xonsh caused neovim to crash. XonSH -> Neovim works. Bash -> Sudoedit -> neovim works. but Xonsh -> Sudoedit -> Neovim doesn't.
And that's just a small list of my biggest gripes that I keep running into. I really hope to see the project improve though! Despite all the bugs, it's still my favorite shell by a mile.
[0] https://gist.github.com/roblabla/d82c440908d08c8a232ac483e6b...
[+] [-] austinpray|7 years ago|reply
“Uh ok so I have this JSON file. When I pipe this to `jq` I forget: to pivot an array of objects to an object keyed by array[x].id is it like `to_entries` then chain it to `map`? Uhh let’s look at the docs...”
However in Python I can write that function at the speed of thought. It may be a couple more lines of code but I’m also 100% confident in the output.
Like I understand some people can legitimately program in bash [0]. But I just can’t bring myself to practice. Why would anyone inflict this language on themselves?
[0] https://github.com/docker-library/python/blob/master/update....
[+] [-] jijojv|7 years ago|reply
$ yes test | tee /tmp/xonsh.log
$ wc -l /tmp/xonsh.log
bummer ctrl+c does eventually work several seconds later (about 10x slower) which is still a deal breaker as it could be disastrous when you need to abort a mistyped command or for scripts that give you a few seconds to abort before it does something the destructive step...[+] [-] ilyagr|7 years ago|reply
[+] [-] scopatz|7 years ago|reply
[+] [-] bitwize|7 years ago|reply
[+] [-] Norther|7 years ago|reply
[+] [-] daveFNbuck|7 years ago|reply
[+] [-] m45t3r|7 years ago|reply
[+] [-] JepZ|7 years ago|reply
In my opinion, such few-dependency, high-importance tools should linked statically.
[+] [-] munchbunny|7 years ago|reply
It's .NET based and very, very different from the sh lineage, but I absolutely love its ability to use objects instead of strings as the underlying transmission medium between "processes". E.g. ls gives you file descriptors, ps gives you process descriptors, etc.
[+] [-] marmaduke|7 years ago|reply
can you say why? Python's stdlib handles a lot of cross-platforminess, Python is mostly easy to write, and is available as or more easily than a C compiler on many platforms.
[+] [-] insertnickname|7 years ago|reply
https://github.com/gentoo/portage/
[+] [-] pyedpiper|7 years ago|reply
it's the shell I always wanted. And cross platform to boot.
Alias ls -l?
aliases['ls'] = "ls -l"
Oops no I don't want that any more:
del aliases['ls']
Add dir to path:
$PATH.append('/foo/bar')
Just the awesome python syntax sugar and readbility right in the
May I never right a bash script again.
[+] [-] Cyph0n|7 years ago|reply
Bash is not going away any time soon, for better or worse..
[+] [-] stochastic_monk|7 years ago|reply
[+] [-] protomikron|7 years ago|reply
However, I struggled a little bit with
$ time ls
where the output of `time` is mangled in-between the output of `ls` - this may be related to STDOUT and STDERR buffering?
[+] [-] h1d|7 years ago|reply
I think the way people handle shell, as in typing commands on a dumb shell, has not improved for decades and I don't know why. The only thing they help without explicitly asking is with autocompletion.
[+] [-] djsumdog|7 years ago|reply
I'm really tempted to try xnosh again as my daily driver for a few weeks though. I like the idea of typing out arbitrary Python code without spawning up IPython.
The problems people seem to be stating about xonsh were similar to a lot of the early bugs with Fish, but those things tend to go away once more people start using the shell and reporting issues.
I hope we got a whole new generation of usable shells with xonsh, oil and fish.
[+] [-] vdm|7 years ago|reply
https://github.com/mhayashi1120/Emacs-shelldoc
[+] [-] pen2l|7 years ago|reply
Except the damned name. Come on guys, there are already enough crazily named things out there, you didn't have to be another one :(
[+] [-] djsumdog|7 years ago|reply
I will say I prefer names that can be searched for on their own (e.g. with Go people typically search for "Go lang").
And as much as I love Void Linux, it's better named than all the xbps-* package manager commands.
[+] [-] programmarchy|7 years ago|reply
[+] [-] sciurus|7 years ago|reply
[+] [-] devnonymous|7 years ago|reply
[+] [-] sctb|7 years ago|reply
[+] [-] Sir_Cmpwn|7 years ago|reply
https://git.sr.ht/~emersion/mrsh
[+] [-] roblabla|7 years ago|reply
Shell scripts are a maintenance nightmare - even when used for personal scripts. They should be avoided at all cost.
[+] [-] joshumax|7 years ago|reply
[+] [-] meowface|7 years ago|reply
If they want bigger adoption, dedicating a bunch of people who do nothing but port zsh and fish plugins would probably go a long way.
[+] [-] scopatz|7 years ago|reply
[+] [-] BeetleB|7 years ago|reply
[+] [-] baddash|7 years ago|reply
[+] [-] BlaXpirit|7 years ago|reply
The motto started out as "BASHwards-compatible", but that was unsatisfactory because on one hand it sounds like nonsense, and on the other hand, it's not actually compatible with Bash. So that devolved over time into what we have now.
https://github.com/xonsh/xonsh/blame/ebd4e597a3cf063b124e5a5... https://github.com/xonsh/xonsh/blame/82cac3fff08b5cc26e421f1... https://github.com/xonsh/xonsh/blame/bd964ce552282334c881181...
[+] [-] hathawsh|7 years ago|reply
[+] [-] h1d|7 years ago|reply
[+] [-] amasad|7 years ago|reply
1. caching pypi installs between instances 2. using a real terminal emulator which means you'll get to use xon.sh (or any shell) in it's full glory
Still a nice surprise to see repl.it embedded in the wild.
[+] [-] fiatjaf|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] di|7 years ago|reply
Sadly it doesn't play well with all of my three thousand various vim plugins, so I still haven't been able to use it as my daily shell. Hopefully someday!
[+] [-] scopatz|7 years ago|reply
[+] [-] devnonymous|7 years ago|reply
[+] [-] mlevental|7 years ago|reply
[+] [-] j2kun|7 years ago|reply
[+] [-] xiaq|7 years ago|reply
[+] [-] therealmarv|7 years ago|reply
[+] [-] anreekoh|7 years ago|reply
So, Xonsh is superior in the manipulation of shell objects. I felt super at home changing the shell prompt and configuring/extending the default Xonsh functionality. This is all because it's literally a superset of Python.
Fish however, blows Xonsh out of the water when it comes to autocomplete and navigation. Xonsh's autocomplete / suggestions are very very weak in comparison to fish's. You feel bogged down when trying to navigate directories quickly with Xonsh. I wrote a small blog post about it here [0]
There was a piece of software I was trying to write that was meant to be Xonsh but with Fish's autocomplete [1], but really didn't succeed and have slightly abandoned it for the time being. But maybe I'll pick it back up soon.
[0] https://ezb.io/thoughts/programming/mollusk/mollusk_1.html
[1] https://github.com/enricozb/mollusk
[+] [-] brazzledazzle|7 years ago|reply