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.
Related
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.
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.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
What language do you prefer for writing scripts for common tasks (backup, sync, etc.) and why? I'm not talking about programming web pages or applications.
I've came up with this question when thinking about why bash is still popular. For example Python looks more comfortable for me. Do you use just because you know it or for some special reasons?
If it's "create this directory, run this command, if that worked do run this"-level, I just use bash shell-scripts..
Anything more complicated, say something that parses the output of a command and acts upon it, becomes a Python script - I find it just as quick to write, mainly because shell scripts are difficult to debug (bash script error messages aren't exactly useful compared to Python's tracebacks..), and the end code becomes much more readable
...why bash is still popular?
Well, because Bourne Shell ( sh , and not necessarily bash ) is pretty much available in any +*n*x installation.
A good command of sh and vi its extremely helpful when connecting to remote servers via telnet/ssh
For local admin ( when you own the server ) you can use python/perl/ruby and customize them at your will. But most certainly, any day you could be asked to "quickly fix" other server where the two defaults are installed: sh+vi
That's why.
Unix has a philosophy of small tools which do one particular job and do it well. Often the easiest way to solve problems is to use a combination of such tools. Shell scripting is the king for this, no questions about that.
Of course, there's also the "when all you have is a hammer" syndrome :)
This really depends on the type of script. I am starting to use ruby for many sysadmin type tasks however bash is still my first choice for quick and dirty scripts. The advantage of bash, in my eyes, is the interactive nature of it.
To give an example. The other day I was searching for some particular values in approx 200 compressed log files, re-formatting the output and mailing the results.
It was very easy to use bash to do this iteratively, so, zcat one file piping the output to grep, retrying a few times to get the regex correct. Then take that output and reformat the result using awk, again retrying several times to get the format correct.
This process took a couple of minutes after which I wrote the bash commands into a script file, paramaterized it, wrapped a for loop around it, mailed the result and the job was done.
I find this process much simpler in bash just using command editing and retrying the regexes etc than I would in a separate script file where I have to keep editing the script and retrying etc.
G'day,
Different tasks call for different languages. I tend to use either shell, usually bash, or Perl depending on the task.
Now I'm getting more comfortable with Ruby, for those tasks that might suit an OO approach, I'll use that.
HTH
cheers,
Perl would be best in handling system administration tasks. I have never come across a *nix system that does not have Perl installed.
Python for me at the moment, I like using python because it has an interactive terminal that I can use to build up and execute the script as I go along - but I used perl in the past.
Bash, or various sh dialects in the broader sense can be assumed to be present on pretty much any unix system. Often, production Unix systems (Solaris, HP/UX, AIX etc.) have a very plain vanilla install; quite often they will not have perl or python installed. There may be company policies restricting this, so getting it installed may not be an option either. If you want something that will work on this type of platform, you will probably be limited to sh/sed/awk.
Bash is quite good for tasks that primarily involve running other commands, so you shouldn't underrate it. However, it rapidly becomes a write-only language at fairly trivial levels of complexity, so Perl or Python might be a better choice if you are programming something with a lot of internal processing.
For scheduling a backup, a bash script run from cron is quite possibly the best way to do the job. For something that involves parsing multiple log files, formatting the output to a summary status file and sending you an email notification if it notices certain types of events you might be better off with perl or python.
Bash is the preferred scripting language for these kinds of tasks. It's pretty ubiquitous, and it's intended to be a glue language, in the sense that you can glue together a bunch of commands that you would normally do in the terminal pretty much unchanged.
I use Ruby for most of my shell scripting tasks. I can never remember some of the nuanaces/gotchas of Bash scripting.
I use Ruby because I am most comfortable in it. It's one of the few languages in which I find myself struggling with the logic of my problem, rather than the syntax or restrictions of the language. Compare this to C++ or Perl, in which I get frustrated over pointers and sigils. I find recursive directory traversal and running system commands very easy to do in Ruby, e.g. using Ruby to rename files and edit their content.
I use perl, typically. The module library at CPAN makes many tasks simple. Net::SSH is a great tool for automating system administration tasks.
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/
I want to stop losing precious time when dealing with Linux/Unix's shell.
If I could get to understand it well, that would be great. Otherwise:
I may end up losing a day just for setting up a crontab.
I'll keep wondering why the shebang in this script doesn't work.
I'll keep wondering what the real difference is between:
. run.sh
./run.sh
. ./run.sh
sh run.sh
sh ./run.sh
You see, it's these kind of things that cripple my Linux/Unix life.
As a programmer, I want to get much better at this. I suppose it's best to stay with the widely-used bash shell, but I might be wrong. Whatever tool I use, I need to understand it down to its guts.
What is the ultimate solution?
Just for fun:
. run.sh --- "Source" the code in run.sh. Usually, this is used to get environment variables into the current shell processes. You probably don't want this for a script called run.sh.
./run.sh --- Execute the run.sh script in the current directory. Generally the current directory is not in the default path (see $PATH), so you need to call out the relative location explicitly. The . character is used differently than in item #1.
. ./run.sh --- Source the run.sh script in the current directory. This combines the use of . from items #1 and #2.
sh run.sh --- Use the sh shell interpretor on run.sh. Bourne shell is usually the default for running shell scripts, so this is probably the same as item #2 except it finds the first run.sh in the $PATH rather than the one in the current directory.
sh ./run.sh --- And this is usually the same as #2 except wordier.
Command line interfaces, such as the various shell interpretors, tend to be very esoteric since they need to pack a lot of meaning into a small number of characters. Otherwise typing takes too long.
In terms of learning, I'd suggest using bash or ksh and don't let anyone talk you into something else until you are comfortable. Please don't learn with csh or you will need to unlearn too much when you start with a Bourne-type shell later.
Also, crontab entries are a bit trickier than other uses of shell. My guess is you lost time because your environment was set differently than on the command line. I would suggest starting somewhere else if possible.
Man pages are probably the "ultimate" solution. I'm always amazed at what gems they contain.
You can even use man bash to answer some of the questions you raise in this question.
Try the Linux Documentation Project's BASH pages here [tldp.org].
PS: The difference is that . is the same as the source command. This only requires read permission. To use ./run.sh, you need execute permissions. When you use 'sh', you are explicitly specifying the command you want to run the script with (here, you only need read permission). If you are using a shell to execute it, there shouldn't be a problem there. If you want to use a different program, such as 'python', you could use python run.py. Another trick is to add a line #!<program> to the beginning of your script. In your case, #!/bin/sh would do, and for Python, #/usr/bin/env python is best.
I think immersing yourself in it is the answer. It's like learning to walk, to type, to use an ergonomic keyboard, or type in dvorak. Commit to it completely. And yes, you will absolutely slow down. And you'll be forced to look at your hands or google things constantly. But eventually it will come to you.
Funny story, I killed my apartment's internet access by doing an ifconfig release. Completely didn't know that ifconfig renew was not a command. Had to call a friend when google didn't load ;) dhcpcd later and I was back to googling everything.
Oreily has an older book that teaches you about bash, and bash scripting at the end. Most everything you need to know is on the web, but spread out.
The best way to learn is by reading, and then trying things out. MAN pages are often very helpful, and there are tons of Shell scripting tutorials out there. If shell scripting is what you are after, just read, and then practice the things you read by writing little scripts that do something neat or fun. If you are looking for more info on all of the different command line applications that can be run from a shell, those are more distro dependent, so look in the documentation for your favorite distro.
There are some decent online guides that will help you feel more comfortable in the shell(s). For example:
Steve Parker's Unix/Linux Shell Scripting Tutorial
UNIX Shell Programming, by Stephen G. Kochan and Patrick H. Wood, available online at Google Books. Also available in hardback. Amazon has it.
UNIX shell scripting with sh/ksh. Apparently used as part of a class at Dartmouth College. ksh is the Korn shell, and it's close enough to bash that the info will be useful.
Spend some time reading those kinds of tutorials and, above all, playing in the shell. Pretty soon, it'll start to feel like $HOME. (Okay, sorry for the bad pun...)
use the shell a lot, type "[prog-name] --help" a lot, type "man [prog-name]" a lot, and make notes on what works and what does not -- even if those notes seem obvious at the time. By tomorrow, they might not be so obvious, again. OTOH, in a couple of weeks they definitely should be!
Have a gander at some of the many books on working with shells, like From Bash to Z Shell (which covers Bash and Z), slog through a shell-scripting tutorial, or Gnu's Bash manual.
While sticking with Bash might be best, while just learning, the fish shell might be a little bit easier to use. I played around with it for a few weeks, and while it didn't seem as powerful as bash, it did seem pretty user friendly.
The way I really learned my way around in Linux was to install gentoo. It takes forever but you begin to see how everything ties together.
Go grab the latest instructions and start following them. Do it enough times and it starts to stick.
After a while you get comfortable building everything from scratch.
I find trying to learn a new command using the man pages sometimes a bit overwhelming.
I prefer man pages for refreshing my memory.
When I want to learn a command I look for examples then use the man pages to fine tune what I want it to do.