[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: shell background job and trap SIGCHILD



On 2016-10-29, Dmitry Alexandrov wrote:

>> Проще command -v ${command}
>
> Пардон, для чего проще?  Для программной проверки, быть может, и так, но для восприятия человеком (как здесь) — боюсь, что нет.
>
``which`` сторонняя утилита и ничего не говорит о том как поступает интерпретатор.

>> оно если с полным путем, то бинарь на диске,
>
> Да не обязательно с полным.  Если подать на вход относительный, то он его и вернет, при условии, что по нему есть исполняемость.
>
> $ command -v .bin/chdate
> .bin/chdate
>
> Или если в «$PATH» за каким-то чертом внесен относительный путь, то также именно он и будет возвращен.
>
> $ export PATH=".:$PATH"
> $ cd .bin
> $ command -v chdate
> ./chdate

Да, забавно. Можно и относительные пути писать, ./run-me синтаксис нужен что
бы добавить слеш в путь, тогда PATH не используется.

Из POSIX 2013 по built-in ``command -v``:

  Utilities, regular built-in utilities, command_names including a <slash>
  character, and any implementation-defined functions that are found using the
  PATH variable (as described in Command Search and Execution), **shall** be
  written as **absolute** pathnames.

Но по env var ``PATH``:

  If the pathname being sought contains a <slash>, the search through the path
  prefixes shall not be performed. If the pathname begins with a <slash>, the
  specified path is resolved.

И тут же:

  The list shall be searched from beginning to end, applying the filename to
  each prefix, until an executable file with the specified name and appropriate
  execution permissions is found.

Выходит что "**shall** be written as **absolute** pathnames" не совсем
однозначно трактуется.
-- 
http://defun.work/


Reply to: