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.
What practical, objective differences are there between Emacs and Vim? For example, what can be done using one but not the other (or done more easily with one than the other)? What should I know in order to choose one to learn?
(the text below is my opinion, it should not be taken as fact or an insult)
With Emacs you are expected to have it open 24/7 and live inside the program, almost everything you do can be done from there. You write your own extensions, use it for note-taking, organization, games, programming, shell access, file access, listening to music, web browsing. It takes weeks and weeks till you will be happy with it and then you will learn new stuff all the time. You will be annoyed when you don't have access to it and constantly change your config. You won't be able to use other peoples emacs versions easily and it won't just be installed. It uses Lisp, which is great. You can make it into anything you want it to be. (anything, at all)
With Vim, it's almost always pre-installed. It's fast. You open up a file do a quick edit and then quit. You can work with the basic setup if you are on someone else's machine. It's not quite so editable, but it's still far better than most text editors. It recognizes that most of the time you are reading/editing not typing and makes that portion faster. You don't suffer from emacs pinkie. It's not so infuriating. It's easier to learn.
Even though I use Emacs all day every day (and love it) unless you intend to spend a lot of time in the program you choose I would pick vim
Vim is not a shell. And it does not communicate well with subprocesses. This is nearly by design, whereas in Emacs, these elements are included by design. This means that some stuff, like embedding a debugger or an interpreter (yielding a sort of IDE), is difficult in Vim.
Also, Emacs shortcuts are mainly accessed through modifiers, and obviously the Vim interface is famously modal, giving access to an absurd amount of direct keys for manipulation.
Emacs used to be the only editor of the two that was programmable, and while Vim has a lot of weird levels to its programmability, with the addition of Python and Ruby bindings (and more, I forget), Vim is also programmable in most ways you'd care for.
I use Vim, and I'm fairly happy with it.
Vim:
better as a simple editor (fewer keys required for simple tasks)
more active scripting community - internal language: vimscript
one central repository of scripts, plugins, color schemes, ...
also extensible in python, ruby
can be made portable (emacs has some problems with that)
Emacs:
non modal by default (most of today's editors have taken this approach). Though there is evil-mode which emulates vim behavior.
more powerful language for extending it (elisp is a full blown language, and in emacs you can practically redefine everything; while in vim you cannot redefine build in functions of the editor. On the downside, vimscript is relatively similar to today's dynamic languages while elisp doesn't resemble pretty much anything)
more extendible
excellent support for GNU tools (the bunch of them)
Personally, I prefer vim - it is small, does what it's supposed to do, and when I wish a full blown IDE I open VS. Emacs's approach of being an editor which wants to be an IDE (or should I say, an OS), but is not quite, is IMHO, outdated. In the old days having a email client, ftp client, tetris, ... whatnot in one package (emacs) made some sense ... nowadays, it doesn't anymore.
Both are however a topic of religious discussions among the programmer and superuser community users, and in that respect, both are excellent for starting flame wars if put in contact (in the same sentence / question).
If you are looking for an objective analysis of both the editors, look at their origins and the philosophy behind their respective designs. Think, which one would suit you better and learn it (and learn it and learn it, because it takes time before you being to discover its true utility as against any IDE).
An Introduction to Display Editing with Vi was written by Bill Joy and Mark Horton and he explains why he choose modal design and rationale for various key strokes ( it helps me to remember that CTRL-W +W (will switch to next Window and it will same for CTRL W+ CTRL W, just in case you held the CTRL key for a longer duration.
Here is a link to Emacs timeline and has the reference to Multics Emacs paper. Hereis RMS paper on Emacs, where I see the stress is on a programmable text editor (even way back in 1981 and before).
I have not read the emacs papers, but have read Bill Joy's vi paper a couple of times.
Both are old, but still you will get the philosophy and you might choose to use the current tool (vim 7.x or emacs 25?)
Edit: I forgot to mention that it takes patience and imagination to read both these papers as it takes you back in time while reading it. But it is worth.
Vim was always faster to start up than Emacs. I'm saying that on any machine, out-of-the-box installs of Vim will start up faster than out-of-the-box installs of Emacs. And I tend to think that after a moderate amount of customisation of either one, Vim will still start up faster than Emacs.
After that, the other practical difference was Emacs' modes. They make your life tremendously easier when editing XML, C/C++/Java/whatever, LaTeX, and most popular languages you can think of. They make you want to keep the editor open for long sessions and work.
All in all, I'll say that Vim pulls you to it for short, fast editing tasks; while Emacs encourages you to dive in for long sessions.
VI is always available and will run on the most crippled, single user mode, broken graphics, no keymap, slow link machine - so it's worth knowing how to edit simple files in it just for sysadmin tasks.
Emacs is a complete user interface in an editor. The idea is that you fire up Emacs when you start the machine and never leave it. It's possible to have thousands of sessions present.
Whether learning the capabilities of Emacs are worth it compared to using a GUI editor/IDE and using something like python/awk/etc for extra tasks is up to you.
I'm a full-blown Emacs fan-boy, but I knew VI long before I knew Emacs. That said, I make all of my people learn VI because it's always available, everywhere. Can't go wrong with either one of them.
Seems an answer has been selected already, but the big difference to me has always been the modal vs. non-modal. Vim is modal, which means that it makes optimizations based on a specific set of usage modes. At least that's how I've always looked at it. This makes using Vim a different experience because instead of having a work area that you type code in, you really are telling an environment to act on the text. This is why people say things like with Vim you really are learning a language. The :wq and :s/foo/bar is all part of a shell like environment that edits and reads text.
Emacs on the other hand is much closer to most editors/word processors/etc. you see today. You have a workspace that has a highly programmable interface. That is why you see things like email, irc, shells, etc. As a programmer it is easy to think in terms of saying "take the line number I'm on and do something with the information". The desire to leave the editor becomes less because instead of having to quit, open some other app/language and do things on some text, you have Emacs where you can do these things within the scope of your editor.
The two ideas are not necessarily contrasting, but it is simply that they reveal two different focuses. Personally I use Emacs, but I've seen folks who know Vim really well and can honestly say it doesn't matter which you choose. I tried Vim first but Emacs ended up sticking for me. It is true that no matter what you choose, you should be at least somewhat proficient in Vim as it really is always available.
There is a huge difference on a day-to-day level - Vim (or any vi variant) is inherently modal (you go into command modes where you cannot edit) and Emacs (along with most other editors) are not.
Sure, using menus and such you don't have to actually enter command mode in Vim - at first. But to use even a tiny fraction of the power of Vim you will. That is at the heart of the Vim/Emacs debate.
Personally, I also think Emacs is far more extensible. You can find Elisp packages for many things.
I am curious, though, why you are thinking to learn one of these over a more traditional IDE. What is it you want to learn one of these for?
I started with vi, went to emacs, then to vim. I've been thinking of trying out Emacs to see what's changed in the last five years. (Speaking of IDE's, I had gotten into eclipse for a while, but I prefer my terminal window connecting my mac to my (husband's) linux box).
The cut and paste thing has been bothering me lately. Cut and paste in Vim takes more steps than in Emacs, IIRC. And pasting from say a browser to a terminal window is irritating unless you do something fancy that I don't feel like doing, so I put up with the weird indentation. I think, editing multiple files in emacs was easier. At least jumping from one file to the next if you have them both up on the screen.
I haven't played with the fancy features of either vi or emacs, as I just like to get to the business of coding. All I need is the pretty colors and proper tab to space conversion (especially important with python).
I think it all depends on if you want to use :wq or Ctrl-x Ctrl-s (IIRC) to save a file if you don't care about the fancy stuff.
#mgb was correct. I've been in the bare minimum linux to fix something just a month or two ago in a Debian distro. vi was the only editor available.
There is a lot of thing that have been said about both editors, but I just have my 5 pence to add. Both editors are wonderful and you cannot go wrong with either of them.
I am a vi/vim user for about 15 years now. I've tried converting to emacs several times but every time was rather discovering that vim actually can do the missing thing out of the box without the need to write a lisp extension or install something.
For me the main difference in the editors that vim makes you use the environment/OS, while emacs tries to encapsulate it or replace it.
For instance you can add a date in you text by :r!date in vim, or calendar with :r!cal 1 2014, or even replace the contents of you buffer with the hex version of the contents. Eg. :%!xxd, edit hex and then get back with :%!xxd -r, and many more other uses, like builtin grep, sed, etc.
Another example is use with jq and gron. Eg. paste json blob to the editor and then run for tranformation:
:r!curl -s http://interesting/api/v1/get/stuff
:%!gron | grep 'interesting' | gron -u
OR
:%!jq .path.to.stuff
Each of the piped commands above can be run separately via :%!<command>, where % means all document, but can also be run on selection, selected lines, etc. Here gron output can be used as jq path.
You also get the EX batch editing functionality, eg. Replacing certain words, reformatting the code, converting dos->unix newline characters, run a macro on say 100 files at a time. It is easily done with ex. I am not sure if emacs has something similar.
In other words IMHO vim goes closer to the unix philosophy. It generally simpler and smaller, but if you know your OS and your tools, you wont likely need more than it(VIM) has to offer. I never do.
Besides vi is defacto standard on any unix/linux system, why learn to use 2 tools that do the same thing. Of course some systems offer mg or something similar, but definitely not all of them. Unix + Vi <3.
Well, just my 5 pence.
I would like to put here a quote from the book "The Art of UNIX Programming":
Many people who regularly use both vi and Emacs tend to use them for
different things, and find it valuable to know both.
In general, vi is best for small jobs – quick replies to mail, simple
tweaks to system configuration, and the like. It is especially useful
when you’re using a new system (or a remote one over a network) and
don’t have your Emacs customization files handy.
Emacs comes into its own for extended editing sessions in which you
have to handle complex tasks, modify multiple files, and use results
from other programs during the session. For programmers using X on
their console (which is typical on modern Unixes), it’s normal to
start up Emacs shortly after login time in a large window and leave it
running forever, possibly visiting dozens of files and even running
programs in multiple Emacs subwindows.
What I really want to highlight here is the: «Many people find it valuable to know both.»
For me pros of emacs are,
tramp-mode allows you to edit remote files over ssh. just like local files.
tramp-mode + dired = full featured sftp client
support for every language you will ever need.
built in terminal emulator(term-mode) so i can keep coding without switching between applications.
extensibility anything you don't like you can change using lisp.
For me, emacs has better development tools(not only tags based tools).
Cedet(c/c++)
Xrefactory(c/c++/java)
Slime(common lisp)
JDEE(java)
ECB(code browser)
GDB Support
NXML(xml)
Benefits of Emacs
Emacs has both non-modal interface (by default) and modal one (e.g. it can emulate vim and vi through Evil, Viper, or Vimpulse).
One of the most ported computer programs. It runs in text mode and under graphical user interfaces on a wide variety of operating systems, including most Unix-like systems (Linux, the various BSDs, Solaris, AIX, IRIX, macOSetc.), MS-DOS, Microsoft Windows, AmigaOS, and OpenVMS. Unix systems, both free and proprietary, frequently provide Emacs bundled with the operating system.
Emacs server architecture allows multiple clients to attach to the same Emacs instance and share the buffer list, kill ring, undo history and other state.
Pervasive online help system with keybindings, functions and commands documented on the fly.
Extensible and customizable Lisp programming language variant (Emacs Lisp), with features that include:
A powerful and extensible file manager (dired), integrated debugger, and a large set of development and other tools.
Having every command be an Emacs Lisp function enables commands to DWIM (Do What I Mean) by programmatically responding to past actions and document state. For example, a switch-or-split-window command could switch to another window if one exists, or create one if needed. This cuts down on the number of keystrokes and commands a user must remember.
"An OS inside an OS". Emacs Lisp enables Emacs to be programmed far beyond editing features. Even a base install contains several dozen applications, including two web browsers, news readers, several mail agents, four IRC clients, a version of ELIZA, and a variety of games. All of these applications are available anywhere Emacs runs, with the same user interface and functionality. Starting with version 24, Emacs includes a package manager, making it easy to install additional applications including alternate web browsers, EMMS (Emacs Multimedia System), and more. Also available are numerous packages for programming, including some targeted at specific language/library combinations or coding styles.
Benefits of vi-like editors
Edit commands are composable
Vi has a modal interface (which Emacs can emulate)
Historically, vi loads faster than Emacs.
While deeply associated with UNIX tradition, it runs on all systems that can implement the standard C library, including UNIX, Linux, AmigaOS, DOS, Windows, Mac, BeOS, OpenVMS, IRIX, AIX, HP-UX, BSD and POSIX-compliant systems.
Extensible and customizable through Vim script or APIs for interpreted languages such as Python, Ruby, Perl, and Lua
Ubiquitous. Essentially all Unix and Unix-like systems come with vi (or a variant) built-in. Vi (and ex, but not vim) is specified in the POSIX standard.
System rescue environments, embedded systems (notably those with busybox) and other constrained environments often include vi, but not emacs.
Source: https://en.wikipedia.org/wiki/Editor_war
The biggest difference for me in choosing to use emacs over vim was the built in gdb support in emacs. Vim doesn't have this included in it's default distribution and the project there for integrating gdb and vim was nearly impossible to get working with MacVim
Now you do not even need to think about the difference between these two because of Spacemacs. It is a community-driven Emacs distribution.
As it said,
The best editor is neither Emacs nor vim, It's Emacs and Vim.
Spacemacs combines the best from both Emacs and Vim, which make your life and job much easier.
See screenshot below,
(source: spacemacs.org)
Its like apples and oranges. Both have different design and philosphy. Vim is a Text Editor while Emacs is a Lisp Interpreter that does Text Editing.
I use Vim because its fast, sleak, and really good at manipulating texts. It has a composable natural key binding that can make your development tasks really harmonic. Vim is based on the simple *nix philiosphy of doing one thing really well - i.e Text Manipulation.
Extending Vim using bash/zsh and tmux is usually easy and allows you learn a lot of things. IMHO this is a good learning curve. The key thing is to learn how to integrate these things to get a larger working application. With Vim you'll need to learn integration because it doesn't naturally integrate unless you tell it how to. Another worthwhile extension which I use is Tig . Its an ncurses based Git frontend . I just have a binding that opens Tig silently and then I do all the Git stuff there.
Its up to the end user to decide what works best. That Emacs and Vim has stood the test of time is proof of their worthiness. Eventually a good programmer needs nothing more than a pen and a paper to be creative. Good algorithms don't need editors to back them. So try them both and see what makes you more productive. And learn design patterns from both these softwares as there are plenty to learn and discover!
Emacs has viper-mode, so in some real sense, it provides a superset of features (excepting those described in What Vim features are missing in Emacs with Viper and Vimpulse?).
vi (and VIM IIRC) is lighter weight (it can edit files in place), but offers fewer features (subprocess communication, extension language).
Emacs is really more of a do everything program, and vi(m) is really just an editor. If you are editing text, they are both fine, but I prefer emacs, simply because I have to shift one off the home row to move around, and keep typing the wrong things in command mode. I you don't have that problem, vi(m) may be the editor for you.
A jaundiced point of view:
vi (not vim) is a professional necessity. You always have some form of
vi easily available, no matter what the environment. You can be in vi
when in emacs, you can be in vi to build bash commands in unix-land.
Even Microsquish has to support vi (although they do a good job of
hiding it) because of gov't and corporate compliance with published
standards.
In my opinion, if you are in a hands-on job in a busy environment--not
a hothouse flower confined to one fancy rig in a development
environment, or in academia--knowing a lot about a fancy editor is a job
handicap. Don't learn all the fancy tricks in vim or emacs, and don't
develop a bunch of macros to make the editing environment bend to your will.
It's an enormous time sink that gets in your way when you attend to
different machines that you probably can't justify in a factory
environment.
Read Bill Joy's paper--it is a very competent, perhaps even
beautiful, engineering exercise in editing plain text very, very
fast. Parito's rule applies here: 80% of the fruit is in 20%
of the baskets. Editing plain text very very fast is the crux of
editing competence--all else is optional--and sometimes hurtful.
In your question, you haven't mentioned that you want it to program in Lisp! But as you have been commenting your answers, I have understood that you actually want a LISP programming interface.
For that precise task, simply forget about Vi. Emacs integration with LISP is wonderful! You should use SLIME. You will then have wonderful integration with the REPL, being able to eval functions, buffers or files directly into a running interpreter in an emacs buffer and much more...
I was user of vim first, then I switched to emacs, then to vim, now I'm experimenting with emacs again.
Both are great editors.
Both are very extensible today
Both have great plugins and community
As developers we type a lot, and, at last for me, moving around in buffers and files are the biggest repetitive tasks, so I want a editor where I CAN MOVE FAST!
The motivation for experimenting with emacs again is that I fell it Ctrl leaded keybinds faster than vim, and easier to reason about.
In vim you have modes, you have insertion mode, visual mode, normal mode, what happens when you press something depends on the mode that you are, is a stateful aproach to editing. You move, enter in insert mode, edit, get out of insert mode and move again. I frequently lose my self if I miss a ESC press or something like this.
In emacs there is no mode, basically you press Ctrl with your pink and type the keystroke, like C-x C-f, C-x C-s, C-x C-c. There are keybinds where you need to release ctrl key, I hate this ones and always replace them by ones with control pressed.
I think that emacs approach is faster to think and type, but vim has another strength, to. Its commands are composable, they usually has a format . For example, to delete a line you can use dd, to delete a word dw. Plugins make use of that felling, with vim-surround plugin you can delete quotes with ds" (delete surround "), delete up to next / dt/. Delete up to previous /: dT/ and so on. So as long as you learn the moving things start to get very interesting.
Summing up, today I fell that emacs keybinds are faster for macro editing and vim commands are more powerfull for microediting
I've been using vim for the last five years so I edit thinking mainly about words, lines, surrounding, blocks, etc. Delete this line, remove quotes, replace quotes,
delete word in cursor, I'm trying to findout the emacs moves for that
As a final quote I would say that, I care more about fzf than about emacs or vim, I would love to have a editor that is completely fzf based
If you move around a lot from site to site or your job involves loging on to production systems then vim is the way to go.
All *nix machines will have vi installed by default.
Most sysdamins prefer ksh as the default shell. ksh uses vi (or emacs) command keystrokes to search history and edit the command line.
If you dont know vi well you are severely handicapped when you log into a unix box with a standard configuraton.
For this reason alone I would recommend vim as your normal every day editor. I have seen emacs fans tear there hair out trying to amend config files on a bare bones unix server.
vim is a handy editor, you simple type vim filename to open the file, edit, save and close.
emacs is an "operating system" pretend to be an editor, you can eval code to change its behavior, and extend it as you like. A mode to receive/send email on emacs is like an email software on operating system.
When doing simple editing, for example, modify a config file, I use vim.
Otherwise, I never leave emacs.
I am an Emacs fan but encourage other developers to learn VI because:
you can use VI to edit the emacs makefiles.
VI includes ed commands and every UNIX user should know ed and sed.
I've noticed several comments about VIM starting faster than emacs. If you really care about that, run emacs in server mode and alias 'emacs' to 'emacsclient'. The client is super fast since all it does is tap the server on the shoulder and tell it which file you want to edit. On MacOSX, emacsclient is only 33K while emacs is 287M.
I'm not sure any of this is necessary on modern hardware. On my MacBook Pro (2013 Retina), emacs loads almost instantaneously when I run it from the shell. I detect no pause at all. When I run Emacs.app (the GUI version) it might take all of 3 seconds.
Most complaints I hear about emacs seem to come from people misinformed about emacs. Having used both vi and emacs since 1982, I definitely remember a time when emacs loaded much slower than vi and used most of the physical memory in my early UNIX boxes, but that is no longer the case and has not been for at least 15-20 years.
One complaint I will concede is "emacs pinkie". This never bothered me at all when I was younger. Now that I'm 58, my pinkie does get a bit sore from repeatedly accessing the Control key for emacs chording. This is especially true on the MacBook Pro keyboard where Control is moved one position to the right to make room for the "fn" key. It's not nearly as annoying when Control is the bottom left key.
I have worked with spacemacs for about 2 years and neovim for about a year now in a production/research environment. Spacemacs is emacs with couple of nice extra features like layers etc. And neovim is a fork of vim again with some extra features.
I am quite unsatisfied with both of them in terms of experience. And I am still on the look out for a long term solution for my text editing needs.
Here is a simple comparison:
Neovim, vim, emacs, spacemacs, etc all of those editors consume less ressources compared to most of the editors out there.
Neovim/vim is slightly faster than emacs, noticably faster than spacemacs.
In terms of editing experience. I can easily say that emacs packages feel superior. I think that's because they blend in better with the core of emacs.
Vimscript is nice and there are certainly great projects in the vim ecosystem as well. The good thing is they are better documented than most emacs projects I have seen so far.
Both can be glitchy depending on the package you are using. Spacemacs tend to freeze, and neovim tend to display scary error messages, so pick your poison there.
Modal editing in vim, is not an intuitive concept, but once you get used to it, you want it anywere. Both of the editor provide that.
Keystroke execution:::
vi editing retains each permutation of typed keys. This creates a path in the decision tree which unambiguously identifies any command , whereas Emacs commands are a combination of typed keys executed immediately, which leaves the user with the choice of whether or not to use a command.
Memory usage and customizability:::
vi is a smaller and faster program, with a more limited capacity for customization, whereas, Emacs takes longer to start up and requires more memory. However, it is highly customizable and includes a large number of features, as it is essentially an execution environment for a Lisp program designed for text-editing.
I think the main difference is the design target.
VIM is for UNIX as a working editor.
Emacs is for GNU and lisp hackers, so it has some mixed design element.
I use vim on my workstation, while I love emacs too.
Firstly Vi (original realization) not used today. That you say is some Vim derivation.
To extend Vim functionality you must recompile Vim, Emacs not.
Emacs has Vim in self (viper-mode).
Emacs usually need manually installation, Vim typically preinstalled on all Unix like OS (but if you have ssh access to host tramp-mode win Vim :).
If you try Vim you hate Emacs, so start from Emacs first.
Also read http://www.dina.dk/~abraham/religion/vi-tutorial.html (link go down so use this)
Anwer search in hxxp://en.wikipedia.org/wiki/Editor_war
I have recently started moving into the world of Linux development. I wanted to learn some new things and thought bash might be fun. As I learn more about bash programming I have found that there are quite an assortment of useful tools to be used (such as grep, tr, awk, etc.) There are so many that I just do not know which ones are "vital" to learn.
Shell scripting commands depend heavily on the configuration of the system itself, and can change drastically over time, unlike most programming languages (where a core library ships with the language itself and represents the "core" set of commands that a programmer would use when interacting with the outside world). Therefore,
As a modern Linux shell script programmer, which command line tools should I be familiar with?
Compressing and uncompressing various archives.
Using the man pages
alias is always helpful
as mentioned by others sed & grep (RegEx is good to know in general), sort, head, tr, cut
echo & printf (their differences and when to use what)
Getting the return value (not as useful but still handy when writing scripts) via $?
top, ps, kill, how to background/foreground/suspend a process
The important thing is combining the many tools that exists and where most become extremely useful. Using man whenever you are stuck is probably the most important thing.
I'd recommend especially that you become familiar with locate, grep and find. sed, awk and vim are next, and around these are cat, less, tail / head, ls (yes, ls!), and the many ways in which bash can help you.
Especially about Bash: beware of bashisms!
Depends on what you're doing, obviously, but I get a lot of mileage out of find, grep, rsync, and ssh. The simple ones are useful, too: cat, tail, wc, ps. There's a lot you can do with a for loop, too, and wildcard syntax is essential. For example,
$ for i in {app,web}{01,02}; do ssh $i date; done
That will ssh into hosts app01, app02, web01, and web02 and execute the date command on each one.
Try looking at commandlinefu. People come up with all sorts of things there, and you're bound to find examples of stuff which may be useful in the future.
But generally, top used commands, by John are nice as a guidance.
And of course, here be dragons, list of stuff you shouldn't do: deadly ones
You should know some console-based text editor. Pico might suffice. I myself am a vi guy, though Emacs is also acceptable. (Though I will recommend vi: that is a de-facto standard on nearly any platform of Unix, and things like grep/sed behave very similar to vi.)
Others:
Screen: extremely useful when you don't have a GUI or don't want to/can't open up many terminal windows or PuTTY sessions. Allows you to have multiple shell sessions open, and you can toggle between them (and many other things.
top: good for monitoring processes, CPU usage, and memory usage
watch: runs a command every "n" seconds and displays its output. E.g., watch -n 1 "ls -aio" executes "ls -aio" every time 1 second.
you should probably know everything on this list:
http://www.faculty.ucr.edu/~tgirke/Documents/UNIX/linux_manual.html
maybe not everything is essential all the time, but knowing at least a cursory overview of each can help a lot for basic functionality.
perl, xargs, lsof, find, grep, bash, tar, gzip, tr, tail, diff, patch, and bc.
And everything that is in SUS2 (Single UNIX Specification).
Like you mentioned, learn awk, sed and grep. They will be very good friends of yours.
Also, very important, learn to use properly a text editor such as vim.
I would also recommend you to get familiar with a good scripting language such as perl or python.
Don't worry about the commands directly. Rather when you find yourself struggling with something try a few quick Google and man page searches and see how you can improve what you're trying to do right then and there. Keep it relevant and you will get more useful results.