What should a longtime Windows user know when starting to use Linux?

Question

We've finally moved our websites to a decent host, and for the first time we have Shell Access.

I know very little about using Linux, I can navigate through the file system, read files with Vim and I'm aware of the man command, and I have been able to work out solutions to problems as they show up (eventually), but I know I'm unaware of a lot.

Edit: We currently only use the host to hold our live sites, I'm sure that we use it more effectively, but I'm not sure where to start.

So with Web Development in mind:

• What are the essential commands that every Linux user should know about?
• What are the most useful commands that I should look into?

Answer 1

Find out the distro they run (e.g. Ubuntu) and focus on that first. Use VirtualBox or another VM to play around, especially networking and the Daemons that your host is using.

Answer 2

less [file name] - shows contents of file screen by screen

I'd recommend that over reading the file through vim. Also, pico and emacs are a little more friendly than vim for noobs.

Answer 3

Let's see...

the basics: cd, ls, mv, cp, mkdir, rm, cat, man

the good ones: ps, chmod, chgrp, sudo (or su), pwd, grep, head, tail, xargs, less, find, awk, sed, ssh/scp, ping, touch, locate/updatedb, ln, kill, echo, wc, passwd, tar, diff, df, du, free, reboot

and the operators: |, >, >>, &&, and ||

... and all the useful associated command line options therein. I could probably come up with another 20 if I thought about it more.

Answer 4

1. more/less: view a file in your command prompt.

   more myfile.txt
   

2. grep: find keywords using regular expressions in a file, group of files or recursively in all files

   grep hello myfile.txt
   grep hello *.txt
   grep -r hello .
   

3. understand pipe (the '|' character)... it lets you chain things together nicely.

   grep -r hello . | grep txt:
   

   (will recursively grep for hello, then grep those results for "txt:" which if you look at grep output, you will see the above means it was found in a file ending in txt)

4. su will let you "switch user", with no argument will be to root, with an argument will be to another user

5. sudo will let you execute a command as root, if you are on the sudo list

   sudo more /path/to/root/only/accessible.file
   

Those are the first few I can think of off the top of my head that should prove really helpful, but I'm sure there are many more that are useful.

Answer 5

Treebeard's Unix Cheat Sheet

Answer 6

This article on linuxguide.it is a fairly comprehensive list of commands but here are a few of the ones I find I use most frequently:

1. ls -la (lists the contents of the current directory, including hidden files)
2. tar cvzf output_file.tar.gz directory/ (tars and gzips all of the files in directory/ into output_file.tar.gz)
3. tar cvzf file.tar.gz (unzips and untars the file, restoring the original directory structure and keeping all permissions intact)
4. man binary (displays the man page for binary)
5. chmod (changes the permissions on a specified file, use man chmod for more details)

Hope that helped at least a little bit, check out the link above for a better list.

Answer 7

Don't forget you can pipe things to the more command which will give you a single page of output and prompt you to continue. I use this most often with ls -la | more (emulates the standard dir command) and I also sometimes pipe (|) grep searches to more.

Answer 8

Seeing that this seems to be a web host, you will probably want to know:

• How to start/stop/restart the webserver (Distro/server dependent. Try /etc/init.d/apache restart to restart.)
• How to check the logs (Distro/server dependent. Try less /var/www/apache.log)
• How to access MySQL directly (mysql -u myusername -p and mysqladmin)
• How to upload/download files (Probably using SFTP on the client end)
• How to edit the webserver configuration (Probably nano /etc/apache2/httpd.conf)
• How to check/edit UNIX permissions and ownership (ls -l to check and chmod XXXX files and chown newowner.newgroup files to change)

These are all using complete guesses for file locations etc. and assume that you are using Apache. A bit of investigation is probably needed for your particular setup.

A special mention goes to permissions. This causes much of the headaches with running CGI's and security. Below is a rough guide to what permissions should be set.

• PHP files: readable by web-server (chmod 640 filename.php)
• CGI scripts: executable by webserver (chmod 750 filename.cgi)
• Static web files: readable by webserver (chmod 640 filename.html)
• Directories: executable by webserver (chmod 750 directoryname)

These settings assume that the webserver process is running as a user who belongs to the same group as the webserver files (this is likely the setup on a managed host).

