What is your preferred Linux login shell?

qlue · 06-19-2014, 04:15 PM

I use bash only because it's the default.
It does what I need it to do. :P

André7785 · 06-20-2014, 11:55 AM

So I was obviously mislead by the query's title "....preferred Linux login shell"
and also by missing the subtleties between 'performing a login' and 'logging in' in your post,
as I would have asked "which shell is your favorite" (without login) or so.

However, I knew yet about switching shell as a possibility! Though there weren't much opportunities to do so, e.g., when checking manually skripts invoking other shells e.g.

alderson · 06-20-2014, 02:41 PM

Quote:

Originally Posted by Toadbrooks

Valid point. I've been doing Unix since 1984. I've used sh, ksh, zsh, csh, tcsh, and bash. Prior to bash, my favorite was ksh. I suppose I like bash because it's pretty much like ksh with a few extra features.

Quote:

Originally Posted by evo2

I was dumped in tsch on DEC and Solaris machines in the mid to late 90s. When I started using Linux in the early 00s I persisted with tcsh since that's what I was used to. I was however told from the beginning that I should not use csh/tsch for scripts, so I was used to looping and branching in sh but not in csh. I'd find myself sometimes typing "bash" at my tcsh prompt to do some things, which after a while lead me to actually trying bash as my login shell. It took me a while to get it set up how I liked it, but once there I was very happy. Around this time I noticed that some of the wizards were using zsh, a few years later I gave it a try and again, after getting it set up to my liking I've been very happy with - the transition from bash to zsh is trivial compared to tcsh to bash.

Like Toadbrooks, I've used sh, csh, tcsh, ksh, and bash (in chronological order--I started using Unix in 1982 on a Pyramid 90x in both the att (System III/System V) and bsd universes where I much preferred csh to sh). Moving on to Ultrix-32, SunOS3&4 (I skipped Slowaris), AIX, and MIPSos, I became a tcsh bigot (at one time, I was quoted in the man page for tcsh in the history of the shell; I don't know whether that's still part of the man page). Eventually, I was exoosed to ksh on HP 9000/800 systems (SVR2) and began the painful transition away from tcsh, though I still used that at Netcom. Eventually, I decided to try bash at Netcom, given its similarity to ksh, and after the Great Netcom Exodus to Panix I specified bash as my preferred shell.

Whenever I set a Linux server to run some project at the museum, I use bash--not because it's the default but because it's my preferred environment.

zsh has never seemed like it would give me much that bash doesn't; on the other hand, I still (20 years on) miss (t)csh's command history editing tools which are to my way of thinking much more intuitive than those in ksh and bash.

Rich Alderson

tronayne · 06-20-2014, 04:04 PM

Quote:

Originally Posted by alderson

... I still (20 years on) miss (t)csh's command history editing tools which are to my way of thinking much more intuitive than those in ksh and bash.

Nice post, interesting history (quite similar to mine in many ways).

Being a vi/ex bigot (and a ksh bigot), command line editing is a simple as press the up arrow (or esc-k), /pattern or k k k k (or up up up up) until you get there, then use vi editing till you're happy and whack the return key.

Personally, I've never been able to figure out BASH's editor, it always looked like an emacs editor to me and, well, to hell with emacs. For me vi/ex is intuitive, emacs is sanskrit upside down in a mirror or something. You just set the VISUAL environment variable to VISUAL=vi.

No accounting for taste, eh?

astrogeek · 06-20-2014, 04:13 PM

Quote:

Originally Posted by tronayne

Being a vi/ex bigot (and a ksh bigot), command line editing is a simple as press the up arrow (or esc-k), /pattern or k k k k (or up up up up) until you get there, then use vi editing till you're happy and whack the return key.

You can improve that a bit by defining history-search-backward and history-search-forward in your /etc/inputrc or ~/.bashrc.

With that you can type a few characters then show only matching history lines - a very convenient extension to history recall and edits.

I usually map them to my pgup and pgdn keys. From my /etc/inputrc:

Code:

# PgUp/PgDw cycles trough history only for matching entries
"\e[5~": history-search-backward        # Previous
"\e[6~": history-search-forward         # Next

Drakevr · 06-20-2014, 05:23 PM

Quote:

Originally Posted by tronayne

Personally, I've never been able to figure out BASH's editor, it always looked like an emacs editor to me and, well, to hell with emacs.

It didn't look like emacs, it IS emacs mode

