«Команда не найдена» после канала - PullRequest
Новая
       19

«Команда не найдена» после канала

0 голосов
/ 26 мая 2019

Некоторые команды возвращают «Команда не найдена», если они вызываются после канала.

Я проверил, если / где они установлены, и в последних версиях, и если они находятся в $ PATH. Справочная информация: MacOS 10.14.5, утилиты gnu и другие команды, установленные через homebrew, вручную устанавливают $ PATHS и $ MANPATHS. 

$ echo -e ${PATH//:/\\n} | cut -d '/' -f 1
-bash:  cut: Command not found.
$ echo -e ${PATH//:/\\n} | grep '/usr/'
-bash:  grep: Command not found.

$ which cut
/usr/local/opt/coreutils/libexec/gnubin/cut
$ which grep
/usr/local/opt/grep/libexec/gnubin/grep

$ cut --version
cut (GNU coreutils) 8.31... 
$ grep --version
grep (GNU grep) 3.3...

$ bash --version
GNU bash, Version 5.0.7(1)-release (x86_64-apple-darwin18.5.0)...

$ echo -e ${PATH//:/\\n}
/usr/local/opt/openssl/bin
/usr/local/opt/coreutils/libexec/gnubin
/usr/local/opt/ed/libexec/gnubin
/usr/local/opt/findutils/libexec/gnubin
/usr/local/opt/gawk/libexec/gnubin
/usr/local/opt/gnu-indent/libexec/gnubin
/usr/local/opt/gnu-sed/libexec/gnubin
/usr/local/opt/gnu-tar/libexec/gnubin
/usr/local/opt/gnu-time/libexec/gnubin
/usr/local/opt/gnu-units/libexec/gnubin
/usr/local/opt/gnu-which/libexec/gnubin
/usr/local/opt/grep/libexec/gnubin
/usr/local/opt/inetutils/libexec/gnubin
/usr/local/opt/make/libexec/gnubin
/Users/xxxx/.jenv/shims
/Users/xxxx/.jenv/bin
/usr/local/opt/icu4c/sbin
/usr/local/opt/icu4c/bin
/usr/local/opt/gettext/bin
/usr/local/opt/binutils/bin
/usr/local/bin
/usr/local/sbin
/usr/bin
/bin
/usr/sbin
/sbin
/opt/X11/bin
/usr/local/opt/e2fsprogs/bin
/usr/local/opt/e2fsprogs/sbin

Команды работают в однострочных и других многострочных вводах: 

$ echo "asdfdfasdfsadf" | cut -c 4-8
fdfas
$ echo "asdfdfasdfsadf" | grep 'df'
asdfdfasdfsadf
$ echo "asdfdfasdfsadf" | grep -v 'df'
$ ls -l | grep aps
drwx------   25 xxxx staff  800 Mai 17 23:33 Maps

Я также пробовал sort и xargs после канала: такое же поведение.

Может быть, виноват многострочный возврат echo -e ${PATH//:/\\n}, или установка / настройка неверны?

Последнее более вероятно из-за этого: 

$ which cut
/usr/local/opt/coreutils/libexec/gnubin/cut
$ whereis cut
/usr/bin/cut
$ which grep
/usr/local/opt/grep/libexec/gnubin/grep
$ whereis grep
/usr/bin/grep

Я признаюсь, что был полностью сбит с толку.

1 Ответ

0 голосов
/ 26 мая 2019

@ Камил Цук Все ваши предложения сработали, с помощью copy-paste. И ты был прав насчет нечитаемого персонажа.

Я открыл историю bash в BBEdit и искал необычные символы, и нашел \x{A0} (неразрывный пробел) между | и следующими командами.

... И поскольку я всегда использовал строку с помощью клавиши со стрелкой вверх, этот гремлин сохранялся во всех попытках.

Спасибо за вашу скорую помощь! Вы можете сделать комментарий ответом?

...