что по твоему делает конструкция «< /dev/null»?

«mplayer file &» не запускается, в faq сказано, что нужно запускать «mplayer file < /dev/null &» и это работает.

> /dev/null

а не < /dev/null

http://www.mplayerhq.hu/DOCS/HTML/en/faq.html#idp11063536

Угадай, что теперь вызывается в функции mplayer по команде mplayer.

mplayer ${@} >&/dev/null < /dev/null &

У тебя функция mplayer вызывает функцию mplayer в фоне. В результате у тебя получилась бесконечная цепочка процессов bash с вызовом mplayer, в которой после запуска нового процесса предыдущий процесс завершается. Этакий огрызок от fork-бомбы 8). Утилиты типа top не видят эти процессы и не позволяют их убить, так как те возникают и завершаются слишком быстро.

mplayer() {
  /usr/bin/mplayer "$@" </dev/null >/dev/null &
}

Если вызвать mplayer по полному пути, запустится именно бинарник, а не bash-функция.

Имхо лучше `which mplayer`

/usr/bin/mplayer «$@» </dev/null >/dev/null &

а для чего нужно </dev/null?

а для чего нужно </dev/null?

ЕМНИП плеер реагирует на команды из /dev/stdin. Вот, что-бы не реагировал.

PS: наверное у него там кнопки проверяются, дабы скрипт прервать. Или что-то такое.

я бы ещё 2>&1 дописал бы

я бы ещё 2>&1 дописал бы

Это по желанию. В идеале программа не должна писать в stderr, если всё хорошо. А если всё настолько плохо, что это надо написать в stderr, то пользователю определённо стоит на текст ошибки взглянуть. В реальности туда сыпется всякий хлам, так что да, дописать надо бы.

запускался отдельным процессом, а консоль можно было закрыть

я не думаю, что тут нужен stderr

В реальности туда сыпется всякий хлам, так что да, дописать надо бы.

ИМХО нет. Мусор-немусор должен пользователь решать, а не скрипт. Если пользователю не нужно, то пусть он и отправляет. Хотя это конечно вопрос идеологии.

ты познал рекурсию, поздравляю.

теперь познай alias