Khepri wrote:
>
> I see that now that I 've been reading through the LFS website....I
> thought the shell was part of the kernel ala DOS but now I see the
> shells are programs that interface to the kernel...
>
> I was under the impression that VI was "built-in" also, and I see that's
> not the case either...LOL
>
> So I would do well to learn say..Emacs and VI or VIM..and then a couple
> of the shells, bash of course and..???
>
> I've already started with VIM and I have a book on bash so I'll start
> thereand develop some proficiency then consider others..I'm just curious
> if most people used tcsh or korn or what?
>
I've strapped on my asbestos overalls.
Ultimately, you'd be better off to learn everything, of course. Nobody
has that kind of time, though, so you have to make some decisions. As
others have noted, there are "religious wars" associated with many of
the questions you're asking.
vi vs. emacs: It's often suggested by emacs devotees that emacs is
"more powerful", easier to use, and "more complete". Devotees of vi
often suggest that vi is "more powerful", easier to use, and "less
bloated". The reasons I went primarily with vi are the larger installed
size and resource footprint of emacs and the ubiquity of it. These
days, you almost can't find a Linux system that doesn't have both
installed, but in the rare cases where there's only one default (as
opposed to only one because some user specified it that way), it's
usually vi. I'm happy with vi, but others are happy with emacs. You'll
have to investigate both for yourself. There are better T-shirts
available for vim, though.
vi vs. vim: These days, unless you find yourself at a really old
system, vi means vim. Anything vi, generally speaking, works flawlessly
in vim. Unless you're specifically speaking of an old-school vi, the
terms are almost interchangeable in common parlance. I kinda wish they
weren't, personally, but I'm weird that way.
bash: You'll find bash basically everywhere, with rare exceptions.
What others will be available (if there's more than one shell available
on a given machine) is pretty much a crap shoot. There are rare
exceptions to the "bash is the default shell", but I haven't (ever)
personally found myself using a system that defaults to a different
shell. I started learning bash, and I never needed to learn others.
All unix shells (as far as I'm aware) are close to interchangeable, but
there are some syntax differences that will trip you up if you're not
careful.
perl: This is a programming and scripting language. If you have it
installed, you can run commands directly from the command line and you
can run Perl scripts just like you'd run shell scripts. Perl is far
more powerful, complete, and flexible than shell scripts, but for
purposes of piddling around with something on the level of a batch file
you don't need it. I, personally, hardly know anything about writing
shell scripts or how to use the more common command line utilities
because I started learning Perl first, and have just never found myself
needing to learn shell scripting much: I can do everything you can do
with a shell script. Perl is pretty much the ultimate unix
administrator's tool, often called the "Swiss Army chainsaw" of unix
(because it makes the Swiss Army knife look useless, but is capable of
cutting off entire limbs if you do something really careless and
stupid), but it's not necessary by any means. I recommend starting with
shell scripts, and learning Perl only if you find you have a need for it
-- in other words, do the opposite of what I did. (By the way, if
you're going to discuss Perl, it might be useful to learn about
capitalization. Y'see, if you say Perl (first letter capitalized),
you're talking about the language, but if you say perl (all lower-case),
you're talking about the interpreter. Calling it PERL is something only
the uninitiated do, pretty much.)
built-in: Basically, nothing is "built in". That's not strictly true,
but it's true "enough" for a beginning assumption. Anything with which
you, as a computer user, actually interact can probably be assumed to be
a utility, server, application, et cetera. While it uses a monolithic
kernel (OS architecture term meaning the lowest-level functions are all
part of one big program), it doesn't suffer the integration nightmare
that certain other OSes do (such as just about anything that starts with
W). Being more modularized than that makes it more flexible, more
secure, and a number of other good "more" things. There's sort of a
traditional (though not strictly universal) unixy philosophy of design
that is often expressed as "does one job and does it well". Each job,
often, is done by one tool, discrete and separate from all other tools.
Complex jobs are broken up into individual parts and delegated to
other tools by a tool whose job that delegation is, giving the illusion
of integrated functionality in one piece of software. This approach
maintains simpler, less bug-prone software, usually. This is, however,
decreasingly applicable in the age of the GUI.
Hopefully, this answers some of your questions (both explicit and
implicit). I'm sure someone will disagree with some of what I said,
though they'll probably do so politely here.
-- Chad
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:36:38 EDT