drlasterjr · 06-20-2014, 05:39 PM

I have used a variety of shells over the years and the Bourne shells have been the best in features and usability. They are also the most consistent for making support scripts that can used on both Unix and Linux based systems. And when one learns the syntax, it is not that hard to learn, it allows for significant and functional scripts to be written without needed a bunch of other tools and files.

charging-ibis · 06-21-2014, 10:51 AM

I am used to bash and that is the one required for me to be Linux certified.

cbk · 06-22-2014, 05:06 AM

tcsh, with bash as close 2nd
For scripting, I usually stick to sh for portability because its feature set is the most ubiquitous (when including ash, ksh and bash)

cyent · 06-22-2014, 04:38 PM

Quote:

Originally Posted by astrogeek

Your understanding of what it is, what it does and why it is as it is, are exactly backward! It is an interactive command interpreter first, with an extended scripting syntax as one component.

As you indicate that you have been forced to work with it, and are obviously not knowledgable within the *nix paradigm, you view it negatively. It would be more useful to try to understand the how and why of it rather than criticize that which you do not understand.

Sigh! I know it is "an interactive command interpreter first". I have been using it that way for nearly twenty years.

It's a pretty good "interactive command interpreter".

I've been using Linux since V0.99, so I have a clue or two about the unix paradigm...

I'm also a language geek. I learn and compare languages as a hobby. I drill down to see what they are, how the design paradigms interact etc. etc.

From that perspective *sh is a pretty good "interactive command interpreter".

But there is no varnishing the truth here. It's a bloody awful programming language.

I have no objection to using it as a "interactive command interpreter".

I have no objection to using it in the original sense... a linear script of a bunch commands strung together.

I object to vast programs written in *sh.

They are needlessly hard and painful to maintain.

It's like Fortran IV programmers proclaiming Fortran IV to be the pinnacle of programming evolution.... and then writing full distro packaging systems out of it.

One just shudders and says.... Please Don't.

/awk/ · 06-22-2014, 06:14 PM

bash. WHY? because it's number one

Toadbrooks · 06-24-2014, 11:07 PM

I do wish people would abandon the "X is best" arguments. In the '70, I had to listen to Pascal snobs say, "If you aren't using Pascal, you can't be writing a structured program." Idiots, as if the language you choose has ANYTHING to do with your skill. To the person who only has a hammer, every problem looks like a nail.

Do I want to do a massive database system completely in a shell script? Hell NO! But to the shell wizard, perhaps that looks good. Deal with it.

I freely admit, I used to program in BASIC, for quick-and-dirty utilities I wanted to knock out with minimal debugging and compiling time. Now I do the same thing using python. Both are interpreted, which means the code doesn't run fast, but it is quick to produce. Nothing that executes directly from human-readable code is compiled. So if absolute speed is your requirement, you need to use a compiled (or assembled) language. For absolute max speed, choose assembly. I was an assembly specialist in the '80s, knowing 14 different ones. But nowadays CPU power and memory are cheap, so monster inefficient programs are acceptable versus hiring an assembly wizard for a high price.

Simply put, if you think whatever you use is the last word in programming, all you are admitting is you either aren't very smart or aren't very experienced. No criticism of anyone above, but again, could we drop the which is best arguments?

thurlowe · 06-27-2014, 11:37 AM

just bash

Gullible Jones · 06-27-2014, 01:55 PM

Today bash stopped noticing backslash characters for some reason, so I just switched to mksh across the board for interactive stuff. I do not think I will be switching back for interactive use. mksh has all the features I need (and none that I don't).

Anyway bash is still my standby for scripting, but only because it's ubiquitous. (Like a lot of other things...)

Gullible Jones · 06-27-2014, 02:09 PM

Now, if I may contribue to the flame war above...

Shell script from what I've seen works great for ad-hoc stuff, and automating small administrative tasks. But once you start really scaling up, and need things like
- Reliable automated tests
- Built-in concept of state
- Idempotence everywhere
- Safe and immediate failure detection
- Full automation, with no user input beyond updates to config files
- Configuration management that runs in a timely (rather than time-consuming) fashion

if you have a configuration management framework composed of SSH and shell scripts, you are going to be in bad shape.

I know this because I currently help to maintain such a framework.

Now granted, the grass may just look greener on the other side - I don't know enough about e.g. Puppet yet to say if it delivers what it promises. I can't say that shell scripts are bad compared to X. But I can say that, in some situations, they're not good enough.