dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
1486

Maxo
Your tax dollars at work.
Premium Member
join:2002-11-04
Tallahassee, FL

1 edit

Maxo

Premium Member

Which shell do you use?

I've been using bash, default in Ubuntu, for just about my entire Unix career. A coworker recently convinced me to try out zsh. I've also heard very good things about fish.
We like to flame each other over what Unix variant or distro we use, how about a nice war of the shells.

Edit: Spelling

markofmayhem
Why not now?
Premium Member
join:2004-04-08
Pittsburgh, PA

1 recommendation

markofmayhem

Premium Member

said by Maxo:

I've been using bash, default in Ubuntu, for just about my entire Unix career. I coworker recently convinced me to try out zsh. I've also heard very good things about fish.
We like to flame each other over what Unix variant or distro we use, how about a nice war of the sheels.

Not to nitpick, but /bin/bash is the user-land shell default. System default on Ubuntu (during boot, for example) is bin/sh which is symlinked to /bin/dash for lower overhead.

»wiki.ubuntu.com/DashAsBinSh

I have been using zsh recently.

»wiki.archlinux.org/index.php/Zsh

EUS
Kill cancer
Premium Member
join:2002-09-10
canada

EUS to Maxo

Premium Member

to Maxo
Debian by default will use dash, but I always override to use bash.
pablo
MVM
join:2003-06-23

pablo to Maxo

MVM

to Maxo
tcsh ... there's really no reason to use any other .. ...

I have tcsh tricked out to do incremental reverse/forward history searching and all the rest. I'm using, of course!, emacs key bindings.

Now, if I'm writing a shell script, then it's /bin/bash - and whatever it mutates to ...

Cheers,
-pablo

timcuth
Braves Fan
Premium Member
join:2000-09-18
Pelham, AL
Technicolor ET2251

timcuth to Maxo

Premium Member

to Maxo
I use bash on Linux because it is easier than switching to a non-default shell and all the sneaky problems that can cause.

For years and years I used the old ksh on HP-UX, Solaris, and other mid-range UNIX systems. I occasionally used ksh-93 (or, is it 92?), but it didn't really make any difference in my life.

Tim
HoboJ
join:2008-03-27
Cornwall, ON

HoboJ to Maxo

Member

to Maxo
I just use bash. As far as I can tell there's nothing offered by other shells beyond what is in bash which I could find useful or exceptionally neat that could drag me away.

Heh213
join:2012-06-16

Heh213 to Maxo

Member

to Maxo
I use zsh because I like its completion and have a pretty decent .zshrc I'm happy with, but in most cases I wouldn't really care either way. I still write scripts and such in bash for the sake of compatibility.

pcdebb
birdbrain
Premium Member
join:2000-12-03
Brandon, FL

pcdebb to Maxo

Premium Member

to Maxo
bash here. that's all I know

Maxo
Your tax dollars at work.
Premium Member
join:2002-11-04
Tallahassee, FL

Maxo to timcuth

Premium Member

to timcuth
said by timcuth:

For years and years I used the old ksh on HP-UX, Solaris, and other mid-range UNIX systems. I occasionally used ksh-93 (or, is it 92?), but it didn't really make any difference in my life.

Our Solaris boxes at work are setup with ksh as the default shell. I had our admin switch over the account I use the most to bash. I was having a hard time getting zsh with oh-my-zsh to work right on Solaris.
I don't know if it is the ksh configuration or what but ksh has no autocompletion or history, which makes it about as crappy as it can get.

Wily_One
Premium Member
join:2002-11-24
San Jose, CA

Wily_One to Maxo

Premium Member

to Maxo
I started with ksh on Solaris, and use bash on Linux.

I dislike csh & its variants, probably because I'm not a C/C++ programmer.

Drunkula
Premium Member
join:2000-06-12
Denton, TX

Drunkula to Maxo

Premium Member

to Maxo
Bash here as well. Mostly familiarity and comfort is the reason. I've tried ksh, tcsh, and a few others but none of them float my boat.

