bash, mostly, because I know it will be there or within reach if it isn’t. If things really need to be portable to the toaster I write to plain POSIX sh (using dash as a test subject). I’ve used csh, tcsh, zsh, ksh and tried to get a working version of a Perl shell but end up with bash all the time.
After a baroque period I spent with zsh years ago, I eventually moved towards a vanilla bash with as little customization as I can. For scripts I try to use POSIX shell as much as possible (usually dash).
To be honest I would often use perl for scripts, but I’m not sure how my colleagues would react. I had a couple of divergence of opinions before about it…
mostly, because I know it will be there or within reach if it isn’t
Yes. I jump systems quite a bit and bash has always been there. I use python3 almost exclusively for scripts now though, because my automation needs to be cross-platform and it’s usually there as well..
I use fish on macOS. There’s occasional headaches due to its lack of bash compatibility, but I find the ergonomics of using it to be much nicer than bash, zsh, or any other bash-compatible shell I’ve tried.
I’m using fish as well as my daily driver, and switched to it more than 2 years ago.
I like that everything is to my liking out of the box, without having to use any plugins for advanced features. I’m using the vim mode in it, and use starship as prompt.
It doesn’t support some bash syntax such as && or !!, but is otherwise very compatible. It changed some things for the better. Problems with this when copy-pasting snippets from others are rare, but I sometimes open bash just to run that snippet.
Same. I bounced off zsh a couple times before this, and fish itself once due to some bugs which the maintainer was quite gracious about (one of my first open source interactions iirc!), but after a long hiatus of putting up with bash’s nonsense I tried fish again and fell in love with it for just providing the Right Stuff for my use case.
Unfortunately, $WORK has quite a lot of important dev tooling written in bash, so I’m still using it by default there. Maybe someday I’ll have it all migrated to Python.
It has all the power of Racket, and you can write normal (or abnormal) Racket code mixed with shell-style code. It has a line-oriented syntax that is nice for interactions (no superfluous parens while interacting with your shell), but you can drop s-expressions in anywhere, and also escape back into line-mode. Just like with Bash and friends you can copy/paste your interactions into a file to instantly have a script. But as you edit your script and generalize it, you have a REAL programming language with data structures, sane error handling, libraries, etc.
Interactive completion leaves a lot to be desired, though. Some day I’ll improve that.
I wrote a dotfile manager in rc and it was such a breath of fresh air. Just reading the documentation honestly made me happy, and not much documentation does that! I don’t think I could ever use it as an interactive shell though, and I still write most scripts in portable sh, but I do wish rc were more ubiquitous.
I’ve been using zsh for nearly a decade. No oh-my-zsh though, just a crufty pile of config and scripts accumulated throughout years (a bit over 2 KLoC). I’ve been experimenting with rash and scsh lately.
I mostly use GUI’s given I came from a Windows background. Far as shells, one of most powerful options was newLISP that @itistoday uses. Here’s highlights from the FAQ:
“newLISP is a LISP-like scripting language for doing things you typically do with scripting languages: programming for the internet, system administration, text processing, gluing other programs together, etc. newLISP is a scripting LISP for people who are fascinated by LISP’s beauty and power of expression, but who need it stripped down to easy-to-learn essentials.
…pragmatic and casual, simple to learn without requiring you to know advanced computer science concepts. Like any good scripting language, newLISP is quick to get into and gets the job done without fuss… newLISP has a very fast startup time, is small on resources like disk space and memory and has a deep, practical API with functions for networking, statistics, machine learning, regular expressions, multiprocessing and distributed computing built right into it, not added as a second thought in external modules.”
He wrote an article about why he loved it with some lessons learned in the comments.
I’m glad you’re enjoying newLISP! I’m surprised to see it mentioned here as far as shells go, but I guess it makes sense since some people use the shell’s “language” to write programs, in addition to executing commands. This idea of using shells to write programs is one of the worst ideas. I hope with time everyone will come to realize that. Here’s a longer rant on the subject. I can’t tell you how much time I’ve wasted writing programs in bash/zsh/sh, only to deeply regret it later on and have to rewrite all of it in newLISP. If I had just written it in newLISP in the first place I would have saved myself so much suffering.
I’m not using it or any other shells much. I just thought it was one of the better options people were evangelizing for their customized setups. Figured I should mention it given I thought it would have an effect like you described in the last sentence. ;)
Bash on Linux, tcsh on FreeBSD, and ksh on OpenBSD. The first and last are default and I’m happy with that for the most part. I got into tcsh somewhat with OS X in the early days when it was the default and decided to switch to that in FreeBSD when I was getting familiar with it.
What: I switched to zsh 4 years ago and dumped my custom bash config in-favor of oh-my-zsh.
Why: Had to setup multiple new installs (due to new releases, server upgrades, etc.) managing my bashrc was getting tedious and oh-my-zsh was way nicer than what i could get by spending the amount of time i had for bash.
Bash. I never have to guess if it’ll be there. I work with lots of systems that I don’t have direct control over, so it makes sense to use the default. At least on Linux.
I’ll suffer through tsch on FreeBSD for root, but my users will use bash.
I use zsh with my own simple config slimzsh. When I started using zsh ~15 years ago it had more polished features than bash like tab-completion, more sophisticated globbing etc. I was improving the config from time to time and ~ 5 years ago I pretty much stabilised with config which became slizmsh.
I used to be that guy who heavily customized his shell – I’ve tried
fish, zsh (heck I even wrote a framework to customize my zsh prompt). But now I’m back to
bash, I just find it faster and simpler. I get all the features that I
actually need. zsh/fish is just fluff, in my opinion – cool stuff, but
not actually necessary to be productive.
Currently I use bash or eshell. I used to use fish but it had a noticeable delay starting up which frustrated me, and out of the box didn’t work well with the framebuffer TTY.
bash because I’m too lazy to change it. I don’t have any modifications to it. eshell because it’s in Emacs and has some nice features, completion and the like which fish had but it also works in my Emacs environment.
I’ve been using fish for some 8~10 years. It was an obvious choice over bash the second I saw it and to this day, I can’t find a single advantage of bash or zsh. All my shell scripts are, well… shell scripts, and point to #!/bin/sh. Bash’ posix compatibility would only be an argument theoretically in systems where bourne shell would not be present, which never really happens. Not even in systems like busybox.
Zsh is popular among apple fanboys, but I noticed they mostly make that choice out of cultural reasons. I.e. they saw someone doing it and do it to without knowledge of other alternatives. I often see people whose terminal applications take seconds to boot the prompt due to zsh plugin abuse. This is just insanity imho.
I change work environment often and need to set up my work computer often, installing plugins and other customization is a cost I am always cautious to take, hence I don’t customize fish further. Except for one thing: a fuzzy search on my command history using which I find to ctrl+r. I use this function . This is invaluable for me, but still, due to the above mention reason, I install it only in the systems I am going to spend a longer time period in, roughly 50% of the time.
I use elvish! I like it. It’s robust and when writing scripts I often appreciate the stronger typing compared to posix shell. Mostly I’m adding this because I haven’t seen it mentioned yet.
bash & shellcheck & shfmt, I have come to love those combination of tools for quickly automating parts of my workflow. I often pipe my shell history into a file and then create a quick script to automate something I am working on, fc -l > script. I think of bash more as a REPL than just as a command shell.
TBH I only use basic features of shell. The most advanced thing I do is piping into awk. If I need any kind of control structure or “advanced” processing, I do it in Lisp (and in the past Python or Perl).
I’ve thought about it. Unfortunately, you’d end up writing code that compiles to bash. At that point you might as well write a python script.
I do have a script to make it easy to generate new bash and python command line scripts, though. Whenever I run across a pattern I keep typing in terminal, I run “mkbin foo”, which spits out ~/bin/foo with a little boilerplate like “if no args are passed in, print usage info and exit.”
mkpy is similar, except it generates boilerplate to parse arguments / stdin, and run main().
Generate native executable using fast compile. Optionally, it’s optimized later.
Generate bash with templates. Optionally, type/argument checks and privilege minimization.
The first option is what I’d think someone would do with an optimizing Lisp. You code for the shell like you would anything else. The program can use any benefits of Lisp. It also runs on any supported platform. That might include Windows and Mac depending on what you’re doing.
For the second, I figured I’d use a command that dropped me into an editor with boilerplate (esp includes) pre-appended. Then, type in whatever I wanted done. Then run and/or compile it.
zsh, with oh-my-zsh and a lot of other configs. I switched from bash to fish a while ago, after years of using bash, and kicked myself for not doing it sooner. Then, I wanted more configurability and freedom (and I was spooked when the fish repo was briefly DMCA’d on github) so I switched to zsh and haven’t looked back :)
Interactive shell: zsh with slightly customised configuration and a very simple theme; this works on Linux, in WSL and on OSX.
Non-interactive shell for scripts: bash; available on all systems I target my scripts at, with richer syntax requiring less contortions than pure POSIX shell.
After two decades of tcsh and zsh I am on fish. Which is amazing. It just works. I think the only thing I did was adding something to my path and change the prompt to include vcs info.
I use xonsh, it’s a god-send to be able to script with something as powerful as Python. I have had a couple issues over the past 4-so years, but mainly with programs that do weird stuff to your shell environment.
To be honest I’m kinda shocked at how much people are willing to suffer through shell scripting for the sake of compatibility. I know some people spend a lot of time in various machines, but don’t most of us use the same one or two machines?
I use zsh, but I’m one of the maintainers of prezto as well as my own mini framework called zsh-utils so I’m a bit biased.
I’m a big fan of zsh because it allows more customizability when compared to bash, but I would strongly recommend using something like zsh-utils (or any number of config frameworks) to reduce boilerplate and strange defaults.
I was using tcsh from 1990 to 2003. Now I am using bash because it was the default that came with distributions that I used from 2003 onwards. Even when my desktop was OpenBSD I added bash instead of pdksh which was (is?) their default.
Bash, with a prompt written in Zig. Keeping an eye on Oil, but it is still much too slow for me. I tried Fish and some others, but they ended up being too much of a hassle for me. I use shellcheck to ensure that I don’t put more bashisms into the world.
Fish, for its autocompletion. Discovering that as a novice terminal user, there was no turning back. I later learnt you can press Ctrl+R in bash to get basically the same. But only basically, as far as I can tell. I would have to spend some time on that if I wanted to switch back to bash, and be as productive, and I don’t even know if I would succeed.
I also appreciate the ability to write multi-liners right in the terminal. From simple loops, to grouping repetitive commands in a scope. And the occasional 20-liner of course.
I have used Fish so long that I don’t get surprised anymore about its differences from a POSIX shell. It’s a nuisance some times, but mostly a non-issue.
I use zsh. I like features like its awesome tab completion, and my prompt is just how I like it.
I’m annoyed that the same config doesn’t work across systems, for example ctrl+backspace produces completely different bytes on my laptop, my desktop and when SSH’d into a server and using tmux. Similarly, my ctrl+j hotkey doesn’t work on my server. However, I don’t think that’s the shell’s fault; that seems to just be that terminals in Linux in general is a mess.
zsh, because it’s just a tad nicer than bash - I think I don’t use all the fancy features, but it fixed some oddities I encountered, years ago, and I never went back. But to be honest, 90% of it is that I managed to get the prompt working in a better and nicer way ;)
I have a basic shell config that works with most POSIX-ly bourne shells - on Debian i use the default bash, on Alpine mksh or busybox ash. Since my prompt renders the same on all shells, im able to use them interchangeably.
bash, because it’s everywhere and it works reasonably well once you know its quirks
tcl. I recently started using it because of expect and I liked it a lot, so I started experimenting with it as a shell. I’m working on integrating it with bash-completion now. I probably wouldn’t use it for big projects though.
When I learned Unix in the late 90ies through installing my very first Linux distro on my machine, I accidentally came across zsh as a replacement for bash which everybody was using back then.
On their website, right in the middle, there was a link to the User-friendly user guide. As a total beginner, that was exactly what I wanted and so I went ahead, clicked that link and began reading.
The guide turned out to be very user-friendly indeed and it didn’t just teach me ZSH in specific but actually Unix shells in general. It also thought me all the features that zsh had back then and that bash was lacking and with it being my first and only shell on my first and only Unix machine, there was no reason not to make use of all of those features.
So in the end, I learned Unix through zsh and it’s oh so very good user’s guide and I stuck with zsh ever since out of brand loyalty and nostalgia.
I can use bash and I know (some of) the differences to zsh, but if it’s a machine I’m actually using, I’m chsh-ing to zsh for sure. Only in zsh I know the names of many, many setopt option flags and only in zsh I know how to configure auto completion and, heck, I even know how to set up colored prompts by heart.
But for general usage and shell scripting, bash and zsh by now are very interchangable, so if you ask me what you should be going with, I would say: whatever your OS comes with and whatever you’re most likely to see installed on the machines you’re working on.
home- hand configured zsh, work- minimally configured bash. Neither are really ideal and I just need to get things done. Anything larger than a few lines and I reach for a (locally acceptable) scripting language.
I use a mix of zsh / oh-my-zsh and good old regular bash. While I use the terminal daily I am not what you would call a power user and only have oh-my-zsh installed for the git status display and tabbed autocomplete.
bash on my linux server, so that I keep fresh on how to use it for when I have to dive into other people’s bash shells.
For work, I used to use git bash on Windows, but these days I’ve switched over to using cmd.exe more, as there are a lot of batch scripts involved in building the software I work on.
In both, however, I use some variation on jumplists, as I find that to be very helpful. I also end up using RipGrep a lot, and of late, I’ve been using Nim for odds and ends in my work shell a fair bit.
I used to use OpenBSD ksh everywhere, but now use ksh on OpenBSD and bash on Linux as I modified my startup scripts to work with both, and it’s just easier that way. For scripts I try to write POSIX sh. I hate #!/bin/bash for scripts. If it’s not going to be portable, and you need the extra features, why not just write in a more capable language?
It depends. I use tcsh on my FreeBSD servers. Everywhere else (work MBP, personal laptop, Cent OS VMs for work), I use fish.
I had used zsh previously for over a decade, which I still quite like and for something POSIX-ish, it’s still my first choice, but I gave fish a go some time ago and it did everything I wanted right out of the box with much less configuration, and let me get rid of a tonne of crufty old config.
tcsh I use on my servers as it’s in the base system and is a decent interactive shell (though its history search behaviour - the necessity to hit escape, specifically - is a bit annoying after being used to how zsh does things), so, with some minor tweaking, I have no need to install any other shells.
Even if out of fashion, KornShell 93 is still my favourite. Not only a great shell with vi-like input, but also a decent scripting language that features floating-point numbers, async, pointers, and OOP.
I use Zsh. It was a straight upgrade from Bash, with quality-of-life improvements like syntax highlighting and autocomplete extensions, as well as hashed directories, sane history, global aliases, better completion, and so on. I was able to keep most of my existing Bash code the same, such as my prompt customizations, and with a little bit of work I’m able to keep all my config compatible with both Zsh and Bash for when I ssh into servers (with sshrc to bring much of my config with me). Since it’s one of the most popular shells, everything supports Zsh out of the box.
I’ve been using zsh for 25-years. I had used tcsh for a couple of years before. Bash was little better than plain sh at that time. My config has grown over the years as features have been added to zsh and is fairly large by now, I’ve not needed to use any framework or plugin manager.
On Wed, 06 Nov 2019 16:51:37 -0600
w w@lobste.rs wrote:
What shell do you use and why?
Bash, because I end up using various boxes, and it’s everywhere.
I have a custom .bashrc in my dotfiles repo which gets placed on every
box I use to make it behave the way I want it to, with tweaks to the
prompt, colouring the hostname by type of box (dev/staging/production
etc), history handling tweaks, some custom functions and aliases etc.
I’ve toyed with other shells but I’ve not found any killer features
that are enough to make me deal with using one shell in some places,
and another in others.
First of all, most absolute generalizations are false, a lot of people very reasonably use fish and run into no issues with incompatibility, because of their use cases. Second, you don’t provide any justification for that claim. Third, you assume the user is male.
If you’re going to comment, foster discussion: why do you make that claim?
bash, mostly, because I know it will be there or within reach if it isn’t. If things really need to be portable to the toaster I write to plain POSIXsh(usingdashas a test subject). I’ve usedcsh,tcsh,zsh,kshand tried to get a working version of a Perl shell but end up withbashall the time.No custom configs, just plain
bash.After a baroque period I spent with zsh years ago, I eventually moved towards a vanilla bash with as little customization as I can. For scripts I try to use POSIX shell as much as possible (usually dash).
To be honest I would often use perl for scripts, but I’m not sure how my colleagues would react. I had a couple of divergence of opinions before about it…
Yes. I jump systems quite a bit and bash has always been there. I use python3 almost exclusively for scripts now though, because my automation needs to be cross-platform and it’s usually there as well..
I use
fishon macOS. There’s occasional headaches due to its lack ofbashcompatibility, but I find the ergonomics of using it to be much nicer thanbash,zsh, or any otherbash-compatible shell I’ve tried.As you I use
fishfor my shell (with oh-my-fish).For short/quick scripts I use
zshgenerally using anix-shellbang pattern like this:And when I’m serious about a script that I switch to
turtle.I find autocomplete and highlighting in fish are amazing compared to any other shell I’ve used
I use eshell, because I can extend it using lisp, and it gives me cool features like hyperlinked grep results.
I’m using
fishas well as my daily driver, and switched to it more than 2 years ago.I like that everything is to my liking out of the box, without having to use any plugins for advanced features. I’m using the vim mode in it, and use
starshipas prompt.It doesn’t support some bash syntax such as
&&or!!, but is otherwise very compatible. It changed some things for the better. Problems with this when copy-pasting snippets from others are rare, but I sometimes openbashjust to run that snippet.If you’re running a recent build of
fish, thebash-style&&syntax should work.[Comment removed by author]
Same. I bounced off
zsha couple times before this, andfishitself once due to some bugs which the maintainer was quite gracious about (one of my first open source interactions iirc!), but after a long hiatus of putting up withbash’s nonsense I triedfishagain and fell in love with it for just providing the Right Stuff for my use case.Unfortunately, $WORK has quite a lot of important dev tooling written in bash, so I’m still using it by default there. Maybe someday I’ll have it all migrated to Python.
Shameless self-promotion: I use Rash, of course!
It has all the power of Racket, and you can write normal (or abnormal) Racket code mixed with shell-style code. It has a line-oriented syntax that is nice for interactions (no superfluous parens while interacting with your shell), but you can drop s-expressions in anywhere, and also escape back into line-mode. Just like with Bash and friends you can copy/paste your interactions into a file to instantly have a script. But as you edit your script and generalize it, you have a REAL programming language with data structures, sane error handling, libraries, etc.
Interactive completion leaves a lot to be desired, though. Some day I’ll improve that.
zsh / oh-my-zsh, mostly because macOS + it is easy
I use rc(1), the only shell that doesn’t confuse me endlessly with absurd quoting problems. Now I actually enjoy writing shell scripts…
I wrote a dotfile manager in rc and it was such a breath of fresh air. Just reading the documentation honestly made me happy, and not much documentation does that! I don’t think I could ever use it as an interactive shell though, and I still write most scripts in portable sh, but I do wish rc were more ubiquitous.
I loved using RC but eventually gave up and use zsh (home) and bash (work).
I use rc as my fulltime shell as well - specifically Byron’s rc which cleans up some of the silly “if not” logical things.
I’m a true Debian user, therefore I use plain old
bash.Why do you use bash if you use debian? Debians default shell is dash since squeeze
/bin/sh is dash, but bash is the default user shell
Even though I don’t use Debian (much) anymore!
Sometimes bash on linux, because it’s the default.
I use fish, It makes me super effecient and i love its autocomplete!
I’ve been using
zshfor nearly a decade. Nooh-my-zshthough, just a crufty pile of config and scripts accumulated throughout years (a bit over 2 KLoC). I’ve been experimenting withrashandscshlately.I mostly use GUI’s given I came from a Windows background. Far as shells, one of most powerful options was newLISP that @itistoday uses. Here’s highlights from the FAQ:
“newLISP is a LISP-like scripting language for doing things you typically do with scripting languages: programming for the internet, system administration, text processing, gluing other programs together, etc. newLISP is a scripting LISP for people who are fascinated by LISP’s beauty and power of expression, but who need it stripped down to easy-to-learn essentials.
…pragmatic and casual, simple to learn without requiring you to know advanced computer science concepts. Like any good scripting language, newLISP is quick to get into and gets the job done without fuss… newLISP has a very fast startup time, is small on resources like disk space and memory and has a deep, practical API with functions for networking, statistics, machine learning, regular expressions, multiprocessing and distributed computing built right into it, not added as a second thought in external modules.”
He wrote an article about why he loved it with some lessons learned in the comments.
I’m glad you’re enjoying newLISP! I’m surprised to see it mentioned here as far as shells go, but I guess it makes sense since some people use the shell’s “language” to write programs, in addition to executing commands. This idea of using shells to write programs is one of the worst ideas. I hope with time everyone will come to realize that. Here’s a longer rant on the subject. I can’t tell you how much time I’ve wasted writing programs in bash/zsh/sh, only to deeply regret it later on and have to rewrite all of it in newLISP. If I had just written it in newLISP in the first place I would have saved myself so much suffering.
I’m not using it or any other shells much. I just thought it was one of the better options people were evangelizing for their customized setups. Figured I should mention it given I thought it would have an effect like you described in the last sentence. ;)
I own a single paper copy of 2600 and it has an article on newLISP :)
You got one of the better ones. ;)
Bash on Linux, tcsh on FreeBSD, and ksh on OpenBSD. The first and last are default and I’m happy with that for the most part. I got into tcsh somewhat with OS X in the early days when it was the default and decided to switch to that in FreeBSD when I was getting familiar with it.
What: I switched to zsh 4 years ago and dumped my custom bash config in-favor of oh-my-zsh.
Why: Had to setup multiple new installs (due to new releases, server upgrades, etc.) managing my bashrc was getting tedious and oh-my-zsh was way nicer than what i could get by spending the amount of time i had for bash.
Bash. I never have to guess if it’ll be there. I work with lots of systems that I don’t have direct control over, so it makes sense to use the default. At least on Linux.
I’ll suffer through tsch on FreeBSD for root, but my users will use bash.
I love ZSH
I use zsh with my own simple config slimzsh. When I started using zsh ~15 years ago it had more polished features than bash like tab-completion, more sophisticated globbing etc. I was improving the config from time to time and ~ 5 years ago I pretty much stabilised with config which became slizmsh.
zsh on GNU/Linux, FreeBSD, and OSX. Mostly because oh-my-zsh makes customization easy.
zshon macOS with zplugin for managing plugins (it’s by far the fastest in my experience, and others have done benchmarks).Why
zsh? It’s popular and isn’tbash. I’ve thought about tryingfishbut haven’t gotten around to it.zsh. I started using it more than a decade ago for the superior completion. I continue to enjoy that and have remained with it ever since.
I used to be that guy who heavily customized his shell – I’ve tried fish, zsh (heck I even wrote a framework to customize my zsh prompt). But now I’m back to bash, I just find it faster and simpler. I get all the features that I actually need. zsh/fish is just fluff, in my opinion – cool stuff, but not actually necessary to be productive.
fish, macOS. I love the autocomplete, and these days it’s relatively painless, compatability-wise.
Currently I use
bashoreshell. I used to usefishbut it had a noticeable delay starting up which frustrated me, and out of the box didn’t work well with the framebuffer TTY.bashbecause I’m too lazy to change it. I don’t have any modifications to it.eshellbecause it’s in Emacs and has some nice features, completion and the like whichfishhad but it also works in my Emacs environment.I’ve been using fish for some 8~10 years. It was an obvious choice over bash the second I saw it and to this day, I can’t find a single advantage of bash or zsh. All my shell scripts are, well… shell scripts, and point to #!/bin/sh. Bash’ posix compatibility would only be an argument theoretically in systems where bourne shell would not be present, which never really happens. Not even in systems like busybox.
Zsh is popular among apple fanboys, but I noticed they mostly make that choice out of cultural reasons. I.e. they saw someone doing it and do it to without knowledge of other alternatives. I often see people whose terminal applications take seconds to boot the prompt due to zsh plugin abuse. This is just insanity imho.
I change work environment often and need to set up my work computer often, installing plugins and other customization is a cost I am always cautious to take, hence I don’t customize fish further. Except for one thing: a fuzzy search on my command history using which I find to ctrl+r. I use this function . This is invaluable for me, but still, due to the above mention reason, I install it only in the systems I am going to spend a longer time period in, roughly 50% of the time.
The default one provider by the OS
I use elvish! I like it. It’s robust and when writing scripts I often appreciate the stronger typing compared to posix shell. Mostly I’m adding this because I haven’t seen it mentioned yet.
bash & shellcheck & shfmt, I have come to love those combination of tools for quickly automating parts of my workflow. I often pipe my shell history into a file and then create a quick script to automate something I am working on,
fc -l > script. I think of bash more as a REPL than just as a command shell.zsh, eshell, and bash.
TBH I only use basic features of shell. The most advanced thing I do is piping into awk. If I need any kind of control structure or “advanced” processing, I do it in Lisp (and in the past Python or Perl).
I try to follow as much as possible the ideas from https://suckless.org/
Thus I use mksh as recommended there: https://suckless.org/rocks/
You can pry zsh from my cold dead hands. Some of my tricks.
bash. It’s productive.
I figured experienced Lisper’s like you would’ve replaced it, embedded it, auto-generated it, or some other wild stuff by now.
I’ve thought about it. Unfortunately, you’d end up writing code that compiles to bash. At that point you might as well write a python script.
I do have a script to make it easy to generate new bash and python command line scripts, though. Whenever I run across a pattern I keep typing in terminal, I run “mkbin foo”, which spits out ~/bin/foo with a little boilerplate like “if no args are passed in, print usage info and exit.”
mkpy is similar, except it generates boilerplate to parse arguments / stdin, and run main().
https://github.com/shawwn/scrap
Yeah, I figured there’s two approaches:
Generate native executable using fast compile. Optionally, it’s optimized later.
Generate bash with templates. Optionally, type/argument checks and privilege minimization.
The first option is what I’d think someone would do with an optimizing Lisp. You code for the shell like you would anything else. The program can use any benefits of Lisp. It also runs on any supported platform. That might include Windows and Mac depending on what you’re doing.
For the second, I figured I’d use a command that dropped me into an editor with boilerplate (esp includes) pre-appended. Then, type in whatever I wanted done. Then run and/or compile it.
zsh on primary machines with this config, fairly stock bash as a matter of course on various servers and things like single-purpose Raspberry Pis.
zsh, with
oh-my-zshand a lot of other configs. I switched from bash to fish a while ago, after years of using bash, and kicked myself for not doing it sooner. Then, I wanted more configurability and freedom (and I was spooked when the fish repo was briefly DMCA’d on github) so I switched to zsh and haven’t looked back :)zsh, with manual configs[1] on macOS, FreeBSD, and Linux (mostly fedora and centos).
[1]: no plugin managers, oh-my-*, etc
I use zsh with fairly minimal customizations. Mostly auto pushd and enabling some of the fancier completions.
Interactive shell:
zshwith slightly customised configuration and a very simple theme; this works on Linux, in WSL and on OSX.Non-interactive shell for scripts:
bash; available on all systems I target my scripts at, with richer syntax requiring less contortions than pure POSIX shell.After two decades of tcsh and zsh I am on fish. Which is amazing. It just works. I think the only thing I did was adding something to my path and change the prompt to include vcs info.
I use
xonsh, it’s a god-send to be able to script with something as powerful as Python. I have had a couple issues over the past 4-so years, but mainly with programs that do weird stuff to your shell environment.To be honest I’m kinda shocked at how much people are willing to suffer through shell scripting for the sake of compatibility. I know some people spend a lot of time in various machines, but don’t most of us use the same one or two machines?
I use zsh, but I’m one of the maintainers of prezto as well as my own mini framework called zsh-utils so I’m a bit biased.
I’m a big fan of zsh because it allows more customizability when compared to bash, but I would strongly recommend using something like zsh-utils (or any number of config frameworks) to reduce boilerplate and strange defaults.
zsh or bash
(Moved)
I was using
tcshfrom 1990 to 2003. Now I am usingbashbecause it was the default that came with distributions that I used from 2003 onwards. Even when my desktop was OpenBSD I added bash instead ofpdkshwhich was (is?) their default.ConEmu + PowerShell on Windows.
Bash, with a prompt written in Zig. Keeping an eye on Oil, but it is still much too slow for me. I tried Fish and some others, but they ended up being too much of a hassle for me. I use shellcheck to ensure that I don’t put more bashisms into the world.
Fish, for its autocompletion. Discovering that as a novice terminal user, there was no turning back. I later learnt you can press Ctrl+R in bash to get basically the same. But only basically, as far as I can tell. I would have to spend some time on that if I wanted to switch back to bash, and be as productive, and I don’t even know if I would succeed.
I also appreciate the ability to write multi-liners right in the terminal. From simple loops, to grouping repetitive commands in a scope. And the occasional 20-liner of course.
I have used Fish so long that I don’t get surprised anymore about its differences from a POSIX shell. It’s a nuisance some times, but mostly a non-issue.
fish as interactive shell.
bash or dash for scripts.
zsh, with a simple
~/.zshenv:and rc
$ZDOTDIR/.zshrc:I use zsh. I like features like its awesome tab completion, and my prompt is just how I like it.
I’m annoyed that the same config doesn’t work across systems, for example ctrl+backspace produces completely different bytes on my laptop, my desktop and when SSH’d into a server and using tmux. Similarly, my ctrl+j hotkey doesn’t work on my server. However, I don’t think that’s the shell’s fault; that seems to just be that terminals in Linux in general is a mess.
zsh, because it’s just a tad nicer thanbash- I think I don’t use all the fancy features, but it fixed some oddities I encountered, years ago, and I never went back. But to be honest, 90% of it is that I managed to get the prompt working in a better and nicer way ;)My login shell is
bash, but for interactive use and some scripts I usefish.zsh with grml config, because it has fictional and useful parts actually improving productivity without fuzz (like oh-my-zsh, etc.).
And I dislike bash, but more for personal taste.
If I want something more minimal I tend to go with ksh. But that’s rare.
I have a basic shell config that works with most POSIX-ly bourne shells - on Debian i use the default bash, on Alpine mksh or busybox ash. Since my prompt renders the same on all shells, im able to use them interchangeably.
You (@w) hadn’t specified the purpose so here goes both:
$SHELL-ksh(1)on OpenBSD, the same on macOS, and whatever is the default (Bash!?) onLinuxsystems I happen to administer./bin/sh(whatever it may be) and stick toPOSIX-only options.expectand I liked it a lot, so I started experimenting with it as a shell. I’m working on integrating it with bash-completion now. I probably wouldn’t use it for big projects though.When I learned Unix in the late 90ies through installing my very first Linux distro on my machine, I accidentally came across zsh as a replacement for bash which everybody was using back then.
On their website, right in the middle, there was a link to the User-friendly user guide. As a total beginner, that was exactly what I wanted and so I went ahead, clicked that link and began reading.
The guide turned out to be very user-friendly indeed and it didn’t just teach me ZSH in specific but actually Unix shells in general. It also thought me all the features that zsh had back then and that bash was lacking and with it being my first and only shell on my first and only Unix machine, there was no reason not to make use of all of those features.
So in the end, I learned Unix through zsh and it’s oh so very good user’s guide and I stuck with zsh ever since out of brand loyalty and nostalgia.
I can use bash and I know (some of) the differences to zsh, but if it’s a machine I’m actually using, I’m
chsh-ing to zsh for sure. Only in zsh I know the names of many, manysetoptoption flags and only in zsh I know how to configure auto completion and, heck, I even know how to set up colored prompts by heart.But for general usage and shell scripting, bash and zsh by now are very interchangable, so if you ask me what you should be going with, I would say: whatever your OS comes with and whatever you’re most likely to see installed on the machines you’re working on.
home- hand configured zsh, work- minimally configured bash. Neither are really ideal and I just need to get things done. Anything larger than a few lines and I reach for a (locally acceptable) scripting language.
zsh (config).
I’d love to switch to ion but it really doesn’t have enough features right now.
auto_pushdcdpath/fromWORDCHARSto make Ctrl-W delete the last path component only in paths)envcommand /SOMEVAR=1 echo $SOMEVARI use a mix of zsh / oh-my-zsh and good old regular bash. While I use the terminal daily I am not what you would call a power user and only have oh-my-zsh installed for the git status display and tabbed autocomplete.
bashon my linux server, so that I keep fresh on how to use it for when I have to dive into other people’s bash shells.For work, I used to use git bash on Windows, but these days I’ve switched over to using cmd.exe more, as there are a lot of batch scripts involved in building the software I work on.
In both, however, I use some variation on jumplists, as I find that to be very helpful. I also end up using RipGrep a lot, and of late, I’ve been using Nim for odds and ends in my work shell a fair bit.
fish. Completions is a win for me.
I used to use OpenBSD ksh everywhere, but now use ksh on OpenBSD and bash on Linux as I modified my startup scripts to work with both, and it’s just easier that way. For scripts I try to write POSIX sh. I hate
#!/bin/bashfor scripts. If it’s not going to be portable, and you need the extra features, why not just write in a more capable language?Ksh on OpenBSD
Bash or KSH on most platforms
CSH on Solaris
VINCE on AmigaOS
It depends. I use tcsh on my FreeBSD servers. Everywhere else (work MBP, personal laptop, Cent OS VMs for work), I use fish.
I had used zsh previously for over a decade, which I still quite like and for something POSIX-ish, it’s still my first choice, but I gave fish a go some time ago and it did everything I wanted right out of the box with much less configuration, and let me get rid of a tonne of crufty old config.
tcsh I use on my servers as it’s in the base system and is a decent interactive shell (though its history search behaviour - the necessity to hit escape, specifically - is a bit annoying after being used to how zsh does things), so, with some minor tweaking, I have no need to install any other shells.
tcshIn base on my daily OS, FreeBSD. No bloat KISS.Even if out of fashion, KornShell 93 is still my favourite. Not only a great shell with vi-like input, but also a decent scripting language that features floating-point numbers, async, pointers, and OOP.
I use fish for my shell (with oh-my-fish). This is pretty killer with Ctrl+R (reverse history search) and fzf
bash, because I do infrastructure / systems work and everything in our universe will break HARD if I try using anything else :)
Also, it’s knowledge I can sure-footedly transfer anywhere.
I use Zsh. It was a straight upgrade from Bash, with quality-of-life improvements like syntax highlighting and autocomplete extensions, as well as hashed directories, sane history, global aliases, better completion, and so on. I was able to keep most of my existing Bash code the same, such as my prompt customizations, and with a little bit of work I’m able to keep all my config compatible with both Zsh and Bash for when I ssh into servers (with sshrc to bring much of my config with me). Since it’s one of the most popular shells, everything supports Zsh out of the box.
My .zshrc is in source control here:
https://github.com/kbd/setup/blob/master/HOME/.zshrc
I’ve been using zsh for 25-years. I had used tcsh for a couple of years before. Bash was little better than plain sh at that time. My config has grown over the years as features have been added to zsh and is fairly large by now, I’ve not needed to use any framework or plugin manager.
On Wed, 06 Nov 2019 16:51:37 -0600 w w@lobste.rs wrote:
Bash, because I end up using various boxes, and it’s everywhere.
I have a custom .bashrc in my dotfiles repo which gets placed on every box I use to make it behave the way I want it to, with tweaks to the prompt, colouring the hostname by type of box (dev/staging/production etc), history handling tweaks, some custom functions and aliases etc.
I’ve toyed with other shells but I’ve not found any killer features that are enough to make me deal with using one shell in some places, and another in others.
Anyone using POSIX-incompatible shell is doing more harm than good to himself.
First of all, most absolute generalizations are false, a lot of people very reasonably use fish and run into no issues with incompatibility, because of their use cases. Second, you don’t provide any justification for that claim. Third, you assume the user is male.
If you’re going to comment, foster discussion: why do you make that claim?