This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
What Linux shell should I use?
I am starting to get proficient in a Linux environment and i'm trying to pick a weapon of choice in terms of command shell scripting (as i'm still a big n00b at this) that will help me (and others) manage, test and administer a set of server side applications running on a *NIX environment.
My question is: What is(are) the preferred command shell(s) out there when the following criteria are considered:
How easy is it to learn/understand for a junior dev who has never had an exposure to shell scripting?
Is there a big pool of developers out there that know this shell script?
Is it safe and easy to use - will script errors be silent or give intelligent error output, will it let the uninitiated shoot them selves in the foot?
How portable is it? - Can i expect the same script to run in OpenSolaris as well as Redhat, FreeBSD? (granted command syntax and options for specific OS will change accordingly)
How standard is it? Is it expected to be included on most distro's of *NIX or does it have to be installed additionally?
I understand that there are camps out there who hold strong feelings for/against specific command shells, i am just looking for an informed opinion.
These days, just about any non-embedded (or large embedded) operating system has a POSIX:2001 a.k.a. Single Unix v3 compatibility layer. This is native on unix platforms (Linux, Mac OS X, Solaris, *BSD, etc.) and installable on other platforms such as Windows and Android. POSIX specifies a shell language, usually known as POSIX sh. This language is derived from the Bourne shell.
Most unix systems have one of two implementations of POSIX sh: ksh or bash, which have additional useful features compared to POSIX. However some less mainstream systems (especially embedded ones) may have only POSIX-mandated features.
Given your objectives, I see three choices:
Restrict yourself to POSIX sh. Pro: you don't have to worry about differing variants, since there's a standard and compliant implementations are readily available. Con: you don't benefit from bash and ksh's extensions.
Use the intersection of ksh and bash. This is attractive in appearance, but it does mean you have to use two reference documents instead of just one — and even the features that bash and ksh have in common don't always use the same syntax. Figuring out which one you want to use on a given system is also a pain.
Choose one of ksh or bash. Both bash and ksh are available on all unix-like platforms and on Windows. Both have an open source implementation (the only one for bash, ATT ksh93 for ksh) that can be installed on most platforms. I'd go for bash over ksh for two reasons. First, it's the default on Linux, so you'll find more people who're used to it. Second, there are systems that come with an older, less-featured implementation of ksh; even if you can install ksh93, it's another thing you have to think about when deploying.
Forget about csh for scripting, and forget about zsh if you want common default availability.
See also What are the fundamental differences between the mainstream *NIX shells?, particularly the “for scripting” part of my answer.
Note that shell programming involves other utilities beyond the shell. POSIX specifies those other utilities. “Bash plus other POSIX utilities” is a reasonable choice, distinct from “POSIX utilities (including sh)”.
csh is almost always wrong.
Z shell (zsh)
It's said zsh is the most powerful for now so I would recommend trying it.
No matter which shell you learn - their syntax is very similar. Only built-in commands may slightly differ. But don't choose those old and unmaintained.
Bash is the most popular. But almost every command in bash works in zsh the same way. There are some exceptions of course.
AFAIK, every shell handles it the same way. But be warned - shells are stupid, they are not as smart as programming languages.
I saw zsh working on all Linuxes, FreeBSD and OpenSolaris.
See 4. Distros have zsh in their repos.
Why I prefer zsh (Z shell) to bash:
files matching like this: for file in ./**/*.java; do ... (I mean ./**/*.ext)
wants me to confirm when I do rm * :)
tab-autocompletion is a lot better, I can write dmdomi[tab] and it suggests dnddomainname. java wants class name as the first parameter, zsh will suggest all classes available in the package and all subpackages.
But you are not limited to zsh only. If something does not work for you, you just write it in bash or sh. This is what is "#!/bin/bash" on top of the script for. :-)
To start quickly, use my .zshrc config: http://www.rozne.geozone.pl/.zshrc The only thing you should change there is export LANG="pl_PL.UTF-8". You probably don't want Polish locale.
Shell scripts for any *nix shell are generally deceptively simple. Easy things are usually easy, sometimes hard things are easy, sometimes easy-seeming things are hard. No shell is particularly better than the others in this area but some are worse (I can't seriously recommend csh). Some will say that bash is the worst 'modern' shell, which may be true but you can't completely escape it anyway.
There's an argument to be made that using the most 'popular' shell is best for maintainability for the same reason Windows is best (and I'm not saying that it is): It's easy to find people you can hire who know how to use it. There are simply more people who have at least a passing familiarity with bash-specific features, say, than ksh or zsh. Finding people who actually understand what they're doing is another matter.
All shells have various gotchas, corner-cases and weird behaviors. Mostly it comes down to what you're used to. Shooting yourself in the foot is what I'd call a grand Unix tradition and no *nix shell can truly keep you safe.
Nearly every shell you'll see is highly portable to almost every platform. Even though this is true you won't necessarily be able to run the same (say) bash script on three different boxes unless you were careful about what utilities you used and which options you passed them. Writing portable shell scripts is hard for reasons having nothing to do with which shell they're written for.
Nearly every Linux uses bash by default and has most shells available. FreeBSD includes sh, csh and tcsh by default with bash and others in ports. Once upon a long time ago, Mac OS X used tcsh by default, but it now uses bash by default, and includes zsh along with most common shells. Beyond that I cannot comment.
Personally I use bash out of (mostly) inertia. If I weren't so familiar with it already I would use zsh instead.
bash is the standard and is very good at interactive use (good completion supporting many programs, history, readline support, many kinds of string expansion). It is also good at scripting, for a shell (arrays and hashes, quoting, string manipulation); though writing reliable scripts requires you to learn a lot more.
If you want your programs to be able to grow, work with elaborate data structures, and use some useful libraries, you should learn a language like python, ruby or perl. Most of those have interactive interpreters as well, not as convenient as a shell but useful for quick testing. IPython, for Python, is particularly useful; it lets you explore documentation very easily, can load and reload source, includes a debugger. It also includes some standard shell commands and can pass the rest to a standard shell by prefixing them with a !.
Thanks to being interactive most shells are easy enough to learn once you start using them exclusively
I believe bash, and the posix subset, is better known by a wide margin. But the languages I mentioned are as well known as many shells.
You can easily shoot yourself in the foot, convenience often makes undesirable things easy.
and 5. Portability of the shell itself shouldn't be a problem; you may need to recompile to get more modern features on some of the OSes you mention. Using a full-blown language with its own libraries will help smoothe the variation of your multiplicity of platforms.
Related
Quick backstory: I'm a graduate student, and I know very little (read: almost nothing) about batch files. A collaborator at another university came to me and told me to create a batch file for a supercomputer which runs on a Linux system. After googling, it looks like a batch file is technically only for Windows systems, and the Linux equivalent is a "shell script". I talked to my collaborator about this, and he's insistent that it should be a batch file, not a shell script, even though it's a Linux system.
Is there something I'm missing here, or is there some way to make a batch file for Linux? There is a language barrier, so I wonder if that's part of the problem. Thanks, and sorry for such an elementary question.
The term "batch" may refer to two different things, maybe that is the issue here:
the MS-Windows batch command processor, some very primitive and limited, non-interactive shell environment
"batch processing" which simply means non-interactive processing of work items or jobs
You are right that the (very) rough equivalent to an MS-Windows batch script is a shell script in unixoid systems (so Linux too). However it should be pointed out that there are many very different types of shell environments you can use, so you have a huge flexibility here.
Considering the two alternative meanings above I could imagine that what is meant is "a script that does batch processing". Usually it is of less importance which specific type of language is chosen for that.
The *nix equivalent would be a shell script. For example, Ubuntu's default shell is bash.
BASH Programming Introduction might prove a worthy read.
As another answer already noted, scripts of command line commands are called "batch files" on Windows, but the term also means non-interactive processing in general.
Since the context was some sort of a supercomputer, there's a possibility that a "batch file" means something specific to the system, not just a generic shell script/program.
Either that, or they are just very insistent on using uncommon terminology.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Find out if a command exists on POSIX system
How to find a usable executable file in bash
On the command line I'd type (e.g.) type vimdiff (or which vimdiff if type is not available on the machine). But in a script, what is the most reliable way to check for a utility and then take some action depending on its availability.
The purpose at hand, if it helps to know, is I'm writing a function, thediff, which I can install on local and remote machines of various operating system and various flavors of OS, and let it pass arguments off to p4merge if it's available (for OS X and Windows/Cygwin environments), and if not then try vimdiff and use that if it's available, and if not then default to diff with my preferred options (e.g. --side-by-side --suppress-common-lines --ignore-space-change').
Since which is notoriously unreliable in the form of feedback it gives, I'm not sure if I can count on $? being 1 if the utility in question is not installed. But on the other hand, I'm not sure I can rely on type being installed at all.
It seems kludgey, but what about just trying the first utility, and if $? is non-zero then trying the next, etc.
How is this generally handled?
UPDATE:
Although I did tag this with 'bash', that was only to get the attention of people following the bash tag, since they'd be likely to know an answer. I did not mean to imply that I only ever use bash, or that I can assume bash will be present on all systems I use. In fact I've had to work on systems where grumpy sysadmins made it difficult to use anything but the Korn shell. And (whenever available) I use zsh instead of bash. So this is not an exact duplicate of How to find a usable executable file in bash since that requires bash. So the questions are different. Further, I explicitly stated that I've had to use systems where type is not available. All the closers apparently overlooked that fact.
This question might legitimately be a duplicate of the other question, if all the systems I mentioned are in fact POSIX compliant. I don't know whether they are.
Ok this is a 2 parter.
First of all, this may sound stupid, but are all Unix Commands on Linux Distros? Does any Linux Distro add any.
And commands like....pwd or......ssh, like what are these "written" in programming language wise. C?
Second part, What is a good book that lists and explains all the Unix commands (or at least most of them)
thanks
The biggest difference you will find
between the Unix (and its
derivatives) and Linux commands are
the options that exist for those
commands. Specifically, the GNU
versions tend to add more
functionality to their commands but
their use is not portable to non-GNU
systems like BSD or Unix.
A common example of this would be
the GNU sed -i option which allows
you to do an in-place edit on the
file. Non-GNU versions of sed
require you to first write to a temp
file then copy the temp file over
the original.
In order to help define what is
portable code and what is not, there
are the
POSIX
and
SUS
specifications. Any shell which
claims to be POSIX compliant
guarantees that any code written
against the POSIX standard will
perform identically. The bash
shell is a POSIX compliant shell but
that doesn't mean all bash
commands are POSIX compliant.
For your second question, yes, most
commands in binary form were
written in the C language.
Sometimes you'll find certain
commands that are written in
scripting languages such as perl,
python or bash. The rename
command is one example that exists
in both perl and binary form
written from C.
For your 3rd question on Book
Recommendations, see this SO
question
Not all linux distributions come with one and the same set of commands. There is, however, The Single UNIX® Specification, which lists canonical commands and utilities.
In short: The majority of programs is written in C.
Again, take a look at The Single UNIX® Specification to get an overview. Once you have opened a terminal with a shell, just press Tab - this will yield a list of commands on your machine.
$ # press
Display all 3358 possibilities? (y or n)
Most commands have man pages, too, if you want to know more about them.
$ man pwd
First off, I think it would be better to refer to shells here, since each *nix distro can come with numerous shells. To answer your questions:
Many commands are available on all shells, but of course each shell can add their own commands. Additionally, many programs can add their own shell accessible programs.
I found the O'Reilly book on learning unix shells to be extremely useful.
I learned much of the basics from http://linuxcommand.org/. Maybe that will help you and the price is right
And visiting it just now I see that the author has compiled it into book for free under a CC licence. Check out the description and a download link here.
1. Yes / C. 2. O'Reilly, and Apress
I. Common Commands
There is a core set of commands that true Unix and all of the Linux distros have.
For some time, the distributions have been evolving to install a set of packages, and since there are thousands and thousands to choose from, the idea of a "base system" has given way to that of a "default install". For example, some can be installed without X or graphics.
Some of the original Unix commands or rewrites of them are available with BSD licenses, and you will run into many of those on true Unix, *BSD, and on the Mac. There are also a set of GPL-licensed rewrites of the Unix commands. These tend to be quite elaborate, leading to confusing manpages, but sometimes they are considerably more useful than the original Unix program. Groff is a good example of a case where the original code has been completely superseded. In any case, Linux distros stick as much as possible to the GPL/GNU versions.
Language: The core commands are almost entirely written in C. As the C++ and C compilers have merged, a few packages are written in C++. A few are written in Posix shell code. As the distributions have grown in scope and size, more packages that are included are written in languages like Perl and Python. I presume you may see packages written in Ruby as well. (Ruby comes with the Mac now.)
II. Books
O'Reilly and Apress are two good sources for Unix and Linux publications.
III. Well, there wasn't a III but Mac OS X is built on a version of Unix. You can learn Unix perfectly well in the Terminal app on your Mac.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I use bash, and have done so for over a decade - but occasionally I wonder whether there has been any significant new developments in the world of Linux shells.
A few years back Microsoft released PowerShell, which seemed very interesting. Is there any comparable innovation going on in Linux shells?
You do realize bash 4 has very recently been released with a load of new features and language additions?
Shell options globstar (**/foo) does a recursive search, dirspell fixes typos during pathname expansion.
Associative arrays, map strings to strings, instead of just numbers to strings.
The autocd shell option allows changing directories by just typing the directory path instead of having to put cd in front.
Coprocesses
&>> and |& redirection operators that redirect both stdout and stderr
Loads of additions to existing builtins for improved scripting convenience.
Check out:
The "official" changelog: http://tiswww.case.edu/php/chet/bash/CHANGES
A short guide to some of the new features: http://bash-hackers.org/wiki/doku.php/bash4
I'd take a look at zsh or fishshell.
One of the least touted features of Bash (and several other shells) is the ability to write your own loadables, and have the shell run them as builtins.
Lets say you write the loadable 'on' .. and you want it to work like this:
on node 123 run some command
on class nodes run some command
on all nodes run some command
... etc ..
You can follow simple examples on how to write a loadable, then enable it as a bash built in via enable -f /path/to/loadable loadable_name
So in our case, enable -f /opt/bash/loadables/on on
... in your bashrc , and you've got it.
So, if you want to have bash interpret your spiffy new language natively, you would write a loadable named 'use' or 'switch_to', then modify the parser to load a different grammar / runtime if a certain environment variable was set.
I.e.:
#/bin/bash
switch_to my-way-cool-language
funkyfunc Zippy(int p) [[
jive.wassup(p) ]]
Most people are not going to want to hack their shell, however. I did want to point out that facilities exist to take Bash and make it the way you want it, without fiddling too much with core code.
See /path-to-bash-source/examples/loadables, you might be able to get that to fly where you work, since you're still using Bash.
You can run PowerShell on Linux via Pash. It uses Mono the way PowerShell uses .NET.
I think the "original improved shell" is ksh93. bash came into existence at a time when the ksh source code was proprietary; if ksh had been open-source then, it might not have been deemed necessary to have a new shell (though with the FSF you never know). ksh is worth studying, especially for its ability to be extended through C modules, but it's not a clear win over bash. bash's autocompletion is clearly superior, which may be enough to make bash a win overall. In any case bash and ksh have made substantial effort to converge, so differences are minor.
The other interesting shell is zsh, which attempts to be everything that ksh is while also including csh. Since I never saw any point or use to csh, I am not the right person to advocate for zsh. I will point out one unusual incompatibility: by default, in zsh a variable $var always expands to a single token, even if it contains spaces. This behavior is incompatible with all other sh-derived shells, and it is occasionally inconvenient, but really it makes a lot more sense than the original, and it saves a hell of a lot of quoting.
csh was the first shell to have job control, but in my mind it (and its successors) has been superseded by bash and ksh. It was never mucn fun to write scripts in.
Finally, there are many tiny shells designed for rescue floppies (!) and other Spartan environments, but it sounds like you have little interest in those.
(In the matter of innovation, I should add that more than half the scripts I used to write as shell scripts are now Lua scripts. Others could say the same for Python or Ruby, or back in the day, Perl or Tcl. So I think the real innovation is migration away from the shell for programmable interaction at the command line.)
IIRC, Powershell is Object Oriented, whereas most unix shells and utilities operate on text. On that regard, Squirrel Shell might interest you. I've never used it, though.
If you’re willing to lose sh compatibility, you could look at using a scripting language like Python or Tcl as your shell. rlwrap can be very handy if the interpreter doesn't provide line editing, command history, completion, etc.
One philosophy regarding shells is that they should primarily only be used to connect processes with files (here is one page that espouses that approach). That said, people have written some remarkably complex software using them.
Shells don't come much more inovative than the Scheme Schell. All the power of Scheme combined with the ability to run Unix commands and an embedded awk interpreter (written in Scheme, of course). The only drawback is that it needs a tiny bit of patching to build on 64 bit Linux.
It's not exactly Bourne-shell, but it's different. Of course, you have to learn Scheme - bonus!
if you like ruby, you can use rush (ruby-unix shell, not irb)
see the presentation here
http://www.slideshare.net/adamwiggins/rush-the-ruby-shell-and-unix-integration-library
or official website to see more examples
http://rush.heroku.com/
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I've used bash, csh, and tcsh. But I asked this question, and Jonathan informed me that csh isn't to be trusted. So what Linux shell is good for development. and why?
The most common shell, by far, on Linux is bash. Unless you have a good reason to use an alternative, I'd suggest that sticking with bash, or the most commonly used shell by your project team (or that the bulk of the shell scripts you have to work with) uses.
The only other very common contender is dash, which is becoming more widely used by the Ubuntu project.
This really is personal preference, well, except for csh.
Wikipedia link for csh
I prefer zsh.
The tab-completion alone is worth it:
It expands wildcards if you want(handy when you want to delete all but one file in a directory)
Will give you a list of switches after specifying a program
Gives tab completion options below the line you're working on, which is pretty handy.
http://zsh.sourceforge.net/
For interactivity, use Zsh. For a while I was the maintainer of the FreeBSD port of the Bash tab-completion scripts, but abandoned it as soon as I tried Zsh for the first time. It can do everything Bash can do but more easily and more elegantly. It also has the nice property of having extremely Bash-like keystrokes, so if you're on a system without Zsh, you'll be able to make do (even if it wouldn't "feel" as nice).
For scripting, use Bourne Shell (sh). It's the POSIX standard scripting language and your scripts are pretty much guaranteed to work everywhere. Bash and Zsh and other shells have nice extensions that you'll miss but those tie you to a specific setup. Ignore that advice for personal-use-only scripts that you're certain you'll never run elsewhere, but remember that it's a real tradeoff that you need to consider.
But in summary, Zsh. I don't know of anyone who's tried it who didn't immediately and permanently switch. It really is that good.
Fish (Friendly Interactive Shell) is a nice alternative to most of the other shells. It has a consistent syntax, nice tab completion and syntax highlighting, is easy to pickup and use (especially if you don't have habits from other shells), and has excellent runtime help.
Downside is that it's erratically developed, has a small (but helpful) user base, and is very different than other shells. Backwards compatibility with shell idioms was not a priority.
In many cases this is good... a lot of the standard shells have really stupid ways of doing things, just because it's always been done that way. "do/done", "case/esac", "if/fi"? This is insanity that fish does away with.
It's worth a look.
Since I believe I'm the person who suggested that you should use something other than C Shell, perhaps I should should qualify my remarks slightly, and then support those who said 'bash on Linux, Korn shell on other platforms (unless bash is installed there too)'.
Rather like editors (do you prefer vim or emacs), choice of shell is partly a question of familiarity and partly a question of preference. There are many who like C shell, though I do believe that it is less easily programmable than Bourne shell and derivatives. What I have in my .cshrc is, indeed, equivalent to exec /bin/ksh (it isn't identically that because I want to execute a login shell - one that reads the profile and so on), but I wouldn't condemn anyone for using C shell or a derivative if it is an informed decision.
If you decide that you want to use something other than C shell, then you are basically in the Bourne shell camp, for which the POSIX standard more or less specifies the expected behaviour and then the different shells -- that is, the Bourne, Korn or Born Again shells -- add (or, in the case of the classic Bourne shell, subtract) a few features. If your code might ever need to move off Linux to HP-UX, Solaris or AIX (the surviving trio of the classic, AT&T-derived Unix variants), then you should consider ensuring you write your shell scripts in classic Bourne shell, though Korn shell is also pretty safe. Note, though, that on Linux you can write #!/bin/sh and get Bash, on the other platforms, you will get Bourne shell.
I switch between Korn shell and Bash without major problems - and seldom with minor problems. I tend to stay clear of those corners of either language that are not well defined - which tends to mean 'defined in both'. Another problem for those using Linux is that the GNU tools have more options than the classic Unix versions, and you can lose portability not because of the shell programming constructs that you use but because of the command options you use. Experience and ready access to the manual pages of other systems helps enormously.
I usually stick to bash, because it's more friendly than straight-up sh, and it's the default on every distro I've used semi-regularly (SuSE, RHEL, Ubuntu, Slackware).
If you're planning to write portable shell scripts, however, make sure they all run in real sh.
Bash. It's standard.
The problem with csh is that it's crap for scripting, as explained here. There's no real reason why you shouldn't use it as an interactive shell, but most people find it confusing having to learn two different shells and not being able to try out bits of their scripts on the command line, so it's easiest to use the same for everything.
The obvious candidates for an interactive shell are bash, dash, zsh and {pd,}ksh. All of these implement the posix shell standard, with some minor extensions. Pick whichever you like for interactive use, I'd tend to go with bash just because it's the standard on linux but they all have their merits and zsh in particular seems popular.
If you're writing a script that you intend to be portable, use #!/bin/sh, and make sure you use standard posix shell syntax. If it works on both bash and ksh it's probably standard. There are some old versions of unix which have a non-standard /bin/sh but I wouldn't bother with that unless you know you have to. More of a problem for portability are all the command line tools you call from your script.
Nobody mentioned the Debian based standard for sh, Its the Debian Almquist shell dash. Its is fully POSIX compliant and has a very fast startup, which is why Debian/Ubuntu use it for /bin/sh.
So I use bash for my interactive shell, but only dash for scripting. That way i know my scripts are at least POSIX compliant, and will run on any other POSIX shell. ... I know portability is more than the shell, but its where I draw the line.
I'm not big Ruby user but http://rush.heroku.com/ looks interesting
It's probably best to stick with bash simply because it's the most widely used as a shell and any tutorials or help you may receive from someone will most likely use bash. However, I have started using zsh for all of my scripts and I have found it to be far superior to bash in terms of scripting.
Just don't use Korn Shell (ksh).
Unless you have perfect typing and never need to use the backspace key.
I like ksh actually. It's a bit more consistent than bash because it does not try to support any csh constructs. tcsh, in my experience, is least compatible with other shells, and I avoid it. I try to write scripts to sh, but ksh does have some nice features like exporting and setting a variable on one line. I try to preserve compatibility with bash as well, since it is full-featured and common. To write portable shell scripts, which is more important than selecting the "best" shell, you might consult this book.
Portable Shell Programming: An Extensive Collection of Bourne Shell Examples (HP Professional Series) by Bruce Blinn (Paperback - Oct 29, 1995)
amazon.com
I use pdksh all the time without having anything close to perfect typing (perhaps you need to fix your termcap?).
ksh is the standard, csh is a standard and bash is 'standard', but on linux only. Better to target ksh.
For writing actual scripts, I prefer ksh, which has several extensions useful for programming and fixes one of my pet annoyances.
bash is my preference for interactive sessions, but that is more a matter of personal preference than anything else. Just be sure it is a Bourne-type shell.
I came also from csh, tcsh to bash. It's different but after some time, at least as nice as the c-shells.
For Scripting I would recommand ksh, because it's available on most Unixes (Solaris, HP-UX , OSF/1 (The best UNIX ever ;) - for it's time)) and it has good features. With Korn you can programm most of the scripts. Sporadicaly you would like to get more then a number, as return value from a function, or you have some data that you can not put in a simple array, or you need something that has better capabilities in case of regegs, or what ever, then I would propose perl.
For scripting, try using dash for a while to get a good feel for what is portable. If you ever use bash to write a shell script, please explicitly declare bash in the scripts shebang.
For your personal console use, experiment with what is out there. Find something that you're comfortable with. Be eccentric and annoy all your sysadmin friends by picking up a shell that has to be compiled from source for every machine you care to use it on.
I think FISH is the best, is has syntax highlighting(for commands that don't exists) and it can autofill. And it is very easy to learn.
Select one:
a. tcsh
b. ksh
c. zsh
d. login
e. bash
I would use login. Just sayin.