timcuth
Braves Fan
Premium Member
join:2000-09-18
Pelham, AL
Technicolor ET2251

timcuth to Maxo

Premium Member

to Maxo
said by Maxo:

I don't know if it is the ksh configuration or what but ksh has no autocompletion or history, which makes it about as crappy as it can get.

???

I always "set -o vi" in my profile and that gave me command history with Esc-k and j and at least filename completion with Esc-\. I still do things that way with bash on Linux.

Tim

nwrickert
Mod
join:2004-09-04
Geneva, IL

nwrickert to Maxo

Mod

to Maxo
"csh" here. Okay, I guess it is really "tcsh" behind the scenes.

I have been using "csh" for more than 20 years. There's no reason to change now.

Pet peeve: The shell startup files in "/etc" (in my case "/etc/csh.cshrc" and "/etc/csh.login"). I hate the way that linux uses those. In the grand scheme of things, the shell startup files in "/etc" are supposed to belong to the local system administrator. The linux distros that I have tried have all stolen those files for their own nefarious uses.

Maxo
Your tax dollars at work.
Premium Member
join:2002-11-04
Tallahassee, FL

Maxo to timcuth

Premium Member

to timcuth
said by timcuth:

I always "set -o vi" in my profile and that gave me command history with Esc-k and j and at least filename completion with Esc-\. I still do things that way with bash on Linux.

Tim

Thanks for the tips. I just added s -o vi to my .kshrc. The Esc-\ feels more clunky to me than auto-completion with in bash and zsh. However, that does still make my life easier.

koitsu
MVM
join:2002-07-16
Mountain View, CA
Humax BGW320-500

koitsu to Maxo

MVM

to Maxo
Q: Which shell do you use?
A: bash

History: I originally started using *IX (specifically SunOS 4 and NetBSD) in the 90s, and used the default shell chosen by the admins at that time: csh. Within a year or two the same admins asked me why I wasn't using tcsh and introduced me to it (tab completion blew my mind), and I was hooked. I used tcsh from that point onward (roughly 1992 to 1997). I was primarily using Linux, SunOS 4, and BSD/OS at that time. Pretty much every shell script I wrote was also for csh/tcsh (tsk tsk). Eventually I started getting annoyed with the lack of csh/tcsh's ability to redirect stdout and stderr separately, plus started getting pressure from colleagues ("who the hell writes shell scripts in csh?!") so I began writing actual shell (sh) scripts instead. After a year this made for somewhat of an annoyance, since my CLI was tcsh yet I was becoming very, very accustomed to things like short one-liners in sh. Thus I made the (somewhat painful at the time) the switch to bash.

That said: I do not use things like the emacs-esque input key/features of bash. My previous lead/boss used them heavily and watching him use the shell was amazing; you could consider me the "peck-typist" of bash.

Footnote opinion: I cannot stand ksh in any way shape or form, in the same way that I cannot stand Solaris /bin/sh. Kudos to those who can write ksh scripts and who tolerate Solaris's shell ancestry.
koitsu

1 recommendation

koitsu to nwrickert

MVM

to nwrickert
said by nwrickert:

Pet peeve: The shell startup files in "/etc" (in my case "/etc/csh.cshrc" and "/etc/csh.login"). I hate the way that linux uses those. In the grand scheme of things, the shell startup files in "/etc" are supposed to belong to the local system administrator. The linux distros that I have tried have all stolen those files for their own nefarious uses.

This is actually incorrect -- sorry for nitpicking, I don't mean anything negative by it, but I want to correct you.

Those files are actually used for all users. They're "global" dotfiles. csh.login is for actual login shell sessions (interactive), while csh.cshrc is for non-interactive and otherwise. You can read about them in the csh/tcsh man page; gotta read slowly though, don't skim.

This isn't a "Linux thing" either. bash, for example, has the same situation: /etc/profile. However, there's no system-wide login-interactive-equivalent. Instead, individual dotfiles are used for those, and it's even more complex under bash than csh: ~/.bash_profile, ~/.bashrc, and ~/.bash_login. All 3 are for different uses, and knowing which one to put what commands/features in requires familiarity with them. No offence to Linux people, but I see Linux folks screw this up *all the time*.

