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.
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
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
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
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
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
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:
tar cvf /dev/fd0 .
Or, if you wanted just certain files, you might do something
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:
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:
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
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
If you are looking for some more information on this, try
There is a good reason for it. To understand it, tell me what
Is that a command called "DOTHIS" that takes the arguments
Is that a command called "DOTHIS" that takes the arguments
"\DOTHAT" and "\AGAIN"?
Could it be a command called "DOTHIS" that takes ONE argument
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:
It's called "man". If you want to know about "rmdir", you'd
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
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.
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
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
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.
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
If that's something you do accidentally and it screws up your
application, you can add these lines to the end of
stty -iuclc -xcase -olcuc
Those lines will reset you to "normal" if you logged in with
Because it does work, just not as you and Microsoft think it
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
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:
Create the file. You can use the GUI Text Editor, vi (see
VI Primer) or even something
as simple as this:
cat > myscript
(type your commands)
(as many lines as you want)
(end with CTRL-D on a line by itself)
The file needs to be marked executable- if everyone should be
able to run it, do:
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.
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.