I've removed advertising from most of this site and will eventually clean up the few pages where it remains.
While not terribly expensive to maintain, this does cost me something. If I don't get enough donations to cover that expense, I will be shutting the site down in early 2020.
If you found something useful today, please consider a small donation.
Unix and Linux are different.
If your first exposure to computers was DOS or Windows, some of what you learned there is going to trip you up in the Unix world. This article attempts to both explain how Unix is different, and also why it is different, because if you understand why, you'll find it easier to remember.
Some other links :
Way back in the beginning, just after the dinosaurs all died, Microsoft DOS didn't have sub-directories. You could put files on a disk (usually a floppy- hard drives were very expensive then), but you couldn't make directories to organize your files.
Unix, which had been around a decade or so longer, did have subdirectories, and then, as now, a path through multiple directories would be indicated by a "/". That's a "forward slash", or just "slash", by the way- if you are coming from DOS, you might think that "\" is a slash and that "/" is a back-slash, but you'd be wrong. Remember that we (Unix folk) were here long before Microsoft- so when you see that some Unix thing is vastly different than the way Windows does it, understand that it's not because we didn't pay attention to Microsoft: Microsoft didn't exist. It is Microsoft that didn't pay attention to Unix.
Anyway, since DOS didn't have directories, it didn't need either slashes or back-slashes for that, so they decided to use "/" for something else: command line arguments, like "DIR /P", which would indicate you wanted to pause your directory listing to keep it from scrolling off the screen.
Why? Because that was the way CP/M did it, and CP/M was the most popular little computer OS, and it didn't have hierarchical directories either. Unix almost always uses "-" for options, and the designers of both CP/M and DOS certainly knew that. Maybe they wanted to be different, or maybe they felt the "/" was easier to reach on the keyboard, or more obvious. Whatever the reason, that's what they decided.
But very soon, sub-directories were added to DOS, and this made a problem. They couldn't use "/" to separate directories, because that was used for command flags. So they used "\", instead.
Even they knew that this was a problem. Because they knew that people used to Unix would find that confusing (and back then, there were a lot more of those people than people used to DOS!), they added a new command "SWITCHAR" (or was it SWITCHCHAR?) that would swap these characters internally so you could type "/" between directories and "\" for flags. It never caught on, and got dropped after a few years.
So, you need to use "/" in Unix. The "\" character isn't used for flags in Unix, but it does have a purpose, and that purpose will trip you up when you forget. For example, if you type:
what your Unix shell actually sees is:
which is not what you meant. So what's the "\" for? It's for "escaping" characters; hiding them from normal interpretation. For example, single quotes are usually found in pairs, and have special meaning. So if I want to use one without that meaning, I need to escape it:
Of course, if you are a web user, you are already used to typing "/" in URL's. Microsoft ignored the Web forever, and by the time they got there, the Unix traditions were too firmly in place.
Windows and DOS people are used to using floppy drives as file systems. Unix folk are more apt to use floppies like you'd use a tape. Because of that basic culture clash, you need to understand some differences:format
When you use "format" in Windows or DOS, you actually get much more than a format: you also get a file system. That's why you can copy files to A:, that's why it looks just like your C: drive, only smaller.
When you format in Unix, you don't get a file system. Of course you can get one if you want it, but that's a separate command: mkfs (or, for a more friendly front-end [SCO]: mkdev fd).
So when you stick a floppy into a Unix box, you can't just copy files to it or from it as you would in DOS. If you did want to use it that way, you'd need to make a filesystem on it, and then mount that filesystem into your hierarchy (see Where's my D:?).
A floppy filesystem does allow you to transfer files from one place to another by way of a shirt pocket. However, a file system has a fair amount of overhead (which means that it will hold less data) and absolutely cannot carry files bigger than 1 floppy in size.
A better way to get files into your pockets is to use an archiver like "tar" or "cpio". First, there is less overhead, and (probably more importantly) you can split large files across multiple floppies, or just put lots of files out there without worrying about when you will run out of space- because tar and cpio will tell you when they need another floppy.
Some old versions of tar don't understand splitting files across multiple volumes. Newer versions do, and some of the newest also offer the ability to compress while creating the archive. There are third party tar compatible programs, too: see The Supertars
I'm going to assume that your floppy is a 3.5 inch 1.44 MB and that it is unit 0. If that's true, you could put everything in /usr/dfw onto floppies with:
cd /usr/dfw tar cvf /dev/fd0 .
Or, if you wanted just certain files, you might do something like:
tar cvf /dev/fd0 document*
If all of your files won't fit on one floppy, tar will ask you for another, and so on. Note there is no mounting or unmounting, and that you didn't need to make a filesystem on the floppy, though you probably should format new floppies.
To examine what you put on, do:
tar tvf /dev/fd0
After taking these floppies somewhere else, lets say you wanted to restore them to /usr/dfw2. You'd just:
cd /usr/dfw2 tar xvf /dev/fd0
If you wanted one specific file, you might say:
tar xvf /dev/fd0 document1
Isn't that easier than mounting and unmounting filesystems?
To find out more about tar and other archivers, do:
man tar man cpio
Another silly thing MSDOS did was to make drives use letters. They regret it now, but it's going to be a long time before they can straighten that mess out completely.
Unix doesn't do that. In Unix, you mount a filesystem (a drive needs to have a filesystem to be useful) at some directory on your booted or "root" drive (or any other already mounted filesystem). To get to the stuff on the second drive, you just "cd" there, which is a much smarter way to do it, because it's all transparent: if your application lives under /usr/lib/whatsthis, it doesn't matter if "whatsthis" is a directory on your first drive, your second, or your 25th: it's just /usr/lib/whatsthis.
Actually, for a long, long time MSDOS has had a way to "mount" drives, but they called it "JOIN". For example, you could "JOIN D: C:\NEWDRIVE", and then if you "CD \NEWDRIVE" you'd be sitting on D:. Hardly anybody ever used this, but it has been there just the same (there's a Unix "join" also, but that's a database like command that merges files based on a common key- see "man join").
You also mount cdrom drives, you can mount floppies (though you usually don't - see: Where's my A:?).
You can mount DOS floppies, though you might have to do something to allow that capability- for example on SCO OSR5 you need to run "mkdev dos"- see: I need some files from DOS!
If you are looking for some more information on this, try
DOS folk are used to "CD\DOS", and often get annoyed and frustrated by the seemingly dumb requirement that Unix imposes where you must
It's hard enough to get used to the "/" (see: Slashes: forward or back?) but that stupid extra space drives people crazy.
There is a good reason for it. To understand it, tell me what this is:
Is that a command called "DOTHIS" that takes the arguments "\DOTHAT"?
Is that a command called "DOTHIS" that takes the arguments "\DOTHAT" and "\AGAIN"?
Could it be a command called "DOTHIS" that takes ONE argument "\DOTHAT\AGAIN"?
Or maybe it's actually the command "AGAIN" that is under "DOTHIS\DOTHAT" in the current directory?
That's why Unix shells insist on spaces.
Spaces in file names is another thing altogether. Both Windows and modern versions of Unix allow you to have moronic filenames with imbedded spaces. Neither of them should allow that, but the brainless hordes won out and they do. If you are going to use that, or if you are stuck with what some idiot gave you, you are going to have to carefully quote such names in Unix (same as you would at the DOS command line).
So, if you want to copy the dumbly named MY FILE, to somewhere else, you'll need to:
cp "MY FILE" here
It's called "man". If you want to know about "rmdir", you'd type
But how would you find out that there even was something called "rmdir" in the first place? DOS has a very small number of commands, but Unix has hundreds and hundreds!
The "apropos" command can help. You might type:
(note: "apropos" is pretty literal, so you'd probably also want to try "apropos directories" and "apropos files". Also, "apropos" gives you a lot of output, so you might want to pipe it: "apropos files | more").
There's also a neat lifebuoy icon on your GUI desktop if you are running SCO (other Unices have similar things). Clicking that will get you all kinds of help.
In adition to man pages, Linux systems have "HOWTO's", many of which are available on the web, but are also often installed on your system. Linux systems also may have the "info" command, which is the GNU hypertext documentation project.
The nasty little names ("ls", "awk") are that way because Unix people hate to type. You can't blame them if you know that when Unix first came out, the "terminals" were teletype machines. You may never have seen one of these, and it's hard to find one nowadays, but these were big, ugly keyboards with giant keys that (slightly exaggerated) you had to mash with your fist to use. They were slow, clumsy, and awful, so the shorter the command, the better.
That's all behind us, of course, but people get used to using certain names, so that's the way it is. You'll get used to it.
If you really can't get used to it, you can make your own commands, either with links or with shell scripts. For example, say you'd rather type "dir" than "ls". You could use:
ln /bin/ls /bin/dir
(that assumes you are root and have permission to write in /bin). That works, sort of. Actually, you might notice on some systems that it's a little different than "ls", and the reason why has to do with the fact that "ls" may already a link: l, lc, lr, lx, and lf are all actually just links to the same program on SCO, for instance, and that program acts differently depending on what the last letter of its name is. So your new "dir" acts like "lr" rather than "ls".
Linking, by the way, is like Windows shortcuts. Sort of. Actually Unix has two kinds of links, hard and soft, and soft is much more like Windows shortcuts than the hard link shown above, but you can still think of it like a shortcut.
Another way to do it is to create a simple script:
echo 'lc $*' > /bin/dir chmod 755 /bin/dir
That will make "dir" work like "lc" does. With many modern shells, you can do the same thing with aliases or shell functions. For example, here's dir as an alias (this would work in bash or ksh and many other shells):
alias dir='ls -l'
(Linux distros already have a "dir"- smart people.)
Always remember to read the man pages. For example, you might find that Unix "sort" works very much like Dos sort. However, it is actually much more powerful, and you'll never know that if you didn't do "man sort". That's true for everything else, too.
An excellent book for learning Unix commands is Unix for the Impatient.
Because it's more powerful. Because it's easier. Because it's faster. Because one picture is sometimes a heck of a lot more confusing than a couple of well chosen words. If that weren't true, we'd still be drawing pictures rather than typing, right? How would I have done this page as a picture?
There are things that are better done in a GUI, and you get that with Unix. But Unix gives you very powerful command line capabilities, too. Microsoft is just starting to realize that they need that; expect to see more of it in future versions of Windows.
Once you start to realize what kind of power and speed the command line gives you, you won't want to be without it. It's lack of this that probably causes the most dislike of Windows and Macintosh by Unix folk. It's not that we hate GUI's, it's that we want (and need) BOTH.
By the way, if you are a SCO user, you might like "scosh". Just type that at the command line prompt, and you get a nice little character mode shell that has a simple little editor, simple file management, and a useful calendar. Try it.
It's not just having a command line that makes Unix special. Dos (and Windows, since it can run a Dos shell) have a command line. The problem is that the Dos shell is pathetic, nearly useless, and although Dos provides pipes, the implementation and performance is terrible, and most of the commands weren't written to be used that way at all. That's not the case with Unix: most Unix commands are written with the idea that someone may want to use them in a pipeline (that is, either driving their input from some other program or passing their output to the input of something else). Unix command line shells also have more ability to control their input and output, and even the worst shells (csh, for example) have programming capabilities far beyond anything you get in Dos or Windows (although Windows Scripting Host is getting pretty darn good).
Another obvious difference between Unix and Windows is that most Unix programs use plain ASCII text control files.
Though I will say that in recent years there has been more of a trend to the type of proprietary binary crap that pervades the Windows world, probably due to younger programmers who should know better but don't.
Ascii text files are easy to manipulate by hand or within the context of another program. They aren't easily "corrupted", and if they are damaged, they are easy to fix.
STOP SHOUTING AT ME!!
Upper case doesn't work because it shouldn't. MSDOS never should have allowed this; it's wasteful and foolish. There is no excuse for that, just as there is no excuse for dumb programs that force you to put CAPS LOCK on or their menus won't work!
Actually, Unix does have a way of supporting that, and you might have run across it if you ever accidentally left your CAPS LOCK on and managed to log in. I say "managed to" because you'd get a warning before it would let you in, but if you just ignored that, you would get logged in, and you would be able to type commands in upper case. It's a little weird though, because EVERYTHING is in upper case, and things that should be upper case get a "\" in front of every upper case \L\E\T\T\E\R. That mode was designed for very old, upper-case only terminals, and really isn't useful today; in fact it will cause many programs to act strangely or not to work at all.
If that's something you do accidentally and it screws up your application, you can add these lines to the end of /etc/profile:
stty -iuclc -xcase -olcuc
Those lines will reset you to "normal" if you logged in with upper case.
First, all Unices have "doscp" or something like it. On SCO OSR5, you could
doscp a:*.* .
On many other systems, including Linux, you'd use the "mtools": mcopy, mdir, etc.
You cam also generally "mount" dos disks (see: Where's my D:?) With SCO OSR5, you'd need to "mkdev dos" first, but after that, you could:
mkdir /floppy mount /dev/fd0 /floppy cd /floppy ls
and expect to see your files (the same commands would also work on Linux).
Also see Data Transfer.
Because it does work, just not as you and Microsoft think it should.
Because it was a dumb idea in DOS and it would be an even dumber idea in Unix. First of all, Unix files very often DON'T have extensions, so that's why it doesn't work as the wonderful folks at Microsoft had it work- it's doing just what you asked it to: showing you files that specifically have a "." in their name. Secondly, Unix wildcards are a hundred times more powerful and useful. For example, this will show you all the files that begin with "g" or "t" and end with "ant":
Try that with Dos or Windows. How about anything from "a" to "h"?
Or everything with "art" anywhere in the name?
You can see it right there in your directory, but it keeps saying "Not found" when you try to run it. If you are "root", it's because root does not, by default and by design, have "." (the current directory) in its PATH, and unlike DOS, Unix shells don't assume that the current directory should be searched. Actually, ordinary users get "." in their PATH, but "root" does not, and the reason is security- to keep you from accidentally executing the wrong program. Type "./program" to get around this, or if you want to live dangerously, modify root's .profile and add ":." to the end of the PATH.
If it does the same thing when you do "./program", it's because the very first line of the script tells it to use some other program: for example, the script might have "#!/usr/bin/perl5" as its first line- if you don't have /usr/bin/perl5, you'll get that "not found" error (look at the line carefully- you might have /usr/local/bin/perl5 or /usr/bin/perl, for example, but close doesn't count here!).
If the error is "cannot execute", try "chmod +x program". Unix programs have to be marked as "executable". DOS does that by the program's extension (.BAT, .EXE, .COM), which is, as usual, dumb. All together now: DOS IS DUMB. Thanks.
It's also possible that your problem is related to LD_LIBRARY_PATH - This won't be the case for a script you make, but it could be for someone else's program. What that controls is where to search for shared libraries. Unix/Linux systems always have standard places to search, but sometimes need some help. See Why do I get "dynamic linker" errors or load failures? in the FAQ here.
First, understand that Unix doesn't need ".bat" or any other extension. You can call it myfile.bat if that makes you warm and fuzzy, but you don't need to. Unix will execute a file if its permissions include the "execute" bit. So, to create a script file that contains commands you want to run:
cat > myscript (type your commands) (as many lines as you want) (end with CTRL-D on a line by itself)
chmod 755 myscript
If the script is placed in a directory included in your PATH (see Why can't I run this program? above), typing "myscript" will now run those commands.
See also Basic Scripting.
Just add an & after the command:
Who says there isn't? Some Unix systems (SCO, for example) have the ability to turn on "versioning" in the filesystem. However, it's also true that this option is seldom turned on, and it does no good to turn it on after you've accidentally removed a file. Try "man undelete" or "apropos undelete" to see if your Unix offers anything like this.
Many Unixes set the "rm" command to prompt you before removing files; those of us accustomed to Unix don't appreciate such helpfulness and will turn that off if we can (it's often done with an alias to "rm -i").
Desktop users may have a trash bin that works like the Windows
trash bucket, but in general, when you remove a file in Unix, it's
gone. Therefore, you should have backups of your files, make copies
of important files before you start removing other files, and
generally use your head.
If you found something useful today, please consider a small donation.
Got something to add? Send me email.
More Articles by Tony Lawrence © 2011-05-07 Tony Lawrence