It's very, very common to see people put commands/etc. in the wrong files as well. I remember seeing people put tput/tset and stty commands in their cshrc, then later when doing something like a non-interactive ssh session, bitching/crying how there's "weird output from tput; why?!?!?!?" Yeah well, read the manpage.

So what you're wanting, if "for the administrator", is ~root/.cshrc and ~root/.login. If you use things like sudo or su2, this becomes extremely tricky to manage. It's not always as easy as just running sudo -i, etc...

P.S. -- Speaking of Linux: my first experience with CentOS was earlier this month, and I was absolutely appalled at the fact that the stock system dotfiles for bash do not set VISUAL, EDITOR, or PAGER to anything despite the system coming with nano/vi and more/less. What the hell is up with that? I had to explain to a user why his "svn commit" command was bitching about those variables missing (while on our FreeBSD systems such never happened). *sigh*

nwrickert
Mod
join:2004-09-04
Geneva, IL

2 recommendations

nwrickert

Mod

said by koitsu:

This is actually incorrect -- sorry for nitpicking, I don't mean anything negative by it, but I want to correct you.

Those files are actually used for all users.

You must have misunderstood something.

I agree that those are used by all users. I didn't say that they were "used" by the local system administrator. I said that they are supposed to belong to the local system adminstrator. They are for shell settings that the local administrator sets up for all local users, as appropriate for the local system and local policy.

In traditional unix systems, or at least in systems that I have used, those startup files are installed empty or with only a few lines. In linux, they are installed full of annoying crap.

So, of course, the first thing that I tried was to delete the files (or make them empty). And then the damn desktop would not start.

Environment variables that are required for the desktop to start should be in the desktop startup scripts. They should not be in the shell startup scripts.

koitsu
MVM
join:2002-07-16
Mountain View, CA
Humax BGW320-500

koitsu

MVM

Ahhhhhhhh, yes I understand now. I took what you meant (quote: supposed to belong to the local system administrator) to mean "these are the dotfiles which should be used by root only". My bad.

