MaxoYour tax dollars at work. Premium Member join:2002-11-04 Tallahassee, FL 1 edit |
Maxo
Premium Member
2012-Aug-22 12:25 pm
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 |
|
markofmayhemWhy not now? Premium Member join:2004-04-08 Pittsburgh, PA
1 recommendation |
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/DashAsBinShI have been using zsh recently. » wiki.archlinux.org/index.php/Zsh |
|
EUSKill cancer Premium Member join:2002-09-10 canada |
EUS to Maxo
Premium Member
2012-Aug-22 2:37 pm
to Maxo
Debian by default will use dash, but I always override to use bash. |
|
|
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 |
|
timcuthBraves Fan Premium Member join:2000-09-18 Pelham, AL Technicolor ET2251
|
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 |
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. |
|
|
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. |
|
pcdebbbirdbrain Premium Member join:2000-12-03 Brandon, FL |
to Maxo
bash here. that's all I know |
|
MaxoYour tax dollars at work. Premium Member join:2002-11-04 Tallahassee, FL |
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 |
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 |
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. |
|
timcuthBraves Fan Premium Member join:2000-09-18 Pelham, AL Technicolor ET2251
|
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 |
|
|
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. |
|
MaxoYour tax dollars at work. Premium Member join:2002-11-04 Tallahassee, FL |
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
|
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 |
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* |
|
2 recommendations |
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
2012-Aug-23 9:40 pm
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! |
|
|
timcuthBraves Fan Premium Member join:2000-09-18 Pelham, AL Technicolor ET2251
|
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 . 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 |
|
rchandraStargate Universe fan Premium Member join:2000-11-09 14225-2105 ARRIS ONT1000GJ4 EnGenius EAP1250
|
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 |
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. |
|
timcuthBraves Fan Premium Member join:2000-09-18 Pelham, AL
1 recommendation |
timcuth
Premium Member
2012-Aug-26 11:11 am
Well said, leibold . Tim |
|
dennismurphyPut me on hold? I'll put YOU on hold Premium Member join:2002-11-19 Parsippany, NJ |
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? |
|
|
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. |
|
dennismurphyPut me on hold? I'll put YOU on hold Premium Member join:2002-11-19 Parsippany, NJ |
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! |
|
|
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. |
|