I would ask, if all the situations where you get
bash: grep: command not found
if they are situations where you are not running from your terminal? For example, from a cron job, a launchd job, an automator/applescript, GeekTool, etc...
As it sounds like a situation were your PATH does not include /usr/bin, and while generally speaking /usr/bin is part of PATH most of the time, it is always possible the environment you are using it in, does not have a PATH with /usr/bin.
The only other possibility is that for some reason you keep loosing access to /usr/bin/grep. How I don't have a clue, and it would be very strange, unless for some reason maybe you were booted over the network, and did not have a local disk.
... I'm receiving--and now comes the most curious part--most of the times (not always!!) an error message
You mean, sometimes you enter the same command and get the error, and sometimes not, with nothing having changed in the meantime? There isn't any theory that could explain that, except maybe a corrupt OS installation.
Yep, that's right. I', opening a new terminal session, and most of the times I'm receiving the error, but occassionally it's working as intended, and as I've experienced it across many different Un*x systems.
The PATH environment variable includes /usr/bin (otherwise it wouldn't find the grep command from the shell if called without the fully qualified path).
I've tried to call the commands with the full leading path names, eg.
bash$ /bin/ps ax | /usr/bin/grep -i grep
bash: /usr/bin/grep: No such file or directory
Then to check
bash$ which grep
Another example would be "launchctl | more", same pattern: "bash: more: command not found", just to ensure that this is lock in on the ps/grep.
I'm with Linc on this, however, I would like to see if there is anything about your environment that is strange. But since I suspect your file system, I would stay if you are not doing backups now, you should be starting just in case.
Create a new account. Does this behavior occur in the new account?
If it does not happen for the new account, then there is something strange with your login environment that is not occurring in the new account. What in your environment could cause this, I do not have a clue, and that is based on 20 years working with Unix.
If the new account does the same thing, I would say proceed with Linc's suggestion, except I would be more concerned about the state of the file system, and would add erase the file system and start with a free newly initialized file system (no need to zero anything, just use the basic Disk Utility erase).
So backup the file system (Carbon Copy Cloner or SuperDuper would be excellent backup choices), erase your disk and put a new file system on it, reinstalled Mac OS X, restore your data.
Well, thanks guys, but somehow I've got the feeling that there might be another, easier, more covenient solution to this than re-installing the whole OS (which, frankly speaking, is unfortunately out of the question).
Doing all the command sequences within tclsh works perfectly fine, but then again I don't want to be stuck with tclsh.
sh and bash are generating the very some errors.
I've never ever encountered such a thing under SunOS/Solaris, Sinix, SCO Unix, FreeBSD, NetBSD, Linux, Xenix, Interactive Unix, DEC Unix, HP/UX, AIX.....really....hmm...strange.
Good, you tried a different shell. sh and bash are essentially the same executable on Mac OS X.
Did you try a new user account? What were those results?
Have you tried installing your own bash? Either build from sources, or use something like MacPorts.org to install one already configured for Mac OS X.
You also have ksh and zsh if they happen to rock your boat (see /etc/shells for a list of installed shells).
I think both Linc an dI agree that we have never seen this situation before either, which is why we suspect something has become corrupt. The "Nuke and Pave" approach tends to eliminate that possibility. But since you have lots of Unix experience (even though you missed a few Unix flavors ), and want to find the root cause, then you need to start doing tests that eliminate components.
The shells on my Mac OS X 10.7.2 Lion system have the following chksum's
cksum /bin/*sh 188949626 1371648 /bin/bash 1672788767 772992 /bin/csh 4164734636 2180736 /bin/ksh 1711289041 1371712 /bin/sh 1672788767 772992 /bin/tcsh 2366092939 1103984 /bin/zsh
I would expect yours to be identical. But that does not take into account any libraries used. And if you have the same values, then you need to look at something else (again, a new account can go a long way to eliminating things in your environment, or pointing to a system component).
Trying different shells is to no avail.
Funny thing though, I've got a shell script (#!/bin/sh ; ls -CFal $* | more) which works perfectly fine!
But hold on...when typing really slowly and waiting a few secs after typing the pipe it's working!!
Can this really be the case? That I'm typing too fast?
On my German keyboard the pipe is at "ALT"+"7"...
1) Not working: bash-3.2# ps ax | more (fast typing)
2) Working: bash-3.2# ps ax | more (slow typing, waiting after pipe before blank)
Running these two lines with "od" it becomes apparent
bash-3.2# echo "ps ax | more" | od -t a
0000000 p s sp a x sp | ? ? m o r e nl
bash-3.2# echo "ps ax | more" | od -t a
0000000 p s sp a x sp | sp m o r e nl
Well, well, how I'm supposed to know this??
Anyhow, one mystery solved!
Try another keyboard. Maybe the current keyboard is generating noise.
Also try a different USB slot (a Mac mini has 4 or 5 USB slots, depending on which model it is). Trying different slots will swtich to different USB controller chips. I'm not sure how many slots are controlled by a single chip, but I think there is more than one controller chip, so try them all).
Can you ssh into your Mac mini from another system. Does the problem continue. This would eliminate any local keyboard/USB hardware. If the problem continues, then that would indicate a software problem. If a software problem, we are back to possibility reinstalling software.
I suppose if things point to a software problem, you might look to see if you have any 3rd party software installed that might affect keyboard input. Maybe start in Single User Mode (boot holding Shift key held down), this should keep any 3rd party extensions from being loaded. Does the problem continue (but I'm still thinking keyboard problem).