I use the borne shell as in /bin/sh for that same reason, however:
I don’t mind calling it /bin/bash – I just don’t use bash-features except line editing and I’m just as happy to use rlwrap or emacs instead.
I don’t tend to change directories. In a project with many subdirectories, I will constantly edit with the full path so that is what is stored in my history. This means that if I want to edit a file again, I will press control-R and type some distinct portion so that even if I have done things in the meantime, it’ll still work (because I’m still in the same directory).
I don’t set environment variables: You won’t find export foo=whatever in my history, because if I want the environment changed in my session I will edit ~/.profile and source it, and if I just want it for a particular invocation, I’ll write foo=whatever command so that the environment is just changed for running command. This has a similar property in that if I want to run the command again I can search for it (and it won’t necessarily have to be ordered).
I love the typeahead autocompletion and the simplified/reduced syntax & configuration. The fact that it’s not POSIX-compliant isn’t usually an issue since I just use plugin-foreign-env to run scripts in bash when necessary (e.g. for nvm).
Also fish and for the same reasons spencer mentioned.
My history with shells: sh/ksh/csh/whatever-pre-bash-sh, bash, zsh and now fish.
Scripting is not an issue (you do use “#!/path/to/shell” in your scripts, right?) and POSIX-compliance isn’t either.
Fish to me feels like to i3 of shells. i3 the window manager needs very little configuration to do what you’d expect and it’s the same for fish (instead of needing tons of config like zsh). I always used to be the kinda guy that wanted endless customization and configurability and I still sorta do but sane defaults have become important to me as well.
I used fish until last week, and now use zsh. The zsh-autosuggestions and zsh-syntax-highlighing plugins emulate the behaviours from fish that I care about. Day to day I use an unholy amount of ad-hoc shell logic, and running bash to do the more complex stuff started annoying me. The exact thing that pushed me over the edge was wanting to loop over thing{2..27}. While there is probably a way to do it in fish, I already know how to do it in bash/zsh.
I’ve used fish since the 2.0 release, and still use it on my home laptop.
I use zsh, and like it well enough, but I’m not enough of a shell power user to give a detailed endorsement. I originally switched some years ago because its tab-completion was better than bash’s, both in that it shipped with many more completions, and the completion language was nicer to use for writing more. The Debian maintainers also do a good job ensuring that the completions are in sync with what various Debian packages do with their binaries.
Beyond completions, the feature I probably use most on a regular basis is the multi-line line editor. Many shells let you write multi-line commands in the REPL, but zsh also lets you edit such commands in the history. For example, if you write something like
for i in 1 2 3
do
echo $i
done
run it, then hit up-arrow to go back and edit it, in zsh it’s still on multiple lines and you can edit them, while bash presents you a version that’s been smooshed into a one-liner.
The extended globbing can also be nice, though it’s huge and there are only a handful of features I remember enough to use.
Indeed, i get annoyed when I have to use find generally.
I tend to do ls -dal /file a LOT
More fun, list all symlinks:
ls *(@)
Take that expansion, restrict to directories:
ls -dal /name(/)
Or files
ls -dal /name(.)
Empty files:
ls -dal */(L0)
Files > 1 meg:
ls -dal */(Lm+1)
Stuff modified in last hour:
ls -dal */(mh-1)
It is a really damn convenient way to not deal with find and multiple predicates. Hell you can combine qualifiers, aka files > 1 meg modified in the last hour:
ls -dal */(.mh-1Lm+1)
Also multi line history editing is what made me switch to zsh years ago. At the time ksh just threw ^J’s in, aka useless, and bash did the same back then. Bash is better now but its still years behind zsh in the “holy hell what can’t this stupid shell do” department.
eshell, because I can extend it in Emacs Lisp, and life is to short to learn another badly-designed language just for customizing your shell. Piping shell commands straight to an Emacs buffer or lisp function is a nice bonus though.
True, but you can add these to a list so they automatically spin off their own specialized terminal emulator buffer automatically even when run from eshell.
Even so I hardly use this, since it’s so rare to find a curses-style program that doesn’t have an alternative interface implemented better in elisp.
I switched to zsh from bash several years ago, for several useful features:
Better tab-completion for command flags
Ignore duplicates in history. This saves me from scrolling past commonly run commands all the time, like “ls”
The “push-line” action, which pushes the current text on the line into a stack that will get popped after you press enter. This is useful when you type a long command to run, but realize that you want to run another command first.
It’s been too long at this point, but I seem to recall that the vi mode was more complete than bash’s
As mjn mentioned, the multi-line editing is more sane and useful
The ** glob is really nice; it expands across multiple directories, so **/*.c expands to all .c files in subdirectories
I’ve been using zsh for a long time, but I don’t really use push-line. Instead, I tend to do C-a C-k, run the other command, then C-y. Or, if in vi mode, ESC 0 d$, run the command, followed by ESC p.
You can do that in Bash by putting ‘erasedups’ in HISTCONTROL. I also want commands that start with a space to be ignored by the history, so I have this in my ~/.bashrc:
bash, because there’s hundreds of servers in $EMPLOYER’s fleet and it’s annoying enough to remember set -o vi every time I connect to one, never mind having to git clone a custom config. Downloading and building a new shell is right out.
If I didn’t have that restriction, I’d like to try fish, or even rc.
Interestingly, back in the college days and on Sun Solaris, I’ve spent quite some time trying to compile a newer version of tcsh from source code, trying to make it do the history search the way I enjoyed it on FreeBSD (was it one of those compile-time options as presented in $version, like filec, I thought to myself?), until finally finding out that it was a .cshrc configuration option.
The official tcsh faq even has an entry about the phenomenon:
28. Why does FreeBSD’s tcsh do history browsing differently than I expect?
On FreeBSD, by default, the up arrow is set to “history-search-backward”, rather than the default “up-history”. As a result, if you type (part of) a word and press up arrow, you’ll see previous commands that match the prefix. Pretty useful, actually, although it takes some getting used to. You can use bindkey to see your settings, and to rebind up & down differently if desired.
mksh, because it is extremely simple. It only auto-completes file paths and it helped me learn most UNIX commands better. Because of its limited feature set, it encourages me to write POSIX sh scripts. Also, it is very lightweight and fast.
Unlike existing shells, it moves seamlessly from creating unmaintainable one-liners optimized for minimal keystrokes, as they grow, into beautiful maintainable programs.
Like existing shells, but completely unlike most scripting languages, much of it’s power arises from decomposing problems into communicating processes, rather than modules.
Unlike existing shells, the interface definition language between processes is strict and formally specified, and human readable when a human looks at it or writes it, and binary when passed between processes.
Unlike existing shells, the options and arguments are not unspecified text strings, but again, in that strict IDL.
Like existing shells, when I’m at a command line, it does as much as possible to save me keystrokes.
Unlike existing shells, understanding of paths, files, filesystems is baked in, not merely half-baked in.
Unlike existing shells, it has a “did you mean it mode”, that will run the command in a fundamentally “read only” safe mode…. allowing you to see what the effect would be. And then allowing to rerun it in destructive mode.
Unlike existing command lines, it is not a infinite ticker tape of fire and forgotten text. But a curated and maintained conversation. Where previous snippets can always be named, recalled, rerun.
Like the sign at the top of a Ladder…. “Start Other Side”.
I’d start with an existing decent language with a very fast compile/link/run cycle.
I’d then define a decent IDL.
I have a horrid suspicion that may be predetermined.
ie. Whatever dbus / systemd / kdbus uses.
99% of what we want is already in dbus, the rest is coming with systemd and kdbus.
Program options and stdin / stdout interfaces and pipes are merely pale shadows of what dbus does.
The only problem is “Time To First Hello World” with dbus is way way too long. The integration with the “tiny tools” ie. coreutils, is non-existent.
The core to solving the problem is smooth that away. ie. Creating a dbus hello world should become as easy as…
echo Hello World
I’d then go through all the coreutils and “wrap” them. ie. Provide an IDL defined interface to their options / arguments, and where appropriate reimplement them to chew on streams defined in the IDL instead of loosely defined text records.
ie. The plan of attack would be….
Choose an existing powerful language with rapid compilation.
Set it up so it only compiles any script “on the first run”.
Provide really really clean and simple interfaces to dbus/kdbus.
Borrow / steal dbus IDL to provide typesafety communications between processes.
Borrow / steal dbus infrastructure define communication channels between processes.
Wrap/reimplement everything you may be tempted to use in Ye Average shell pipeline.
Bring XTERM into the 21st century.
Reimplement the “killer apps” for xterm (screen / ssh)
But this time have all the tools and power you need.
Would you have left your definition of IPC as environment variables (Hash from String to String), (argc, argv[]) Vector of null terminated strings and stdin,stdout, stderr?
Sure that is very powerful and flexible.
But it’s slow as paste and remarkably error prone. Need I list the ways? I can, but it would be a looong post.
You don’t need to sell me on that. Environment variables are invisible nonlocal state, and from a security-oriented perspective in 2016, they seem like the curse that keeps on giving. And I would really, really like a shell that could programmatically pull out relevant snippets of documentation, as I enter parameters. And one that doesn’t build all its core functionality around nested string escaping.
I’m nervous about dbus as the choice, because I have strong opinions on type systems, and I know nothing about the dbus architecture in general except that on my personal machines, it seems to either break or work fine, without a lot of manual configuration either way.
Hah! Dead right! That’s one of the strong points of dbus (and kdbus) is a lot of thought has been put into security aspects.
I have strong opinions on type systems
Alas, that’s a fundamental stumbling point.
You can’t afford to have too strong opinions as every computer language on the planet already has it’s own (equally strong, if not stronger) opinions.
One of the reasons I suggest dbus, is it clearly has hit a pragmatic compromise amongst those opinions.
One of the existing problems with dbus is it’s opaque to the ordinary user…. which is probably why you mistrust it.
A programmer may choose to use one of the several introspection tools, but even then most of the traffic seems to be RPC rather than streams.
Nifty tool to take a painfree peek into the murky world of dbus is called “d-feet”.
That said, a major weakness of shells is the need to start and shutdown literally millions of instances (of often the same) executable, and indeed often of themselves! This is sort of the realm in which dbus and systemd reign king. They know what needs to be alive (and kept alive) when.
Been using bash for years, with pretty much default config apart from a slightly more informative prompt. Default install on debian, v4+ with GNU coreutils from homebrew on Mac. It’s everywhere and it just does what you expect, even if that’s because you’ve learned to expect it to do that ;-) Also for scripts I love its idiosyncracy and general nuttiness, and I think evolutionary artefacts like esac and fi are hilarious and cute and remind us poignantly of a different time.
All the fish love on this thread has prompted me ¯\_(ツ)_/¯ to look into that, and it seems great. I really like stuff that you can get a lot out of just by using the defaults and learning some options, rather than having to configure or customize it to do what you want. Will probably spend a bit of time learning some of what it can do. Thanks!
On OpenBSD, ksh. On Ubuntu, bash. On Windows either cmd.exe or the bash that comes with Git for Windows. Basically I’m just using the default shell on every operating system with the exception on Windows since cmd.exe is somewhat limited.
bash everywhere, started using Linux a long time ago (not as long as other people here though) and with time accumulated few scripts, utility functions, custom prompt, etc. now i am used to the work flow and can easily git clone my dotfiles.
When i recently got a mac, first step was install homebrew second was bash. Surprisingly bash is still case sensitive on the mac which is good.
I believe the default filesystem on OS X is case insensitive and zsh uses that i.e. you can cd abc when the folder name was Abc but with bash you have to type cd Abc.
caveat i haven’t used zsh on the mac but i am pretty sure the filesystem doesn’t differentiate on the bases of character case.
I was a zsh user for many years, but a few months ago I changed to use eshell
(the Emacs shell written in Emacs Lisp) or fish if I need a “real” terminal.
Eshell has the benefit that it is TRAMP aware, and you take your environment
with you wherever you go. (So all aliases etc follow you around to remote
servers.) A consequence of the TRAMP awareness is that remote files are opened
in my local editor, with all the syntax highlighting and key combinations I am
used to.
I love Fish’s autocompletion, and config machinery (type fish_config at the
CLI), and its functions rather than aliases, but I do sorely miss !$ and
!! from zsh and friends.
zsh with oh my zsh on iTerm2 and bash on default Terminal app (on OS X)
I like this zsh theme which shows me everything about current git repo I am working and keeps me sane. I haven’t explored any others and stuck with this one.
I use fish currently – it has a little bit of an uncanny valley problem, in that it’s unPOSIXy enough to trip my sh reflexes up, while at the same time being sufficiently POSIXy to annoy me. But it works well out of the box and my days on this earth are now too short for me to be spending them on shell configuration. I used to use zsh, when I had a much higher tolerance for stupid shell tricks; my first shell was ksh (on Irix of all things) – nobody in my first Unix lab would touch csh, because it is horrible.
Since I may have broken myself of sh style flow control syntax, it may be time for me to take another shot at living in eshell instead.
bash - it’s usually the default on most Linux systems, and it works well for my purposes. I think it might be interesting to learn a “better” shell one day, but I’ve not yet felt enough pain to invest a lot of time into trying to learn tcsh or zsh or fish or whatever.
GNU bash, version 4.3.42(1)-release (x86_64-unknown-linux-gnu)
I like it because it’s reliable, has a wealth of community lore, it gets in my way less than the others, and most importantly it’s the one I know best.
How it’s like for interactive use (prompt, completion…);
How it perform for executing script (performances, programming features…).
For the former, I don’t really know what’s the best. I’ll say bash and zsh have completion for many commands.
For the latter, I advise you to use a POSIX compatible shell (fish is not). I use dash and ash for this, as they are really fast, while still being POSIX compliant. Bash has more scripting features than what POSIX describes, but using them breaks compatibility for other shells. As bash scripts are very frequents, most OSes and distros have bash installed. And bash is slower.
To choose a shell for a script, you can either call it on the command line:
$ name-of-the-shell path/to/the/script.sh
Or you can use a shebang as the first line of the script:
#!/bin/name-of-the-shell
Usually:
#!/bin/sh
And then start the script by calling its path.
But unfortunately, on many distros, #!/bin/sh is a link to /bin/bash, so while calling #!/bin/sh, even if dash or ash or other are installed, it’s bash that is executed, and is slower. If you want another, you will have to relink sh to /bin/dash or whatever shell you want.
bash mostly. mksh in a couple of places (used to use it more), and plain ol' /bin/sh in several FreeBSD jails (which I think is a derivative of the Almquist shell).
bash, with a few fripperies to get a fancy looking prompt and everything else on the shell I do is perl and gnu tools. I have always meant to try zsh for better completion, but after two decades, most commands are second nature and typing speed isn’t much of a factor. I do frequently crave better tools for directory and history navigation, though.
I use zsh with pretzo (I used oh-my-zsh for a brief while, but it was too bulky) in iTerm2 on OSX.
On Windows I use msys2 :S although I might give Babun a closer look. Once on Windows 10 at work, I’ll probably get on the Ubuntu bash.
mksh since it does what I need it to do and is lighter weight than bash. The only time I’ve had issues with it are with scripts that require bash-specific features like rvm, but apart from that it just works like a lighter bash.
First I used csh, because that’s what the sysadmins gave me.
Shortly thereafter, tcsh.
Then I decided that writing scripts in Bourne shell and having a completely different dialect at the prompt was ridiculous (hello fish). pdksh had no !!, and I didn’t like bash for some reason, so I went with zsh and never looked back.
I don’t see the value to use heavy shell configuration frameworks, especially oh-my-zsh that thinks it’s an OS and includes an auto-updater (soon to come: oh-my-virus-scanner!). I just looked in my .z* files, and they basically:
tset and stty
autoconfigure a reasonable PATH for almost any post-1990 Unix
find Go and Java and set the appropriate environment variables
set some environment variables, prompt, precmd, aliases and shell options
fight with /etc/profile.d in modern Linux distros that try to reset my PATH and locale
and leave completions to the OS/distro maintainers. I can’t expect the frameworks to help me with (1); (2) has been crafted to my liking over millenia; (3) is stupid anyway; (4) is a collection of trivial snippets at best; and (5) would probably only get worse.
I use zsh mostly. I originally switched because I was looking for less GPL in my life, but stayed for the better tab completion. I pretty much only write POSIX-compliant shell scripts (I’d rather use an actual programming language if I need anything more complicated), so I’m not terribly attached; I’ve got a setup I like that works with OpenBSD, OS X, and Linux, so that’s really what’s keeping me. I’ve been trying fish on and off, used rc and ksh in the past.
try to be shell agnostic as much as possible, since I’m a bit too lazy to move my dot files everywhere I login. The future of commandlines will be exciting as they start predicting a lot more, or start helping us express complex stuff that quickly gets too complicated to do properly / safely in the varieties of shell syntax today
I wouldn’t say that I like it, but I think I would similarly dislike anything else, and it’s not the part of my environment I’m focused on customizing recently.
zsh - I use it everywhere I can, otherwise bash or ksh. I switched to zsh in the late 90s, when bash still had very basic completion. I’m still using basically the same set of dotfiles today, albeit with lots of tweaks.
I’m mostly shell agnostic, as I have everything in my .profile, read by all shells.
I use alias, functions, environment variable, customize my prompt… and do not feel the need for more!
Then every shell suits me, and I can even use everything on busybox’s ash (my current shell).
If I really want to, I still can use a fancy prompt, by having a .bashrc, .zshrc, .mkshrc… in addition of the .profile.
So I advise you to use .profile for everything that is not specific to your shell!
bash - tried csh and ksh back in the day; may give zsh a try before too long.
Also, I am steadily making notes and plans towards developing a new shell, but there’s at least two-three years of projects in front of it in my queue.
Don’t remember. Got ~200k elisp in my dotfiles plus other stuff. Have to use bash for a bit to remember. Think it has to do with making the completion less gormy.
I don’t really remember things since I started on the book a year and a half ago.
On Unix(-like): zsh as a preference but I maintain a bash configuration as well given the latter’s near omnipresence. I tried fish as well a while ago but stopped using it. I need to revisit it as I definitely feel I haven’t given it the attention it deserves.
On Windows: PowerShell with Command Prompt as a fallback. The latter mainly when I need to use complex native Win32 CLI tools as the different shell semantics can make getting the escaping right when invoking via PowerShell a real pain.
EDIT: Sharing our shell configurations so we can learn from each other’s feels at least as useful as sharing our shell preferences so here are mine for any who are curious: https://github.com/ralish/dotfiles
I have used zsh for time being, but there were parts incompatible with bash scripts I use. So I’m back to bash with very spartan setup. I mostly use Linux via Vagrant (on OS X).
I used to use fish, but I switched back over to zsh with ohmyzsh. I use konsole as my terminal emulator, as it supports ligatures provided by Pragmata Pro.
fish with essentially zero configuration (some aliases and environment variables). It’s great out of the box and makes living in the shell all day even more pleasant. I don’t install it on servers – I just revert to bash there.
bash- It’s simple and it works everywhere.Used to use
zsh, but realized that I didn’t use enough of it’s features to justify the configuration and context switching overhead.bash can be made to do almost everything that zsh can do, just requires a lot more configging.
I use the borne shell as in
/bin/shfor that same reason, however:/bin/bash– I just don’t use bash-features except line editing and I’m just as happy to userlwraporemacsinstead.control-Rand type some distinct portion so that even if I have done things in the meantime, it’ll still work (because I’m still in the same directory).export foo=whateverin my history, because if I want the environment changed in my session I will edit~/.profileand source it, and if I just want it for a particular invocation, I’ll writefoo=whatever commandso that the environment is just changed for runningcommand. This has a similar property in that if I want to run the command again I can search for it (and it won’t necessarily have to be ordered).fish, with http://fisherman.sh/.
I love the typeahead autocompletion and the simplified/reduced syntax & configuration. The fact that it’s not POSIX-compliant isn’t usually an issue since I just use plugin-foreign-env to run scripts in bash when necessary (e.g. for nvm).
The design principles of fish shell: https://fishshell.com/docs/current/design.html
Also fish and for the same reasons spencer mentioned.
My history with shells: sh/ksh/csh/whatever-pre-bash-sh, bash, zsh and now fish.
Scripting is not an issue (you do use “#!/path/to/shell” in your scripts, right?) and POSIX-compliance isn’t either.
Fish to me feels like to i3 of shells. i3 the window manager needs very little configuration to do what you’d expect and it’s the same for fish (instead of needing tons of config like zsh). I always used to be the kinda guy that wanted endless customization and configurability and I still sorta do but sane defaults have become important to me as well.
Why would zsh need a lot of configuration?
I’m wondering if people assume that oh-my-zsh is somehow necessary to make zsh work. If that’s the case, then yes, that’s a ton of config.
I used fish until last week, and now use zsh. The zsh-autosuggestions and zsh-syntax-highlighing plugins emulate the behaviours from fish that I care about. Day to day I use an unholy amount of ad-hoc shell logic, and running bash to do the more complex stuff started annoying me. The exact thing that pushed me over the edge was wanting to loop over
thing{2..27}. While there is probably a way to do it in fish, I already know how to do it in bash/zsh.I’ve used fish since the 2.0 release, and still use it on my home laptop.
I use zsh, and like it well enough, but I’m not enough of a shell power user to give a detailed endorsement. I originally switched some years ago because its tab-completion was better than bash’s, both in that it shipped with many more completions, and the completion language was nicer to use for writing more. The Debian maintainers also do a good job ensuring that the completions are in sync with what various Debian packages do with their binaries.
Beyond completions, the feature I probably use most on a regular basis is the multi-line line editor. Many shells let you write multi-line commands in the REPL, but zsh also lets you edit such commands in the history. For example, if you write something like
run it, then hit up-arrow to go back and edit it, in zsh it’s still on multiple lines and you can edit them, while bash presents you a version that’s been smooshed into a one-liner.
The extended globbing can also be nice, though it’s huge and there are only a handful of features I remember enough to use.
Indeed, i get annoyed when I have to use find generally.
I tend to do ls -dal /file a LOT
More fun, list all symlinks: ls *(@)
Take that expansion, restrict to directories: ls -dal /name(/)
Or files ls -dal /name(.)
Empty files: ls -dal */(L0)
Files > 1 meg: ls -dal */(Lm+1)
Stuff modified in last hour: ls -dal */(mh-1)
It is a really damn convenient way to not deal with find and multiple predicates. Hell you can combine qualifiers, aka files > 1 meg modified in the last hour: ls -dal */(.mh-1Lm+1)
Also multi line history editing is what made me switch to zsh years ago. At the time ksh just threw ^J’s in, aka useless, and bash did the same back then. Bash is better now but its still years behind zsh in the “holy hell what can’t this stupid shell do” department.
[Comment removed by author]
What does the second number mean? And why does scsh have three of them?
You’re a good man/woman/cat.
[Comment removed by author]
eshell, because I can extend it in Emacs Lisp, and life is to short to learn another badly-designed language just for customizing your shell. Piping shell commands straight to an Emacs buffer or lisp function is a nice bonus though.
[Comment removed by author]
True, but you can add these to a list so they automatically spin off their own specialized terminal emulator buffer automatically even when run from eshell.
Even so I hardly use this, since it’s so rare to find a curses-style program that doesn’t have an alternative interface implemented better in elisp.
eshellis sorely lacking input redirection. How do you stand it/get around something like that?I switched to zsh from bash several years ago, for several useful features:
I’ve been using zsh for a long time, but I don’t really use push-line. Instead, I tend to do C-a C-k, run the other command, then C-y. Or, if in vi mode, ESC 0 d$, run the command, followed by ESC p.
2 and 6 exist in bash too. 3 can be easily achieved by putting a # at the start of the command you want to run later.
You can do that in Bash by putting ‘erasedups’ in HISTCONTROL. I also want commands that start with a space to be ignored by the history, so I have this in my ~/.bashrc:
mksh. It’s a bit more of a feature-light shell thanbashbut feels more swift. Perfect for my tastes.bash, because there’s hundreds of servers in $EMPLOYER’s fleet and it’s annoying enough to remember
set -o vievery time I connect to one, never mind having togit clonea custom config. Downloading and building a new shell is right out.If I didn’t have that restriction, I’d like to try fish, or even rc.
rc is a small-ish binary clocking in at 332K on an ubuntu build. You can definitely build it statically and copy it along for your sanity.
rc also usually means you have no config. set -o vi means using rc probably will be very frustrating for you though.
A static build using musl is actually 79k here.
I use
tcshpretty much everywhere, specifically, with the history search as configured by default on FreeBSD (bindkey -k up history-search-backward).http://bxr.su/FreeBSD/share/skel/dot.cshrc#39
http://bxr.su/FreeBSD/etc/root/dot.cshrc#39
Interestingly, back in the college days and on Sun Solaris, I’ve spent quite some time trying to compile a newer version of tcsh from source code, trying to make it do the history search the way I enjoyed it on FreeBSD (was it one of those compile-time options as presented in
$version, likefilec, I thought to myself?), until finally finding out that it was a.cshrcconfiguration option.The official tcsh faq even has an entry about the phenomenon:
http://www.tcsh.org/FAQ
zsh with this: https://grml.org/zsh/
Me too. To this day I havent really looked at what GRML is. But I use their zsh config everywhere. It is the best ;)
I like their no-bullshit tmux.conf file too.
mksh, because it is extremely simple. It only auto-completes file paths and it helped me learn most UNIX commands better. Because of its limited feature set, it encourages me to write POSIX sh scripts. Also, it is very lightweight and fast.In my dreams….. I use a shell not yet written.
Unlike existing shells, it moves seamlessly from creating unmaintainable one-liners optimized for minimal keystrokes, as they grow, into beautiful maintainable programs.
Like existing shells, but completely unlike most scripting languages, much of it’s power arises from decomposing problems into communicating processes, rather than modules.
Unlike existing shells, the interface definition language between processes is strict and formally specified, and human readable when a human looks at it or writes it, and binary when passed between processes.
Unlike existing shells, the options and arguments are not unspecified text strings, but again, in that strict IDL.
Like existing shells, when I’m at a command line, it does as much as possible to save me keystrokes.
Unlike existing shells, understanding of paths, files, filesystems is baked in, not merely half-baked in.
Unlike existing shells, it has a “did you mean it mode”, that will run the command in a fundamentally “read only” safe mode…. allowing you to see what the effect would be. And then allowing to rerun it in destructive mode.
Unlike existing command lines, it is not a infinite ticker tape of fire and forgotten text. But a curated and maintained conversation. Where previous snippets can always be named, recalled, rerun.
Very similar list of features to my own dream shell. A lot of work to get there from here, though.
Yes and no.
Like the sign at the top of a Ladder…. “Start Other Side”.
I’d start with an existing decent language with a very fast compile/link/run cycle.
I’d then define a decent IDL.
I have a horrid suspicion that may be predetermined.
ie. Whatever dbus / systemd / kdbus uses.
99% of what we want is already in dbus, the rest is coming with systemd and kdbus.
Program options and stdin / stdout interfaces and pipes are merely pale shadows of what dbus does.
The only problem is “Time To First Hello World” with dbus is way way too long. The integration with the “tiny tools” ie. coreutils, is non-existent.
The core to solving the problem is smooth that away. ie. Creating a dbus hello world should become as easy as…
I’d then go through all the coreutils and “wrap” them. ie. Provide an IDL defined interface to their options / arguments, and where appropriate reimplement them to chew on streams defined in the IDL instead of loosely defined text records.
ie. The plan of attack would be….
Items 1 and 2 exist. It’s called D and rdmd.
Interesting approach. I see how this would eventually extend to cross-language use, which is good, because it needs to.
I don’t know a lot about dbus and am nervous about it, but I see your point that it already occupies related niches.
I can understand the nervousness.
But look at it this way.
If you could roll back time to The First Shell.
But this time have all the tools and power you need.
Would you have left your definition of IPC as environment variables (Hash from String to String), (argc, argv[]) Vector of null terminated strings and stdin,stdout, stderr?
Sure that is very powerful and flexible.
But it’s slow as paste and remarkably error prone. Need I list the ways? I can, but it would be a looong post.
You don’t need to sell me on that. Environment variables are invisible nonlocal state, and from a security-oriented perspective in 2016, they seem like the curse that keeps on giving. And I would really, really like a shell that could programmatically pull out relevant snippets of documentation, as I enter parameters. And one that doesn’t build all its core functionality around nested string escaping.
I’m nervous about dbus as the choice, because I have strong opinions on type systems, and I know nothing about the dbus architecture in general except that on my personal machines, it seems to either break or work fine, without a lot of manual configuration either way.
Hah! Dead right! That’s one of the strong points of dbus (and kdbus) is a lot of thought has been put into security aspects.
Alas, that’s a fundamental stumbling point.
You can’t afford to have too strong opinions as every computer language on the planet already has it’s own (equally strong, if not stronger) opinions.
One of the reasons I suggest dbus, is it clearly has hit a pragmatic compromise amongst those opinions.
One of the existing problems with dbus is it’s opaque to the ordinary user…. which is probably why you mistrust it.
A programmer may choose to use one of the several introspection tools, but even then most of the traffic seems to be RPC rather than streams.
Nifty tool to take a painfree peek into the murky world of dbus is called “d-feet”.
That said, a major weakness of shells is the need to start and shutdown literally millions of instances (of often the same) executable, and indeed often of themselves! This is sort of the realm in which dbus and systemd reign king. They know what needs to be alive (and kept alive) when.
I take your point. :)
I will look into d-feet whenever I look into dbus, thank you.
Been using
bashfor years, with pretty much default config apart from a slightly more informative prompt. Default install on debian, v4+ with GNUcoreutilsfromhomebrewon Mac. It’s everywhere and it just does what you expect, even if that’s because you’ve learned to expect it to do that ;-) Also for scripts I love its idiosyncracy and general nuttiness, and I think evolutionary artefacts likeesacandfiare hilarious and cute and remind us poignantly of a different time.All the
fishlove on this thread has prompted me ¯\_(ツ)_/¯ to look into that, and it seems great. I really like stuff that you can get a lot out of just by using the defaults and learning some options, rather than having to configure or customize it to do what you want. Will probably spend a bit of time learning some of what it can do. Thanks!I use bash, because it was the default. I have not tried any other shells yet.
Same here, but the comments in this thread provide a lot of inspiration.
On OpenBSD, ksh. On Ubuntu, bash. On Windows either cmd.exe or the bash that comes with Git for Windows. Basically I’m just using the default shell on every operating system with the exception on Windows since cmd.exe is somewhat limited.
basheverywhere, started using Linux a long time ago (not as long as other people here though) and with time accumulated few scripts, utility functions, custom prompt, etc. now i am used to the work flow and can easily git clone my dotfiles.When i recently got a mac, first step was install homebrew second was bash. Surprisingly bash is still case sensitive on the mac which is good.
Can you explain what you mean?
I believe the default filesystem on OS X is case insensitive and zsh uses that i.e. you can
cd abcwhen the folder name wasAbcbut with bash you have to typecd Abc.caveat i haven’t used zsh on the mac but i am pretty sure the filesystem doesn’t differentiate on the bases of character case.
There doesn’t seem to be any difference in behaviour between zsh and bash on OS X (Yosemite, zsh and bash from Homebrew):
By default, the OS X filesystem is case-preserving, but not case-sensitive. It has the option to be case-sensitive if you want, though.
i stand corrected, it’s only for autocomplete then.
I was a zsh user for many years, but a few months ago I changed to use eshell (the Emacs shell written in Emacs Lisp) or fish if I need a “real” terminal.
Eshell has the benefit that it is TRAMP aware, and you take your environment with you wherever you go. (So all aliases etc follow you around to remote servers.) A consequence of the TRAMP awareness is that remote files are opened in my local editor, with all the syntax highlighting and key combinations I am used to.
I love Fish’s autocompletion, and config machinery (type
fish_configat the CLI), and its functions rather than aliases, but I do sorely miss!$and!!from zsh and friends.It’s from csh. Perhaps the only worthy thing to come out of csh. And yes, I love it.
Oh, thanks. I didn’t know where those variables originated. I should have put “… !$ and !! that I am used to from zsh and friends” perhaps.
zsh with oh my zsh on iTerm2 and bash on default Terminal app (on OS X)
I like this zsh theme which shows me everything about current git repo I am working and keeps me sane. I haven’t explored any others and stuck with this one.
zsh, of course!
zsh power user, my config: http://chneukirchen.org/dotfiles/.zshrc
zsh. If fish was more UNIX-compliant, I’d use it all the time. If bash was more user-friendly, I’d use it.
Bash is usually the path of lease resistance, but I continue to use rc shell
I use fish currently – it has a little bit of an uncanny valley problem, in that it’s unPOSIXy enough to trip my sh reflexes up, while at the same time being sufficiently POSIXy to annoy me. But it works well out of the box and my days on this earth are now too short for me to be spending them on shell configuration. I used to use zsh, when I had a much higher tolerance for stupid shell tricks; my first shell was ksh (on Irix of all things) – nobody in my first Unix lab would touch csh, because it is horrible.
Since I may have broken myself of sh style flow control syntax, it may be time for me to take another shot at living in eshell instead.
Oh, it’s a simple shell that’s designed around scheme.
bash - it’s usually the default on most Linux systems, and it works well for my purposes. I think it might be interesting to learn a “better” shell one day, but I’ve not yet felt enough pain to invest a lot of time into trying to learn tcsh or zsh or fish or whatever.
I like it because it’s reliable, has a wealth of community lore, it gets in my way less than the others, and most importantly it’s the one I know best.
I see two things to compare:
For the former, I don’t really know what’s the best. I’ll say
bashandzshhave completion for many commands.For the latter, I advise you to use a POSIX compatible shell (
fishis not). I usedashandashfor this, as they are really fast, while still being POSIX compliant. Bash has more scripting features than what POSIX describes, but using them breaks compatibility for other shells. As bash scripts are very frequents, most OSes and distros have bash installed. And bash is slower.To choose a shell for a script, you can either call it on the command line:
Or you can use a shebang as the first line of the script:
Usually:
And then start the script by calling its path.
But unfortunately, on many distros, #!/bin/sh is a link to /bin/bash, so while calling #!/bin/sh, even if
dashorashor other are installed, it’sbashthat is executed, and is slower. If you want another, you will have to relink sh to /bin/dash or whatever shell you want.bash mostly. mksh in a couple of places (used to use it more), and plain ol' /bin/sh in several FreeBSD jails (which I think is a derivative of the Almquist shell).
[Comment removed by author]
bash, with a few fripperies to get a fancy looking prompt and everything else on the shell I do is perl and gnu tools. I have always meant to try zsh for better completion, but after two decades, most commands are second nature and typing speed isn’t much of a factor. I do frequently crave better tools for directory and history navigation, though.
zshon machines I physically touch (laptops). Originally via oh-my-zsh, now with my own zshrc configuration.bashon machines I touch via SSH, both$workones and personal ones.I use zsh with pretzo (I used oh-my-zsh for a brief while, but it was too bulky) in iTerm2 on OSX. On Windows I use msys2 :S although I might give Babun a closer look. Once on Windows 10 at work, I’ll probably get on the Ubuntu bash.
zsh ftw!
mkshsince it does what I need it to do and is lighter weight thanbash. The only time I’ve had issues with it are with scripts that require bash-specific features likervm, but apart from that it just works like a lighterbash.Bash. It’s everywhere and I’ve been using it for almost 20 years. Too much inertia to change.
First I used
csh, because that’s what the sysadmins gave me.Shortly thereafter,
tcsh.Then I decided that writing scripts in Bourne shell and having a completely different dialect at the prompt was ridiculous (hello
fish).pdkshhad no!!, and I didn’t likebashfor some reason, so I went withzshand never looked back.I don’t see the value to use heavy shell configuration frameworks, especially
oh-my-zshthat thinks it’s an OS and includes an auto-updater (soon to come:oh-my-virus-scanner!). I just looked in my.z*files, and they basically:tsetandsttyprecmd, aliases and shell options/etc/profile.din modern Linux distros that try to reset my PATH and localeand leave completions to the OS/distro maintainers. I can’t expect the frameworks to help me with (1); (2) has been crafted to my liking over millenia; (3) is stupid anyway; (4) is a collection of trivial snippets at best; and (5) would probably only get worse.
I use zsh mostly. I originally switched because I was looking for less GPL in my life, but stayed for the better tab completion. I pretty much only write POSIX-compliant shell scripts (I’d rather use an actual programming language if I need anything more complicated), so I’m not terribly attached; I’ve got a setup I like that works with OpenBSD, OS X, and Linux, so that’s really what’s keeping me. I’ve been trying fish on and off, used
rcandkshin the past.OpenBSD’s
kshon OpenBSD,mkshon Linux.zsh with oh-my-zsh & bash,
generally “scripting” in bash not zsh.
try to be shell agnostic as much as possible, since I’m a bit too lazy to move my dot files everywhere I login. The future of commandlines will be exciting as they start predicting a lot more, or start helping us express complex stuff that quickly gets too complicated to do properly / safely in the varieties of shell syntax today
I use mksh when I want an interactive shell, and rc or es when I write scripts.
Just
bash, nothing interesting.I wouldn’t say that I like it, but I think I would similarly dislike anything else, and it’s not the part of my environment I’m focused on customizing recently.
zsh- I use it everywhere I can, otherwisebashorksh. I switched tozshin the late 90s, whenbashstill had very basic completion. I’m still using basically the same set of dotfiles today, albeit with lots of tweaks.[Comment removed by author]
Most of the time I use zsh running in tmux.
Occasionally eshell when I’m in Emacs and it’s convenient, but tmux with multiple zshs is too convenient to use eshell all the time.
I’m mostly shell agnostic, as I have everything in my
.profile, read by all shells. I use alias, functions, environment variable, customize my prompt… and do not feel the need for more!Then every shell suits me, and I can even use everything on busybox’s
ash(my current shell).If I really want to, I still can use a fancy prompt, by having a
.bashrc,.zshrc,.mkshrc… in addition of the .profile.So I advise you to use
.profilefor everything that is not specific to your shell!zsh
bash - tried csh and ksh back in the day; may give zsh a try before too long.
Also, I am steadily making notes and plans towards developing a new shell, but there’s at least two-three years of projects in front of it in my queue.
zsh, mostly for this https://github.com/bitemyapp/dotfiles/blob/master/.zshrc#L14-L16
Care to explain what those lines do? :)
Don’t remember. Got ~200k elisp in my dotfiles plus other stuff. Have to use bash for a bit to remember. Think it has to do with making the completion less gormy.
I don’t really remember things since I started on the book a year and a half ago.
On Unix(-like):
zshas a preference but I maintain abashconfiguration as well given the latter’s near omnipresence. I triedfishas well a while ago but stopped using it. I need to revisit it as I definitely feel I haven’t given it the attention it deserves.On Windows: PowerShell with Command Prompt as a fallback. The latter mainly when I need to use complex native Win32 CLI tools as the different shell semantics can make getting the escaping right when invoking via PowerShell a real pain.
EDIT: Sharing our shell configurations so we can learn from each other’s feels at least as useful as sharing our shell preferences so here are mine for any who are curious: https://github.com/ralish/dotfiles
I have used zsh for time being, but there were parts incompatible with bash scripts I use. So I’m back to bash with very spartan setup. I mostly use Linux via Vagrant (on OS X).
On OpenBSD I use ksh. On my workstation at work, I use mksh.
I used to use
fish, but I switched back over tozshwithohmyzsh. I usekonsoleas my terminal emulator, as it supports ligatures provided by Pragmata Pro.The default -
pdkshis nice enough, andbashis inoffensive enough.Fish!
I used to use zsh, but I mostly use mksh these days.
ksh and bash
zsh
fishwith essentially zero configuration (some aliases and environment variables). It’s great out of the box and makes living in the shell all day even more pleasant. I don’t install it on servers – I just revert to bash there.bash + https://github.com/chilicuil/shundle