A final headache that may cause trouble is that Linux is case sensitive. When serving static files from Apache, by default you will need to include any weird capitalisation. It's generally a good idea to stick to lower-case and underscores/hyphens for naming directories and files.

Answer 9

Fosswire Unix/Linux Command Reference

My advice would be to install a distribution (or use a LiveCD) on one of your own machines and play around with it first, and then, once you're confident enough to move on fiddling with the production server.

Answer 10

This is a little more broad range & general of a suggestion but I found Unix System V: A Practical Guide (Mark G. Sobell) was a great...I repeat...great book to learn the basics from (albeit it was my academic textbook). Like I said, you might be more interested in something a little more distro-specific, but for the general Unix goods I can't recommend this reference enough.

Answer 11

I don't want to get into a religious war here, but regardless of your eventual text editor preference pico and nano are the easiest to jump into because the essential keyboard commands are all displayed for you at the bottom of the screen. I've long been told that vi would be worth using but for when you just need to change one line in a config file its nice not to have to spend 15 minutes trying to remember how to save and quit.

That said, if you do find yourself in vi you can press escape to enter 'command mode' (or whatever it is called) and :wq will save and quit.

I only mention this because of all things Linux related trying to exit vi is the thing that frustrated me the most until I learnt how!

Answer 12

Baby steps...

Most of my command line stuff is integrating with our code. svn up, svn commit, svn merge, and so on.

Personally, what I've found very useful is a basic knowledge of bash scripting, ruby scripting, and (absurdly) colordiff

Command line stuff requires a pile of typing, but that's one of the main reasons why scripting exists.

For example, I can't for the life of me read svn diff output on the commandline. Piping it to the colordiff utility makes a world of difference.

It's then one more step to create a bash function to save you typing svn diff | colordiff | less -R all the time.

If you read man colordiff you'll see they define a function in your ~/.bashrc file, mine goes something like this

function sdiff() { svn diff $@ | colordiff | less -R; }

The $@ means 'All arguments', otherwise arguments are $1, $2, etc, and the rest should be fairly self explanatory. You can then apply this knowledge you now have to other repetitive actions, and before you know it, you'll be a guru.

Sometimes bash gets a bit hairy (like when you want to do anything more complicated than piping a few programs together) and in those cases I've found just writing simple ruby scripts to be the way out. Ruby is awesome.

Good Luck! :-)

Answer 13

Oh, I also use less to look at log files. It's a WHOLE LOT BETTER if you know some shortcuts (these also work in vim)

• /regex - Search for the next text which matches regex
• n - Jump to the next match for the regex you just typed
• N - Jump to previous match
• ESC - Cancel searches and get yourself out of trouble
• g - Jump to start of file
• G - Jump to end of file
• 72g - Jump to line 72

Answer 14

