zsh, I've used oh-my-zsh and a custom theme for so long that I can't use anything else

i also use zsh for the terminal. I really like the vim mode.
For scripting i use Bash.

any readline-linked shell can have vim mode. just use the CTRL-ALT-j key to enter vim mode from bash or rc and voila, vim mode. Also in bash, 'set -o vi' will take you into vim mode. while in vim command mode, CTRL-e will take you back to emacs editing mode.

@robotchaos awesome, thanks! I'll try this!

(24-04-2017, 02:33 PM)robotchaos Wrote: any readline-linked shell can have vim mode. just use the CTRL-ALT-j key to enter vim mode from bash or rc and voila, vim mode. Also in bash, 'set -o vi' will take you into vim mode. while in vim command mode, CTRL-e will take you back to emacs editing mode.

That was the command that brought me back to bash, since the only thing I really loved about zsh was the vi mode.

dcat made me switch away from vi mode. I hated him at first, now I'm sold!

I love vi's modes, it makes text edition really powerful and convenient, but for line edition, it is a waste of time. In vi, you spend most of the time in normal mode, while in term, you're in insert mode 90% of the time. This makes using normal mode inneficient and tiresome. It took me a few weeks to assimilate the readline basic moves (M-f, M-b, ...) but it is definitely worth it!

(25-04-2017, 06:11 AM)z3bra Wrote: I love vi's modes, it makes text edition really powerful and convenient, but for line edition, it is a waste of time. In vi, you spend most of the time in normal mode, while in term, you're in insert mode 90% of the time. This makes using normal mode inneficient and tiresome. It took me a few weeks to assimilate the readline basic moves (M-f, M-b, ...) but it is definitely worth it!

Same here, I switched away from vi mode but for another reason: I want to keep things vanilla.

I'm sshing into a bunch of machine and I thought it would be better to just get accustomed to the default keybinds instead of vi.

Also a misconception I had about those keybinds is that they are "terminal keybinds" and not "Emacs keybinds", though some of them are in fact Emacs too, like the M-f and M-b. Most of the others are just plain line-discipline interpretation.

These days I'm using zsh but for only one feature: the explanation of the command line arguments on completion.
For the rest I'm using whatever comes on the machine (except C shells).

@venam, i did for the same exact reason. i also use the default emacs mode. i tend to spend a lot of time on a lot of different servers, and the default is emacs mode on every single one of them. so instead of always switching to vi-mode, i decided to learn the default. it has the added benefit of getting me used to applications that are also readline capable. this way i can use C-a to go to the beginning of the line, C-e to go to the end, M-backspace to delete a word with separator back, C-w to delete a full word back, C-p for previous history, C-n for next history, etc. it is all so very helpful. (could also use vi-mode within a cli app, but would have to change the mode there as well)

except when you get so damn used to these keybindings, and you attempt to delete the last word you're typing in a reply on the forum using C-w...

but the defaults are why i also use bash everywhere except my personal laptop. it is the default shell on all of our servers. and i follow where the wind blows, or something like that

(25-04-2017, 06:11 AM)z3bra Wrote: It took me a few weeks to assimilate the readline basic moves (M-f, M-b, ...) but it is definitely worth it!

Yesssss... Goooood... Glad you're finally starting to see the light.

yeah you can learn a lot reading readline(3)

while using emacs-mode as the default one, you always can construct long expressions with "C-x C-e" (the default editor will start with current text, save-n-quit will execute the command, even multiline)
this covers 146% cases [for me]

zsh on my laptop (because of nice features)
ksh on my servers (running openbsd)

A late update:

jkl Wrote:ksh93 everywhere because of POSIX.

I have actively decided to use different shells for scripting and interactive use for quite a while now and I have come to the conclusion that standard compliance does not matter for the latter at all. My shell scripts usually point to the bosh wherever I can compile it so I can be sure that they are relatively portable to anything that implements POSIX, just in case.

Interactive shells are a different thing though. The maximum "scripting" I do without writing a complete script file is looping over a set of files, so the scripting language is neglegible. The more important feature is the ability to find stuff in my history. One of the longest non-scriptable command lists which I regularly need consists of six commands and has different parameters towards the end, so finding it easily after a week of doing other shell work would be a good thing.

