PAGE DATE 1990428

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 >
Uh, you got this if you do

    
e2fsck /
   
but not if you do e2fsck /dev/sda1.

IS IT A SCRIPT?

/bin/blerf: toeuix: command not found
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.

/bin/blerf: /8515: Permission denied
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.

SNAGGY FILENAME?

You're in some directory of C sourcecode files, and you do.....
$ 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.

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....
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 .

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,


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.

RIGHTS

This page is Copyright 1999 Richard Allen Hohensee. It is released for redistribution only as part of an intact cLIeNUX Core.