Previous 1 2 Next 28 Replies Latest reply: Feb 19, 2015 10:53 AM by mstg
MMHein Level 1 Level 1 (0 points)

Hi,

 

I'm trying something quite commonly found in an Unix environment, namely piping the output of one command into the input of a subsequent one, eg.

 

   bash$ ps ax | grep -i bash

 

But unfortunately I'm receiving--and now comes the most curious part--most of the times (not always!!) an error message

 

   bash: grep: command not found

 

When calling grep directly

 

   bash$ grep

 

the resulting output is

 

   Usage: grep [OPTION]... PATTERN [FILE]...

   Try `grep --help' for more information.

 

"which"-ing the commands

 

   bash$ which bash ps grep

 

results in

 

   /bin/bash

   /bin/ps

   /usr/bin/grep

 

 

Cheers,

MMHein


Mac mini, Mac OS X (10.7)
  • MrHoffman Level 6 Level 6 (12,980 points)

    Check your syntax:

     

    ps -ax | grep -i bash

     

    You're missing a dash.

  • Linc Davis Level 10 Level 10 (146,985 points)

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

  • BobHarris Level 6 Level 6 (14,670 points)

    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.

  • Linc Davis Level 10 Level 10 (146,985 points)

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

  • MMHein Level 1 Level 1 (0 points)

    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

     

    resulting in

     

      bash: /usr/bin/grep: No such file or directory

     

    Then to check

     

      bash$ which grep

       /usr/bin/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.

  • Linc Davis Level 10 Level 10 (146,985 points)

    Back up all data, then reinstall the OS.

  • BobHarris Level 6 Level 6 (14,670 points)

    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.

  • MMHein Level 1 Level 1 (0 points)

    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.

  • Linc Davis Level 10 Level 10 (146,985 points)

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

  • BobHarris Level 6 Level 6 (14,670 points)

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

  • MMHein Level 1 Level 1 (0 points)

    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

     

    ad 1)

    bash-3.2# echo "ps ax | more" | od -t a

    0000000    p   s  sp   a   x  sp   |   ?   ?   m   o   r   e  nl       

    0000016

     

    ad 2)

    bash-3.2# echo "ps ax | more" | od -t a

    0000000    p   s  sp   a   x  sp   |  sp   m   o   r   e  nl           

    0000015

     

    Well, well, how I'm supposed to know this??

     

    Anyhow, one mystery solved!

  • Linc Davis Level 10 Level 10 (146,985 points)

    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.

  • BobHarris Level 6 Level 6 (14,670 points)

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

  • MMHein Level 1 Level 1 (0 points)

    Well, swapping the keyboard did the trick.

     

    Funny though, that only on the shell, only when piping the issue occured.

     

    Thanks guys!

Previous 1 2 Next