If you've had to type a long command, and for whatever reason you need to type it again there's a neat (well, it's neat to me, anyway) trick.
Providing you remember at least a part of command on the line you typed, use

history | [part of the line]

This will return a numbered list of the command in the history buffer (which generally stashes about 1000 lines) which contain [part of the line].

You can then quickly re-run it by typing

![linenumber]

Answer 15

mc (midnight commander) is quite helpful - it's a text-mode Norton commander clone, useful for getting an overview of the file system, copying/moving files, has an integrated text viewer/editor which is a bit more friendly than vi and much more. It's not installed by default on all systems, though.

Answer 16

As a relatively new Linux user myself there are a few commands and tools that I have come to rely on.

Find - I use find every day along with xargs. Find is very flexible and its useful to start out small and start building on top of that. Using xargs and find, you can execute commands on the files you've found. I often use this to zip files I've recently edited or search through files using the next tool I'd suggest.

grep - I use grep to search through log files and code mostly. Grep is a very powerful tool and can be used with Regular Expressions for very powerful searching. Grep is very powerful is fairly easy to start out with. Once you get comfortable with it, keep adding more complex/specific searches to help get better using grep.

Cron - Cron is a powerful scheduling service that lets you run commands, scripts, programs at specific times, intervals, etc. Cron is used to rotate logs, run backups, you name it. If you want to run something regularly, learn how to use cron.

A solid text editor - I use Vim as my text editor, but this is more of a choice thing. I'd suggest that you try out several and find one you like the most and stick with it. I find its easiest to just skip the more simple editors and use more powerful ones so you can grow and learn the more advanced features as you get better.

It also helps to learn some basic shell scripting and have a basic understanding of your distribution's file system.

Answer 17

Personally, I found slicehost a big help with setting up webservers on Linux, and this eventually helped me make the transition to Linux as my desktop OS. They have tons of articles covering various distros, security concerns and web stacks, and should be helpful even if you're not hosting with them.

http://articles.slicehost.com/

Answer 18

There is the common ls, cp, ln, mv, grep, man, kill, ps.

One thing I would definitely recommend apt-get, and aptitude, to be able to uninstall some program, or library you really need.

I would also recommend reading the Advanced Bash Scripting Guide, to help you automate anything that you happen to do often.

Answer 19

A more philosophical answer:

Unix (in all flavors) is built on a single big idea:

Difficult problems can be solved by solving easy problems first.

You might recognize this as the Bottom-Up approach. But Unix takes this philosophy to an extreme. It's like living in a foreign country: you need to enculturate.

For instance, suppose you are working on a system that requires three separate servers. Every morning, you type in three different commands to start them up. At some point (hopefully on day two), you decide it's silly to type those same three commands each time you want to start work. You might be tempted to write an application that controls those servers, but that's not the Unix way. Instead, you should put those three commands in a script and move on.

Later, when you are ready to go into production, you want to show the startup process to your customer. It's a bit embarrassing to show off the startup script, so you write a little GUI that has a startup button for the customer to press. That button simply calls the script you wrote back on day two. Problem solved!

If that scenario strikes you as odd or horrifying, you are still thinking like a Windows programmer. And in some ways it is horrifying: a little helper script has become part of production code almost by accident. But this sort of thing happens all the time on Unix systems and it mostly works.

There's not much point in listing commands that you need. If you use the command line long enough, you'll figure out what you need fairly quickly. Instead, I'd focus on trying to do everything in the shell for a while. (I use ksh exclusively for writing scripts and bash for my interactive shell. They're similar, but geared toward slightly different uses.)

I don't believe anyone who does not understand pipelines can be said to be a Unix programmer. A fairly common idiom that I found helpful to grokking pipelines was the output of find piped into xargs. Right now, for instance, I need to remove a bunch of files that I own. First I find the files:

$ find . -user jericson

Then I pipe the results to xargs to remove them:

$ find . -user jericson | xargs rm

Be sure to look at the -i option for xargs as well.

Note that I broke the problem into two smaller problems and solved each one separately. I actually ran the find command by itself to be sure I was looking at correct files. Then I piped the results to the second command as input. Using the pipeline avoids an intermediary file.

Answer 20

If you're going to be doing development on Linux, I'd recommend skimming "The Art of Unix Programming" by Eric S. Raymond. This book is less about the details and more about the differing philosophies that are behind Windows and Linux. It will help you think like a Unix developer and make all the weird things more understandable. As Eric says in the introduction:

You should read this book if you are a non-Unix programmer who has figured out that the Unix tradition might have something to teach you. We believe you're right, and that the Unix philosophy can be exported to other operating systems. So we will pay more attention to non-Unix environments (especially Microsoft operating systems) than is usual in a Unix book; and when tools and case studies are portable, we say so.

Answer 21

An extremely helpful command that doesn't seem to get mentioned a lot is apropos which lets you search the man pages. The man pages are great for figuring out how a command works, but troublesome when you aren't sure what command(s) will do what you want to do. Keep in mind when moving to Linux that you will want to read the man pages thoroughly and often.

Beyond that, another laundry list of commands isn't going to help a lot (there are already some useful suggestions in this area); but I can say that it's important to get used to piping and redirection. If possible pick up books on shell scripting and perl - it's no joke that they are the glue and duct tape that hold pretty much every *nix system together. Learn to use vi effectively, since it's the standard on linux systems for editing configuration files. Finally, if you're not already, get comfortable with regular expressions and globs, since they are used a lot in the linux world.

Answer 22

A command I use quite frequently that I don't see any reference to is

$ top

It serves as a terminal/console equivalent to Windows Task Manager, letting you see the state of the system in terms of workload, and resource availability; listing what tasks are running and how much impact they are having.

Answer 23

Oh, there was a fun thing on old Linux distributions:

rm -rf *

I just wanted to delete all files inside the current folder. But I managed to delete the whole disk. This is because "*" included "." and ".." too. This was changed in newer Linux releases. But be careful on old distributions. ;)

