It’s a cool shell. I used it for a half a year. And then it started crashing on me every ten minutes or so. That’s when I came to appreciate how important the stability of such a tool is.
I prefer sticking with bash where necessary (where a script is the only thing that will reasonably work), and elsewhere using a programming language with testing, type checking, modularity, and compilation into something with zero or minimal runtime dependencies.
I use zsh on my work and personal computers. I'm not ssh'ing into boxen these days. But when I do, I'm not doing anything more than reading logs to figure out why the userdata on an EC2 didn't work as expected.
I try to use posix standards when convenient, but I'll switch to bash at the first sign of posix complexity.
Xonsh seems like I'd have to type a lot more than I do with zsh. I would also be concerned about not being able to give my team members the same command I used without forcing them into a non-standard shell.
I don't use fish because I've only met one other person IRL who used it. Everyone I've worked with has use bash, zsh, or ksh (I'm glad I left the ksh company before they had to rewrite all those ksh scripts).
Also, Bash is staying for now. posix will most likely always work for the foreseeable future. Zsh seems to be the new Bash, but I have yet to see anyone put zsh in a shebang at work.
I recently (i.e., yesterday) migrated my 15+ year old bash config to zsh. zsh has some great quality of life improvements compared to bash and is basically 1-1 compatible. I had to spend about an hour migrating my prompt, but other than that it was a smooth transition.
zsh is now the default shell in macOS, so I'd say it's a safe bet if that's what you work with.
Learn the new tools. I’m working on my own machine 99% of the time, and if I’m on a remote machine, there’s a 90% chance I’m running something automated there. I’m not going to handcuff myself to the baseline for the sake of that .1%.
There’s no way I’d go back from Fish to Zsh or Bash on my daily driver. It’s just too pleasant to give up just because of “what if?”.
The big problem is that bash is more or less portable (almost everything has bash in the box). They need to start convincing distros to include and/or default xonsh, to really make it worthwhile.
If you're new and still trying to get into the industry, try all the new tools. Drive them hard and try to break them, so that you can find bug fixes you can contribute. Just go nuts, and let yourself steadily build up a backlog of unique, public, referencable commits you can show employers.
Once you're already established and comfortable, it's up to you if you want to keep trying the new flavor of the week. People gravitate towards novelty at different parts of the stack: Some people love running FreeBSD or Alpine, but stick to Bash on top of those; others, like me, try to stick with Ubuntu whenever possible, and mess around with things like shells and tiling window managers. Others even return to Windowsland and instead focus all of their efforts on innovating at the highest levels of what they can do with C# and actually making money with an innovative business model.
But you'll never learn where you don't enjoy the thrill of seeing something new break on you if you don't have that initial "question everything" phase.
Personally I'd prefer to have to learn no shells at all, but since that's not possible I'll stick with the one that's most commonly installed, which is bash. Similar feeling with an editor - vanilla vi instead of learning and depending on a slew of fragile extensions that only work on a personal laptop. If the challengers supplant the defaults on servers in these domains at some point, I'll learn them then.
I've been using xonsh since 2018 - on both Windows and Linux. I love it. It's not as responsive as a C based shell (e.g. Bash), but you get over it and the pros heavily outweigh the cons.
If you love Bash scripting, xonsh isn't for you. For everyone else, xonsh is.
The only serious headache I have with it - very poor compatibility with fzf. None of the main developers use fzf so they don't feel the pain. As an example, doing:
git checkout $(git branch | fzf)
doesn't work because the result of the fzf command has a newline. So you need something like @$(...).
What I really want is to swap the default TAB autocompletion with an fzf selection, and there's no easy way to do it. You have to get deep into the underlying prompt_toolkit library and do a lot of surgery. It's doable, but I haven't had the time.
> xonsh is Bash-wards compatible in the ways that matter, such as for running commands, reading in the Bash environment, and utilizing Bash tab completion
What does in the ways that matter mean? It would matter to me that it is 100% Bash compatible, else I won't use another shell in addition to `zsh`.
why not just run interactive python when you need it?
A shell should be interoperable between users. If everyone on your team uses xonsh, then great, by all means. Otherwise, you're in your own little esoteric world.
a shell has to be stable, a python environment is not. There is just too many ways a python package can break. If python had a good package system perhaps it'd bring something to the table.. but python is by far the winner of the programming language with the worst packaging ecosystem i've seen and used.
Do those more object oriented shells expose more substitution and streaming goodies? For example do they have process substitution - i.e. <(foo | bar)? Or do they use memfd instead of temporary files on Linux? Do they have first class fd, processes and pipelines manipulation?
For example the thing that turned me completely off PowerShell is that its pipelines are sequential not parallel. I use shell a lot, because it has streaming built-in. Many (also standard) libraries do not work around streaming, which I find is the reason why they often crumble when there is more data. For example Python's ZipFile or TarFile work around listing members should have been iterators.
Python has issues with dependency management. I don’t know that having your shell be based on Python is such a great idea as you could easily get yourself to weird situations.
That's a weird take given bash doesn't have _any_ dependency management. At least with XonSH you get something? Also, I'm not sure what issues you're hinting at - my experience with python dep management is that, although the tooling is terrible, the core import system works fine.
To move from the abstract to the concrete: I've been using it for almost 6 years and this has not been a problem.
OK. I lied. Since I installed xonsh and its dependencies in my user directory and not system wide, every time I upgrade my Python to a new major version I have to reinstall xonsh. Usually just one command will do it.
What I really want is all the shell commands to have an object (e.g. json) output mode. Then all my "glue" between tools becomes less bespoke and more standardized, e.g. jq. Instead of analyzing output to build weird grep and awk statements, I would just need to remember a couple of jq patterns, take a quick look at the output, and use one of my patterns to extract the data to stream to the next command.
https://github.com/kellyjonbrazil/jc - "CLI tool and python library that converts the output of popular command-line tools, file-types, and common strings to JSON, YAML, or Dictionaries. This allows piping of output to tools like jq and simplifying automation scripts."
I have a recurring nightmare where web developers create a one world government where they enforce a law requiring all data be converted to JSON before transmission. Existing network protocols are replaced with JSON-compatible versions, and specialized JSON parsing ASICs become a necessity in network devices. The nightmare ends with the collapse of civilization.
I use xonsh. Doing simple math on the command line reminds me of my QNX days back in the 80's. And being able to do python on the commandline is awesome.
Also, the rc file is way easier to read and manage.
I don't know why they advertise as being like bash. It's absolutely not like bash except that their default prompts look similar on the command line. The similarities pretty much end there.
Xonsh by itself is pretty cool and I hope it continues to grow.
However, I feel like Xonsh needs a killer app to really demonstrate the advantages of the semantics Xonsh provides. Maybe something like Rawdog (https://github.com/AbanteAI/rawdog) + Xonsh?
Interesting. I've been mulling around in my head a shell which embeds a Lisp. Well aware the idea isn't particularly ground breaking but I do love the idea of better languages embedded right within the shell, but not quite a REPL for that language.
I use xonsh as a shell for few years but I think I will go back to another shell as I am too frustrated with incombatibilities. That's being said, my xonsh scripts are there to stay, I still think that's an excellent way to build scripts.
I hate to say it, but I've completely stopped using Xonsh (which I adore) since ChatGPT-4 (whom I also adore) came out. Xonsh lowered the friction and cognitive load to get some jobs done in an elegant or at least sufficiently rapid way for me, and I am grateful. I can still see LLMs, many of which are benefactors of significant RLHF of the two parent languages, making great use of such a tool - especially paired with a nix-style approach to handling dependencies and environments.
Check out marcel (https://marceltheshell.org). It's yet another pipe-objects-instead-of-strings shell (like nushell). Unlike nushell, you pipe Python values. Marcel has no sublanguages (like awk, sed, ...). Instead, when logic is needed, you write Python code, delimited by parens. So:
(USER)
prints the value of the USER environment variable.
(f'Hello {USER}')
evaluates the expression inside the parens and prints "Hello jao" (for me).
ls | select (f: time.time() - f.mtime < days(2))
ls finds files in the current directory, pipes them to select, which keeps the files that were modified in the last two days (days is a builtin function).
[+] [-] marktucker|2 years ago|reply
[+] [-] overbytecode|2 years ago|reply
I like Xonsh, it’s pretty nice to work with, but it makes going back to Bash, when I have to, even more painful.
[+] [-] eviks|2 years ago|reply
[+] [-] aphexairlines|2 years ago|reply
I prefer sticking with bash where necessary (where a script is the only thing that will reasonably work), and elsewhere using a programming language with testing, type checking, modularity, and compilation into something with zero or minimal runtime dependencies.
[+] [-] therealfiona|2 years ago|reply
I try to use posix standards when convenient, but I'll switch to bash at the first sign of posix complexity.
Xonsh seems like I'd have to type a lot more than I do with zsh. I would also be concerned about not being able to give my team members the same command I used without forcing them into a non-standard shell.
I don't use fish because I've only met one other person IRL who used it. Everyone I've worked with has use bash, zsh, or ksh (I'm glad I left the ksh company before they had to rewrite all those ksh scripts).
Also, Bash is staying for now. posix will most likely always work for the foreseeable future. Zsh seems to be the new Bash, but I have yet to see anyone put zsh in a shebang at work.
[+] [-] theli0nheart|2 years ago|reply
zsh is now the default shell in macOS, so I'd say it's a safe bet if that's what you work with.
[+] [-] kstrauser|2 years ago|reply
There’s no way I’d go back from Fish to Zsh or Bash on my daily driver. It’s just too pleasant to give up just because of “what if?”.
[+] [-] efitz|2 years ago|reply
The big problem is that bash is more or less portable (almost everything has bash in the box). They need to start convincing distros to include and/or default xonsh, to really make it worthwhile.
[+] [-] hiAndrewQuinn|2 years ago|reply
Once you're already established and comfortable, it's up to you if you want to keep trying the new flavor of the week. People gravitate towards novelty at different parts of the stack: Some people love running FreeBSD or Alpine, but stick to Bash on top of those; others, like me, try to stick with Ubuntu whenever possible, and mess around with things like shells and tiling window managers. Others even return to Windowsland and instead focus all of their efforts on innovating at the highest levels of what they can do with C# and actually making money with an innovative business model.
But you'll never learn where you don't enjoy the thrill of seeing something new break on you if you don't have that initial "question everything" phase.
[+] [-] stcroixx|2 years ago|reply
[+] [-] int_19h|2 years ago|reply
[+] [-] pxc|2 years ago|reply
If I want it on a server I'm using, I (*gasp!*) just install it.
(I still write Bash sometimes and that's not really a problem, either.)
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] jerpint|2 years ago|reply
[+] [-] unrealhoang|2 years ago|reply
whenever I have some task to deal with data manipulation, i.e. fetch a json, map/filter/reduce on it, save it as some format, I reach for nushell.
If it's just process management or day to day trigger of command in a folder, I use zsh.
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] BeetleB|2 years ago|reply
If you love Bash scripting, xonsh isn't for you. For everyone else, xonsh is.
The only serious headache I have with it - very poor compatibility with fzf. None of the main developers use fzf so they don't feel the pain. As an example, doing:
doesn't work because the result of the fzf command has a newline. So you need something like @$(...).What I really want is to swap the default TAB autocompletion with an fzf selection, and there's no easy way to do it. You have to get deep into the underlying prompt_toolkit library and do a lot of surgery. It's doable, but I haven't had the time.
[+] [-] yitchelle|2 years ago|reply
With this setup, you can...
* create a BASIC program right at the command prompt
* execute instructions to read and write to mass storage.
* debug your BASIC program at the command prompt
* direct access to memory addresses via peek and poke commands
[+] [-] qwertox|2 years ago|reply
What does in the ways that matter mean? It would matter to me that it is 100% Bash compatible, else I won't use another shell in addition to `zsh`.
[+] [-] BeetleB|2 years ago|reply
It's Bash compatible in many/most ways, but there are always exceptions. If you want a Bash-like experience in Windows, xonsh is a good fit.
[+] [-] INTPenis|2 years ago|reply
[+] [-] weinzierl|2 years ago|reply
[+] [-] gatane|2 years ago|reply
[1] https://www.mankier.com/1/rc
[2] https://github.com/rakitzis/rc
[+] [-] sigmonsays|2 years ago|reply
A shell should be interoperable between users. If everyone on your team uses xonsh, then great, by all means. Otherwise, you're in your own little esoteric world.
a shell has to be stable, a python environment is not. There is just too many ways a python package can break. If python had a good package system perhaps it'd bring something to the table.. but python is by far the winner of the programming language with the worst packaging ecosystem i've seen and used.
[+] [-] hawski|2 years ago|reply
For example the thing that turned me completely off PowerShell is that its pipelines are sequential not parallel. I use shell a lot, because it has streaming built-in. Many (also standard) libraries do not work around streaming, which I find is the reason why they often crumble when there is more data. For example Python's ZipFile or TarFile work around listing members should have been iterators.
[+] [-] honkycat|2 years ago|reply
Make sucks, it is a c build tool we have Frankenstein'd into a task runner.
Bash is missing a huge amount of features of modern programming languages, and has a bunch of foot-guns baked in by default ( not setting -e, etc. )
I would love to see a modern language that:
- has a similar mental model a d syntax to other programming languages
- built in argument parsing, declaration, and help string generation
- designed for "scripting" - calling out to other binaries and gluing tools together
[+] [-] hnlmorg|2 years ago|reply
- Elvish: https://elv.sh
- Murex: https://murex.rocks
- Nushell: https://www.nushell.sh
Each have their own strengths and weaknesses
[+] [-] RcouF1uZ4gsC|2 years ago|reply
[+] [-] roblabla|2 years ago|reply
[+] [-] BeetleB|2 years ago|reply
OK. I lied. Since I installed xonsh and its dependencies in my user directory and not system wide, every time I upgrade my Python to a new major version I have to reinstall xonsh. Usually just one command will do it.
And it's not even in a virtualenv.
[+] [-] efitz|2 years ago|reply
[+] [-] jijijijij|2 years ago|reply
https://github.com/nushell/nushell
[+] [-] geophile|2 years ago|reply
It passes Python values instead of json, but otherwise works as you described.
[+] [-] Arcuru|2 years ago|reply
[+] [-] wredue|2 years ago|reply
[+] [-] epr|2 years ago|reply
[+] [-] ksaj|2 years ago|reply
Also, the rc file is way easier to read and manage.
I don't know why they advertise as being like bash. It's absolutely not like bash except that their default prompts look similar on the command line. The similarities pretty much end there.
[+] [-] ultra_nick|2 years ago|reply
However, I feel like Xonsh needs a killer app to really demonstrate the advantages of the semantics Xonsh provides. Maybe something like Rawdog (https://github.com/AbanteAI/rawdog) + Xonsh?
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] AeroNotix|2 years ago|reply
[+] [-] thesuperbigfrog|2 years ago|reply
There are several projects with the same idea: https://www.cliki.net/Lisp%20as%20a%20shell
[+] [-] globular-toast|2 years ago|reply
[+] [-] brumar|2 years ago|reply
[+] [-] eternityforest|2 years ago|reply
Using the same tool everywhere is nice because... that way I don't forget how to use BASH when I eventually need it.
[+] [-] ok123456|2 years ago|reply
[+] [-] BeetleB|2 years ago|reply
[+] [-] h0p3|2 years ago|reply
[+] [-] roger_|2 years ago|reply
[+] [-] geophile|2 years ago|reply
Lots of examples on the website.