Это не из-за конвейера, а из-за {}. Сделай без них

не, если верить ману - фигурные скобки не запучкают, а вот конвейер запускает порожденный интерпретатор вот например следующий код на переменную var не оказывает ни какого влияния

echo "1:2:3:4:" | while read -d : n ; do  var=var:$n; done

и как все-таки найти файл в $PATH?

тему не читал

и как все-таки найти файл в $PATH?

% readlink -f $(which www-browser) 
/usr/bin/lynx

дочитай man bash на предмет >>>

там есть только <<<
а что в моём варианте не так?

which?

вот у тебя как раз правильно.

sed 's/:/\n/g'< <(echo $PATH)

ну надо было не просто s/:/\n/, надо было в переменную запихивать.

JSON или «питонсон»

как вернуть значение переменной

#!/bin/bash

function f() {
    name="$1"
    echo $PATH | while read -d : p; do
        [ -e "$p"/"$name" ] && { echo "$p"/"$name"; break; }
    done
}

echo $(f 'bash')

done< <(echo $PATH)

done <<<$PATH

И зачем лишнюю команду исполнять? Не ты ли орал на людей за лишние команды cat?

в этом говнокоде

while read -d: p;do
    [ -e "$p/$name" ]&&{ name="$p/$name";break; }
done< <(echo $PATH)

мой вариант:

$ NAME=ls; find ${PATH//:/ } -name "$NAME" -executable

вроде-бы ТС этого хотел подсознательно.

set ${PATH//:/ }

тоже вариант.

мой вариант

which "$NAME"

You won.

это уже было в симпсонах ☺

ну и вопрос был не о поиске, зачем тут твой find?

вроде-бы ТС этого хотел подсознательно.

но все-таки такой вопрос возникал у меня раньше и на других примерах

Так чуть лучше:

while read -d: p;do
    [ -e "$p/$name" ]&&{ name="$p/$name";break; }
done <<< $PATH

уже было

проблема в сабшеле, здесь два варианта: или избегать сабшела или возвращать результат через файл или stdout, типа var=$(subshell)

избегать сабшела

если подумать: а зачем он здесь?

В любом случае, это временный файл, пусть даже это пайп. В простых случаях это оправданно, вроде

ps uax|grep 'чё-то'