I would agree that things relating to desktop use (I'm assuming you mean things like startx) absolutely shouldn't go in there. If anything, such settings should end up in per-account dotfiles and be populated (put into place) during account creation via /usr/share/skel or /etc/skel or equivalent. System-wide dotfiles is not the proper place for those, absolutely agreed!

timcuth
Braves Fan
Premium Member
join:2000-09-18
Pelham, AL
Technicolor ET2251

timcuth to koitsu

Premium Member

to koitsu
said by koitsu:

This isn't a "Linux thing" either. bash, for example, has the same situation: /etc/profile. However, there's no system-wide login-interactive-equivalent. Instead, individual dotfiles are used for those, and it's even more complex under bash than csh: ~/.bash_profile, ~/.bashrc, and ~/.bash_login. All 3 are for different uses, and knowing which one to put what commands/features in requires familiarity with them. No offence to Linux people, but I see Linux folks screw this up *all the time*.

It's very, very common to see people put commands/etc. in the wrong files as well. I remember seeing people put tput/tset and stty commands in their cshrc, then later when doing something like a non-interactive ssh session, bitching/crying how there's "weird output from tput; why?!?!?!?" Yeah well, read the manpage.

So what you're wanting, if "for the administrator", is ~root/.cshrc and ~root/.login. If you use things like sudo or su2, this becomes extremely tricky to manage. It's not always as easy as just running sudo -i, etc...

Thank you for the quick tutorial, koitsu See Profile. Coming from a long ksh background, I have the hardest time keeping all this straight on Linux with bash. I am going to put your write-up into my permanent notes.

Tim

rchandra
Stargate Universe fan
Premium Member
join:2000-11-09
14225-2105
ARRIS ONT1000GJ4
EnGenius EAP1250

rchandra to Maxo

Premium Member

to Maxo
Bash for me.

For several years I was an adherent to tcsh. But I remember things slowly being realized by me as overconvoluted for things like I/O redirection, file list handling (for loop), and suchlike features. Eventually I also grew weary of having to switch mindsets when going from my interactive shell to having to do things like tweak /etc/init.d scripts. So basically for that reason alone, I'd try to get comfortable with whatever your chosen Unix variant mostly uses for its system grinding. In my case, it's a mixture of Fedora and Ubuntu Linuxen, and a smattering of Solaris 8 and UnixWare was thrown in for my previous job. At worst, I had been using ksh with emacs or vi keybindings.

gotta have pathname completion...and Bash has darned flexible completion. I don't know if other shells do it, but you can for example only complete directory names when TABbing after something that will only take directories, such as cd or pushd. Heck, I even saw that the bash_completions package for Ubuntu will even complete commands after typing "sudo ".

leibold
MVM
join:2002-07-09
Sunnyvale, CA
Netgear CG3000DCR
ZyXEL P-663HN-51

1 recommendation

leibold to Maxo

MVM

to Maxo
I started my Unix experience on System V which defaulted to /bin/sh (the bourne shell). At the time I was primarily a C (and Assembler) programmer and as a result I was briefly tempted by the csh. Luckily I discovered some of its limitations early on and went back to sh.

I feel lucky because the shells I'm finding on Unix and lookalike operating systems today as defaults (ksh and bash) are using supersets of the syntax that I'm used to. Everything I learned still works both in interactive shell usage and in scripts. I'm well aware that some things could be done less verbose if I took advantage of the richer functionality offered by more modern shells but I prefer not having to worry about whether the system I'm on right now is using ksh or bash.

timcuth
Braves Fan
Premium Member
join:2000-09-18
Pelham, AL

1 recommendation

timcuth

Premium Member

Well said, leibold See Profile.

Tim

dennismurphy
Put me on hold? I'll put YOU on hold
Premium Member
join:2002-11-19
Parsippany, NJ

dennismurphy to Maxo

Premium Member

to Maxo
These days, it's all bash.

When I was doing HPUX/Solaris daily, I left my shell as /bin/sh (or, on Solaris, /sbin/sh), and then added to my .profile:

if [ -x /usr/local/bin/bash ]; then
  exec /usr/local/bin/bash
fi
 

This way, if I login and, something is broken (i.e. /usr didn't mount correctly, perms are wrong, what-have-you), I'll fall back to /bin/sh.

Or, on Solaris, to /sbin/sh.

Trivia time - what's different between /bin/sh and /sbin/sh on Solaris?

nwrickert
Mod
join:2004-09-04
Geneva, IL

nwrickert

Mod

said by dennismurphy:

Trivia time - what's different between /bin/sh and /sbin/sh on Solaris?

Dynamic vs. static linking, although I'm not sure that is true anymore.

dennismurphy
Put me on hold? I'll put YOU on hold
Premium Member
join:2002-11-19
Parsippany, NJ

dennismurphy

Premium Member

said by nwrickert:

said by dennismurphy:

Trivia time - what's different between /bin/sh and /sbin/sh on Solaris?

Dynamic vs. static linking, although I'm not sure that is true anymore.

I guess I'm dating myself. Get these damn kids off my lawn!
iteratee
join:2012-09-04

iteratee to Maxo

Member

to Maxo
Yo, may as well make this my first post.

I mostly use Bash interactively, and don't use a fraction of its interactive features.

For small to medium sized scripts that don't need complex datastructures, extensibility, or performance, it's usually Bash again. The latest version has most of what's needed for most scripting. It's very stable and mature with good compromises on features compared to its relatives. Bash seems to have a huge number of quirks and (mis)behaviors that happen to be useful enough to abuse if you know what you're doing.

For larger or complex scripts where I'm reluctant to move to Python, (things that need libraries of shell functions etc), I tend to switch to ksh93 as it's obviously by far the most powerful POSIX-compatible shell in terms of programming features.

Also I occasionally use mksh in applications requiring a fast lightweight shell that doesn't suck.

And a dozen or so other shells just for testing.