As I found myself using a different shell on almost all of my (non-Windows) machines, I am currently re-evaluating my options. macOS uses the zsh by default now, and as I spend more and more time on macOS, I gave it another try only to find that it is quite annoying to use as it tries to be smart and it really should not. I tried the ksh2020 today, but it is really the opposite of stable just yet. Too bad!

My preferred shell should

• draw in as little additional dependencies as possible,
  
• be a suitable interactive shell, i.e. not optimized for pure non-interactive use (sorry, bosh and rc!),
  
• have acceptable globbing, tab-completion and history functionalities,
  
• have a relatively fast startup time and a low resource usage (sorry, zsh and PowerShell!),
  
• be in a mature state, not a "technical preview" anymore (sorry, nushell!),
  
• come without any VCS integration out of the box or make it easy to get rid of that (showing your repository state is not a shell prompt's job in my opinion),
  
• generally be configurable in a way that does not piss me off while using it,
  
• be portable so I won't have to think about which shell I use every time I ssh into a different non-Windows system.
  

After checking the usual repositories and playing with some of them for a while, I narrowed down my selection a bit. I even included shells which I actively disliked for non-technical reasons before.


I did all of my tests in a Debian Unstable bash on Windows 10, the performance tests were done without changing any of the distribution's defaults; I temporarily renamed the .bashrc file though, so I could start from scratch.


1. Performance and resource usage


Results:


Interesting: The tcsh is roughly twice as slow as the penultimate runner, and the ksh93 even outperforms the "native" bash. What about the resource usage? I opened all shells with a $sh -c sleep 1d & and checked the vsz= output:


As you might imagine, this was my moment of getting rid of the fish shell again. I mean, wtf? The mksh's sleep weirdness will be ignored by me though. I hardly ever need an interactive "don't do anything for a while" command under most circumstances.

Let's give the other shells a spin.


2. Real-life test

For the real-life test, I did (of course) modify at least some of the defaults.

2.1. tcsh

I know, I know: The tcsh is bad for scripting and its syntax is a mess etc. etc. - hooray for the shebang, I guess. I configured some of it:


Globbing: cd */*oo* moves into "shelltest/Foo".
Tab-completion: cd sh<tab>f<tab> moves into "shelltest/Foo". Good.
History:
- Ctrl+R sh<Enter> performs cd shelltest/Foo.
- !! brings back the previous command.
- !-3 brings back whatever was three commands ago.
Dependencies (on Debian Linux): libc, libtinfo.

2.2. bash

A similar basic configuration:


Globbing: cd */*oo* moves into "shelltest/Foo".
Tab-completion: cd sh<tab>f<tab> moves into "shelltest/Foo". Good.
History:
- Ctrl+R sh<Enter> performs cd shelltest/Foo out of the box - no configuration needed.
- !! brings back the previous command.
- !-3 brings back whatever was three commands ago.
Dependencies (on Debian Linux): libc, libtinfo, base-files, debianutils.

2.3. mksh

Again, I try to bring this shell to the same level as the others in my small test:


Globbing: cd */*oo* moves into "shelltest/Foo".
Tab-completion: cd sh<tab>f<tab> fails. Case-insensitivity is not in mksh.
History:
- Ctrl+R sh<Enter> performs cd shelltest/Foo out of the box - no configuration needed.
- fc -s -- -1 brings back the previous command (no built-in shortcut).
- fc -s -- -3 brings back whatever was three commands ago (no built-in shortcut).
Dependencies (on Debian Linux): libc. Nice.

2.4. ksh93

It is safe to assume that most of what occurs with the mksh was directly or indirectly taken from the ksh... or was it? At least the completion commands need to be set up first:


Globbing: cd */*oo* moves into "shelltest/Foo".
Tab-completion: cd sh<tab>f<tab> fails. Again, there seems to be no built-in way to circumvent this which does not involve writing my own cd command.
History:
- Ctrl+R sh<Enter><Enter> - yes, that's twice - performs cd shelltest/Foo out of the box - no configuration needed.
- fc -s -- -1 brings back the previous command (no built-in shortcut).
- fc -s -- -3 brings back whatever was three commands ago (no built-in shortcut).
Dependencies (on Debian Linux): libc, binfmt-support.

3. Conclusion

I'll move on to the tcsh over the following weeks.

4. Afterword

... sorry, this has become somewhat longer than I had planned, again. You are happily invited to not have read it because of that. (All later edits were grammar fixes.)

That was really interesting, you put a lot of efforts into that !

I use mksh myself, mostly because it is light on resources, and less subject to bugs than bash or zsh (which have features I don't use anyway).
I find it interesting that you ended up using tcsh, because the syntax is REALLY different from standard POSIX shell language. It basically means learning a new shell scripting language, even though you only use it interactively and for a few use cases (looping through files, etc…). How do you feel about that ?

I haven't written a single zsh script (excluding one oh-my-zsh plugin) in my life, despite having used it on a number of systems in the past. I haven't written a single tcsh script in my life either, despite using FreeBSD on most of my servers.

In conclusion, it feels safe to assume that the shell language is entirely irrelevant for interactive use (yes, I know about the existence of the xonsh, thank you, Pythoneers). There's nothing to "learn" here, except maybe the "for ()" syntax. ;-)

I've also been using tcsh for a while now, it does everything I want. Before that I used rc but as you say it's not great for interactive use.

I agree that interactive shells shouldn't need to be standards compliant. A couple of years ago I used fish, and it didn't matter because shebangs exist! It just meant my shell was very comfortable.

I like the syntax of tcsh the best, and it has some nice features.

rc is quite awesome on Plan 9 because all of its history commands are meant to be used with mouse chords. But I couldn’t even modify its prompt easily. It was a late removal from the test above ...

Yep, rc is definitely designed to be used in its home environment. I remember seeing a project to make it decent on linux, using readline or whatever, but I can't find that now.

It's this one, usually packaged as "rc" (Debian, pkgsrc) anyway.

ksh on OpenBSD normally does the job. However, while using other systems bash is unbeatable due to its enormous scripting capabilities.
At least for me, lol.

Which scripting capabilities does the ksh lack for you?

I haven't found anything I need in bash that I can't also get in ksh93, and I prefer to avoid the GNU stuff wherever possible.

Oh, and jkl, in response to your question in another thread, I think what I was missing in mksh that sent me to ksh93 instead was associative arrays. Maybe those are in there now...

(06-06-2020, 10:48 AM)jkl Wrote: Which scripting capabilities does the ksh lack for you?

Things like for loops and arrays are better implemented on bash. However, the best ksh I ever user is from OpenBSD. Never got the Solaris or FreeBSD ksh work the same way.

You can install oksh which is (usually) the OpenBSD ksh...?

(06-06-2020, 10:38 AM)wolf Wrote: its enormous scripting capabilities.

That's interesting, so do you make use of bashisms in your shell scripts?

I try and avoid bash where possible, in equal parts for being GNU and having such a high code:feature ratio. I know that they're both ideological things and don't affect the end user at all, but are enough for me to not want to use it.

(06-06-2020, 05:15 PM)twee Wrote:

(06-06-2020, 10:38 AM)wolf Wrote: its enormous scripting capabilities.

That's interesting, so do you make use of bashisms in your shell scripts?

I try and avoid bash where possible, in equal parts for being GNU and having such a high code:feature ratio. I know that they're both ideological things and don't affect the end user at all, but are enough for me to not want to use it.

It's always cleaner to use POSIX sh in my cookbook. It's vegan.

I use OpenBSD's ksh for interactive shell and POSIX sh for scripts.
Before using OpenBSD I used zsh for interactive shell and bash for scripts.
I still miss some bashisms like creating files on-the-fly with <(command).

(06-06-2020, 04:01 PM)jkl Wrote: You can install oksh which is (usually) the OpenBSD ksh...?

So, so.
Maybe at FreeBSD ( I haven't any installation now , but I'll test it sometime ), but Solaris is something different to me in my case. I cannot use non Oracle provided packages. ='(

(06-06-2020, 05:15 PM)twee Wrote: I try and avoid bash where possible, in equal parts for being GNU and having such a high code:feature ratio. I know that they're both ideological things and don't affect the end user at all, but are enough for me to not want to use it.

(11-06-2020, 01:24 AM)banna Wrote: It's always cleaner to use POSIX sh in my cookbook. It's vegan.

(14-06-2020, 09:54 AM)phillbush Wrote: I use OpenBSD's ksh for interactive shell and POSIX sh for scripts.

You guys have a point there ... I'll meditate about it. Thanks a lot.

(18-06-2020, 03:08 PM)wolf Wrote: Solaris is something different to me in my case. I cannot use non Oracle provided packages. ='(

I admit that I hadn’t tested it on a real Solaris yet, but wouldn’t pkgsrc work?