Getting started with command-line Unix/Linux/BSD, a very rough guide thread:
First off, you can look things up in the built-in manual. It's called "man", short for manual. Tell it which program you'd like to know more about, e.g. "man ls".
Getting started with command-line Unix/Linux/BSD, a very rough guide thread:
First off, you can look things up in the built-in manual. It's called "man", short for manual. Tell it which program you'd like to know more about, e.g. "man ls".
Moving around:
Print which directory you're currently working in with "pwd" (print working directory).
List the files and subdirectories within it with "ls" (list).
Move around with "cd" (change directory). Move inside a subdirectory with "cd [name]", where [name] is the name of that subdirectory. Move back outside of the directory you're in with "cd ..".
Make a new directory with "mkdir" (make directory). Remove an empty one with "rmdir" (remove directory).
Make a new blank file with "touch". Delete a file with "rm" (remove).
Be very careful with "rm"! Unix is like a genie. It *will* grant you an ill-advised wish.
Newcomers are tempted to view a file with "cat", but that's not really what it's for. "more" will show you the contents of a plain text file one screen at a time. There's also an improved version, playfully called "less".
You can view just the first few lines of a text file using "head", or the last few lines with "tail".
Where it really starts to get useful is with pipes. Kind of like plumbing. In Unix, almost everything is meant to be plain text, and can be passed along from files to programs, to other programs, to other files, in a pipeline.
For example, "echo 'one' > test" will make a new file called test, with the word "one" in it on a line by itself, as "less test" will attest. ">" means "send the output of that last program to a file with this name".
Similarly, ">>" will append the output to the end of a file. "echo 'two' >> test" and "echo 'three' >> test" will add the expected lines to the file.
In the other direction, "<" will send a file to the input of the program before it. So "less < test" will send the contents of the test file to the less program *via the pipe*.
So "less < test" will show us the contents of the file:
one
two
three
This is where it starts to get useful. You can alphabetise the lines of a text file using "sort". In this case, "sort < test".
one
three
two
(As "h" comes before "w".)
Note that sort hasn't changed the file, as its output by default is sent to the virtual terminal. We can output the alphabetised version of the file in a different file like this: "sort < test > test-alphabetised". That way, the original file is preserved, and the new version safely saved separately.
As an example of how you can chain along these simple tools, "uniq" (unique) removes duplicate lines, if they're one right after the other. This is especially useful after alphabetising them (as with, say, lists). You can do this with e.g. "sort < messy-file | uniq > clean-file"
the original messy-file:
one
three
two
three
becomes the new clean-file:
one
three
two
Unix is by and for writers. Chiefly programmers, as programming is a subset of writing. But it works on English just as well as it does C.
Want to know the word count of a file? "wc" (word count) tells you how many lines, words, and characters are in it.
Again, these are simple tools you can combine in complex ways. For example: "ls -1" lists all the files in the working directory, one per line. "wc -l" counts lines. So "ls -1 | wc -l" tells you how many files are in the working directory.
Perhaps this is why I find modular synthesisers so intuitive: it's the same principle. Lots of simple tools, each doing only one simple job, but doing it well... that you can connect together, into more complex combinations. This is known as the Unix philosophy.
There are lots of other useful Unix tools, but that's enough to get started on the command line. Remember, you can ask "man" for information about all of them.