Answer 24

Now that you are on a stable OS. I recommend that you still boot your new machine at least once a month or so. I know with the old Windows machine, you probably rebooted weekly, but don't do what a friend did on an hp-ux machine and run 2 years without rebooting. It really does speed things up if you reboot once a month or so even if everything is running well. :)

Answer 25

There are many answers here, but none of them include the incredibly useful tool that I simply cannot live without:

strace

I cannot count the number of times that I have run a program, it has crashed for an obscure reason, or given an obscure error message, and I have been able to ascertain the problem immediately and resolve it.

Here is a concrete example, I was called in to discover why after an upgrade, php started ignoring its configuration on the webserver. No matter what settings they put in the config file, they weren't being observed, and the website was down.

So I ran 'php', saw no errors, ascertained that it was looking at the correct config file using 'phpinfo()', so I decided, "lets see what it's actually doing".

$ strace -e open php 2>&1 | grep php.ini
open("/usr/bin/php.ini", O_RDONLY)      = -1 ENOENT (No such file or directory)
open("/etc/php.ini", O_RDONLY)          = -1 EACCES (Permission denied)

doing a quick ls -la solves the mystery:

$ ls -la /etc/php.ini
-rw------- 1 root root 44990 2008-05-09 00:26 /etc/php.ini

php.ini wasn't readable to the user running the webserver. Somehow its permissions had been altered in the upgrade.

I would never have found that out without using strace.

Answer 26

• Vim - If you haven't already, you should definitely run through the vimtutor tutorial. It will help you really use all of the power that Vim provides. You can get usually access it just by typing 'vimutor' at the command line.

• ack - ack is replacement(sort of) for grep written in Perl, providing a ton of features specifically for programmers. It is amazing and much easier to use than grep. It should come with every copy of Linux, but sadly it doesn't. As a bonus, it works on Windows too!

• git - the greatest version control system ever, imho. Even if you are working by yourself, the simple repository setup and branching/merging make git a great choice for version control. If you are unfamiliar with git, the kernel.org tutorial is a decent place to start.

• !! - Repeats the previous command. For example, if you wanted to delete some file that required sudo'ing to delete, but forget to type the sudo, you could do the following:

  > rm somefile # won't do anything since it needs root privileges to delete
  > sudo !!     # the same as typing 'sudo rm somefile'
  

Answer 27

Before you start to migrate to Linux read this: Linux is not Windows.

Answer 28

A lot of the posts here are really great. Here are my favorites whenver I am asked this:

• Get a book on bash scripting. In there it will walk you through most of the basics of the command line as well as give you a feel for what you will need moving forward.

• Read through a book like 'Linux in a nutshell' which is just a listing of all the commands and how they are used.

• Go on IRC and joining #linuxhelp channel to ask questions.

• If you have no real attachment to windows: switch to linux. Don't just 'dual boot'- take your windows or other machine and put it in a corner and use linux only for a period of at least 6 months. When doing this don't look for the gui tools first.

Answer 29

I have found these mapping tables between Windows Shell (DOS) and Unix/Bash commands to be very useful:

UNIX For DOS Users

Answer 30

In a pathname, the separators go like this "/" and not like this "\". Also, spaces and/or capitalization sucks in a pathname.

Answer 31

Bash is the default shell under linux and its job control features are nice. Bash supports fg (foreground), bg (background) and the classic '&' (run in the background). Use the jobs command to see the currently running process in the shell.

Check out the bash man page for more info. I believe there is a job control section that discusses these commands.

Keep in mind that most of the core bash commands (and much, much more) are available on windows via cygwin. You can play around with all this command-line stuff without leaving the comfort of your windows environment if you choose. Once you become versed in the fundamental unix shell tools, you will find that cygwin allows you to transfer these skills to windows systems.

Answer 32

In Windows, when you run a program by typing just the program name (without the path), Windows will search the current working directory, and then the PATH.

In Linux, programs must be in your path for you to execute them without specifying the path (absolute or relative).

So if you want to run a program that's in the current directory, you have a couple of options (assuming the program name is program):

1. Run ./program.
2. Add "." to the PATH, then run program

This was got me the first few days/weeks I started using Linux.

Answer 33

Stop refreshing !

Answer 34

The Window Key on your keyboard is not gonna work.