"Pipe" to another process often fails

thepopethepope
Posted:
in Genius Bar edited January 2014
I have experienced a lot of times that the following type of command fails:



grep X file | more



...where it complains about not knowing the "more" command. If I write it again, it often works. Without the "|" character things work fine, so it seems that the next command sometimes does not inherit the path settings or something like that.



Anyone see this?

Comments

  • Reply 1 of 5
    pyr3pyr3 Posts: 946member
    Quote:

    Originally posted by thepope

    I have experienced a lot of times that the following type of command fails:



    grep X file | more



    ...where it complains about not knowing the "more" command. If I write it again, it often works. Without the "|" character things work fine, so it seems that the next command sometimes does not inherit the path settings or something like that.



    Anyone see this?



    You could try:



    grep <something> file|more



    without the spaces. That should work. It sounds more like there is a problem finding the 'more' command than something being wrong with the pipe command. Maybe you are mistyping something the first time through?
  • Reply 2 of 5
    thuh freakthuh freak Posts: 2,664member
    the spaces aren't supposed to be required. you could try the full path for more and see if it borks on that too (full path for more is /usr/bin/more). if you get the prob again, throw us the exact error messgae and maybe we can track this sucker down. also, when you say that you write it again, do you actually type it out, or just go back through the history (up/dn arrows)?
  • Reply 3 of 5
    dobbydobby Posts: 797member
    Are you using tcsh?

    do an echo $PATH.

    You should have /bin:/sbin:/usr/bin:/usr/sbin.



    Are you doing a sudo grep X file |more?



    This could cause the pipe to fail as the permissions are valid on the first command but not the second (more is a bad example I know).



    Dobby.
  • Reply 4 of 5
    thepopethepope Posts: 8member
    I found the problem.



    Basically - option 7 is the pipe character on my keyboard, but if I accidentally press space while option is still pressed, it prints a space character, but it actually prints a character that displays as a space on my machine.



    Try it for yourselves:



    cat(space)file(option-7)(option-space)more



    In my case:



    bash-2.05a$ cat /etc/motd| more

    bash: more: command not found



    Pasting the command into some text areas with a different font actually shows that the underscore character is inserted, but on my system it is a space. What the h*ll is the underscore character doing on option-space anyway?
  • Reply 5 of 5
    pyr3pyr3 Posts: 946member
    Quote:

    Originally posted by thepope

    I found the problem.



    Basically - option 7 is the pipe character on my keyboard, but if I accidentally press space while option is still pressed, it prints a space character, but it actually prints a character that displays as a space on my machine.



    Try it for yourselves:



    cat(space)file(option-7)(option-space)more



    In my case:



    bash-2.05a$ cat /etc/motd| more

    bash: more: command not found



    Pasting the command into some text areas with a different font actually shows that the underscore character is inserted, but on my system it is a space. What the h*ll is the underscore character doing on option-space anyway?



    It's probably not the underscore character. It's probably an ASCII character that is a non-displayable character and some fonts display and underscore when they choke and other display a space. Could also be the app that you are using too that is making the underscore.
Sign In or Register to comment.