"Pipe" to another process often fails
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?
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
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?
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.
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?
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.