On Tue, 2005-11-01 at 03:13 +0200, Amit Aronovitch wrote: > The problem with this issue, is that there is a wide range of possible > causes to this problem, spanning a large 'diagnosis tree'. This makes it > hard to diagnose by iterative mail questions. > I'll try to ask enough questions to cover the "more reasonable?" causes. > > Aaron wrote: > > >>>"cd" command not found?? "cd" is an internal shell command (doesn't make > >>>sense to run it in a separate process). Are you sure that's what happened? > >>> > >>> > >>> > >>> > >seperate process? > > > > > I think what Amos means is that for cd it's a different matter than e.g. > for ls. > When you type ls, bash searches for the command on your path, and if > found runs it in a subprocess. If your path, or the disk containing the > executable (normally /bin/ls) is broken, you get the message you got below. > However since cd is an "internal command", bash should run it directly > (there is no 'cd' executable, it's the bash executable that does the > job), so we'd be very surprised if you see similiar message for the 'cd' > command too. Were you just giving an example or did you actually see a > '-bash: cd: command not found'? I can hardly imagine how this could > happen - unless the bash executable itself is broken. > > >>What's the exact error message? It should be something like > >>-bash: <exact commandname>: command not found > >> > >> > >> > >-bash: ls:command not found > > > > > > > OK, so we know it's bash, and we know it knows you typed ls (unless > there are some mysterious unprintables hidden over there), rules out a > few exotic possibilities. > What about if you try explicit path: /bin/ls ? Can you access /bin at > all? I would have said try ls'ing it, but since you don't have ls... > what happens if you type /bi<tab>? does it complete? if yes, try another > tab to see what's there... > > If there is a working /bin/ls, then it's your PATH. Were the "echo > $PATH" results you mentioned before done from a "working" terminal? If > yes, try from a non-working one (echo, like cd, is an internal command - > if it does not work, either you have a bad alias or your bash executable > is bad). > > If you see no /bin or no /bin/ls, indeed the most probable cause would > be a bad disk/ bad file-system. When this happens, try switching to > another (working) shell, and see if you can access /bin/ls from there. > If you can run /bin/df, try "/bin/df /" and "/bin/df /bin". > It might also be related to user permissions (maybe these shells are > opened under some special user, that does not have read or exec perms to > the file) - try running /usr/bin/id ... oops - this would probably not > be available too - so try locating this shell by carefully examining the > output of "ps -ef" from another terminal - note the user id. One more > general diagnosis tool - if you do locate the shell's process from > another terminal, you can use 'strace -p <process number>', then go back > to the bad term and type "/bin/ls -ld /bin/ls" to see the syscalls bash > does when looking for ls. > Yet another possibility, is that for some reason the shell or the > terminal is run chroot(8)'ed to some other place - I guess this one is > too far fetched for now > > >was from ctrl alt F2 > > > >but the same thing on term windows > > > >I us konsole if it matters > > > > > > > This would have helped to further diagnose had you given a different > answer to my other question (the exact error message). As it stands it > probably does not matter. > > >It happens randomly and often after time when I open a new term. > >Aaron > > > > > "after time" - does that mean that it works ok for a while, then the > same shell stops recognizing commands?
yes it means it was working and pitom all of a sudden it stopped. > Or do you simply mean that you > open a new shell after some time, and the *new* shell is the one that > does not work? Or - is it that they both stop working, but this does not > happen unless you open a new terminal. > > One more useful technique you can try, especially if you suspect PATH is > being corruped, is adding debug printings in initialization scripts - > e.g. /etc/profile /etc/bash.bashrc, ~/.bash_profile and ~/.bashrc > (sometimes it's the initializations scripts that fail, corrupting your > PATH on the way). But do make sure you remember to remove them once > your'e done experimenting... Thanks for the suggestions I will use all the above the next time it happens Aaron > > > ================================================================= > To unsubscribe, send mail to [EMAIL PROTECTED] with > the word "unsubscribe" in the message body, e.g., run the command > echo unsubscribe | mail [EMAIL PROTECTED] > ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
