DESCRIPTION
This page is an attempt to de-mystify some of the more baffling error
messages a cLIeNUX user may encounter with user commands.
NON-MESSAGE ERRORS Probably worse than cryptic error messages are the things that don't do what you want and don't say much of anything. If you attempt to do a command and the cursor just drops to the next line and waits for more input, you probably gave an incomplete command. This is what will happen with grep with only one argument, for example. Hit ctrl&d and try again.
If you get a > on the line after what you thought was a valid command, it was valid, but it was the beginning of a compound command like a for loop, and you're looking at PS2, the second level command prompt. Often however, it is in effect an error message. Hit ctrl&d and try again.
no rule to make target blah
command not found
cannot open initial console
31 unallocated sectors
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 < device >
IS IT A SCRIPT?
/bin/blerf: toeuix: command not found
/bin/blerf: /8515: Permission denied
SNAGGY FILENAME?
You're in some directory of C sourcecode files, and you do.....
HASHED?
Your in a shell. You do a command, ls for example. Then you move ls from
/bin to some other directory in your path. Try ls again in that shell and
you'll get....
OVERLOADING THE "WHITESPACE" OPERATOR
unix has a very bad habit of supporting multiple meanings for things you
can't see. In the "make" utility for example, a tab is an operator. The
equivalent number of blanks is not. This will cause you bewildering
missing separator error messages if you edit a makefile and
aren't vewwy vewwy careful about the exact nature of blank space in the
text. (I'm not real fond of make.)
The shell itself suffers from this also. "blah " is not the
same as "blah" . This will bite you with the delimiters for
<< "here document" redirection, and when using \ to
continue a logical line across more than one physical line. For example,
RIGHTS
This page is Copyright 1999 Richard Allen Hohensee. It is released for
redistribution only as part of an intact cLIeNUX Core.
Uh, you got this if you do
e2fsck /
but not if you do
e2fsck /dev/sda1.
I generated that one by writing a script file /bin/blerf, and putting a
line in it that's not a command, namely toeuix. The point is, if you don't
know that the command (blerf in this case) is a script, and you don't
realize that the error message is showing a sub-command also, the "command
not found" will drive you nuts, since you can see that blerf does exist
and has executable perms. The line that fails in a broken script can be
even more obscure than toeuix too, and thus less likely to remind you that
you called a script.
Here's another good variation on the treacherous broken script theme. I
changed toueix to /* wrong */ in /bin/blerf and got the above
message. Bash sees the /* in a valid C comment as "do the first file in
/", which happens to be a junk file called 8515 on my box at the
moment, and which, mercifully, isn't an executable. At first glance
though, it looks like it's not letting you execute blerf. It is.
$ ls *.c
and you get......
ls: invalid option `--'
Try `ls --help' for more information.
Bizarre, eh? Well, that's what you may get if there's a file named "-1.c"
in the directory. Bash apparently expands the glob pattern "*.c", and THEN
interprets the syntax of the resulting line. Since -1.c is likely to be
the first file in the directory, ls *.c will expand to
ls -1.c (other filenames)
and the -1.c goes from being a filename to looking like a bogus command
switch. Filenames starting with - are even hard to mv. In this case
mv ./-1.c minusOne.c
should unsnag things. The ./ blocks the - from looking like a
switch. Quotes won't.
bash: /bin/ls: No such file or directory
This one doesn't happen so often, but if you move commands around it can
cost you your sanity. Bash keeps a hash table of commands it has run. If
it has a command in the table, but it's no longer where the table says it
is, it won't look any more. Not even if the command is still in your PATH.
The fix is to invoke the Bash "hash" builtin mith the -r switch, e.g.
hash -r .
cat > concatenationFileOfAllTheseOthers file1 file2 file3 \
file4 file5
will cat file1 file2 and file3 to concatenationFileOfAllTheseOthers
and then try to execute file4 as a command with file5 as it's argument if
there's any whitespace other than a newline after \ . In other
words, \ isn't the line continuation operator,
\{newline}
is, but the difference between
\{newline}
and
\{spaces}{newline}
isn't visible.