bash: command not found after piping

I am having exactly the same issue, although in my case the typing speed does not seem to matter, I mean it is another factor, sometimes it works, sometimes it doesn't!

For instance:

MacBook-Pro-de-Manuel:~ alexman$ env | grep food

-bash: grep: command not found

MacBook-Pro-de-Manuel:~ alexman$ env | grep -i food

FOOD2FORK_KEY=c6367265ef527c79e579e75f76485d69

The 2 commands were typed with 20 mins of difference and on the same terminal, is my laptop getting aware of its existance?

Note:

My setup is a macbook pro 15" mid 2012 with Sierra and iterm2.

Check your syntax:

ps -ax | grep -i bash

You're missing a dash.

The dash is optional. That's not the problem.

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.

Back up all data, then reinstall the OS.

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.

...re-installing the whole OS (which, frankly speaking, is unfortunately out of the question).

Why is it out of the question? It's easy to do.

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

You're not supposed to know that, because it makes no sense. You have a damaged system. Continuing to use it in that state is, frankly, ridiculous. But apparently you consider the problem to be solved, so I'll unsubscribe from this thread now.

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