"#! / path / to / NAME"대신 "#! / usr / bin / env NAME"을 내 방아쇠로 사용하는 것이 더 좋은 이유는 무엇입니까?

나는 다른 사람들로부터 얻은 일부 스크립트는 shebang #!/path/to/NAME을 가지고 있고 다른 스크립트 는 같은 도구를 사용하여 shebang 을 가지고 있음을 알았습니다 #!/usr/bin/env NAME.

둘 다 제대로 작동하는 것 같습니다. 자습서 (예 : Python)에서는 후자의 shebang이 더 낫다는 제안이있는 것 같습니다. 그러나 이것이 왜 그런지 잘 모르겠습니다.

나는 후자의 shebang을 사용하려면 NAME이 PATH에 있어야하지만 첫 번째 shebang에는이 제한이 없다는 것을 알고 있습니다.

또한 NAME이 위치한 곳을 정확하게 지정하기 때문에 첫 번째가 더 나은 Shebang이 될 것입니다. 따라서이 경우 여러 버전의 NAME (예 : / usr / bin / NAME, / usr / local / bin / NAME)이있는 경우 첫 번째 경우는 사용할 버전을 지정합니다.

내 질문은 왜 첫 번째 세방이 두 번째 세방보다 선호됩니까?

반드시 더 좋은 것은 아닙니다.

장점은 사용자의 첫 번째 실행 파일 #!/usr/bin/env python을 모두 사용한다는 것입니다 .python$PATH

단점 의는 #!/usr/bin/env python그것이 무엇이든 사용하는 것입니다 python사용자의에 처음 나타나는 실행 $PATH.

이는 스크립트를 실행하는 사람에 따라 스크립트가 다르게 작동 할 수 있음을 의미합니다. 한 사용자의 /usr/bin/python경우 OS와 함께 설치된 것을 사용할 수 있습니다 . 다른 경우에는 /home/phred/bin/python제대로 작동하지 않는 실험 을 사용할 수 있습니다 .

만약 python단지에 설치되어 /usr/local/bin,이없는 사용자 /usr/local/bin인은 $PATH심지어 스크립트를 실행할 수 없습니다. (아마도 현대 시스템에서는 그럴 것 같지 않지만 더 모호한 통역사에게는 쉽게 발생할 수 있습니다.)

지정 #!/usr/bin/python하면 특정 시스템 에서 스크립트를 실행하는 데 사용할 인터프리터를 정확하게 지정할 수 있습니다 .

또 다른 잠재적 인 문제는 #!/usr/bin/env트릭 으로 인해 해석자가 인수를 전달할 수 없다는 것입니다 (암시 적으로 전달되는 스크립트 이름 이외). 이것은 일반적으로 문제가 아니지만 문제가 될 수 있습니다. 많은 Perl 스크립트는로 작성 #!/usr/bin/perl -w되었지만 use warnings;요즘에는 권장되는 대체 방법입니다. Csh 스크립트는 사용해야 #!/bin/csh -f하지만 처음 에는 csh 스크립트가 권장되지 않습니다 . 그러나 다른 예가있을 수 있습니다.

개인 시스템 제어 시스템에 새 시스템에 계정을 설정할 때 설치하는 여러 Perl 스크립트가 있습니다. 내 스크립트를 #!설치할 때 각 스크립트 의 줄 을 수정하는 설치 관리자 스크립트를 사용합니다 $HOME/bin. (저는 #!/usr/bin/perl최근에 다른 것을 사용할 필요가 없었습니다 . Perl이 기본적으로 설치되지 않은 때로 되돌아갑니다.)

사소한 요점 : #!/usr/bin/env트릭은 아마도 env이름이 암시하는 것처럼 변경된 환경에서 명령을 호출하기위한 명령 의 남용입니다 . 또한 일부 구형 시스템 (정확하게 리콜하면 SunOS 4 포함)에 env명령 이 없었 습니다 /usr/bin. 이들 중 어느 것도 중요한 문제가되지 않을 것입니다. env이 방법으로 작동하면 많은 스크립트가 #!/usr/bin/env트릭을 사용 하며 OS 제공 업체는이를 해결하기 위해 아무것도하지 않을 것입니다. 그것은 수도 당신이 당신의 스크립트가 정말 오래된 시스템에서 실행하려면,하지만 당신은 어쨌든 그것을 수정해야 할 가능성이있는 경우 문제가 될 수.

또 다른 가능한 문제는 의견에서 지적한 Sopalajo de Arrierez 덕분에 크론 작업이 제한된 환경에서 실행된다는 것입니다. 특히, $PATH일반적으로 같은 것 /usr/bin:/bin입니다. 따라서 인터프리터를 포함하는 디렉토리가 해당 디렉토리 중 하나에 있지 않으면 $PATH사용자 쉘 의 기본값 에 있더라도 /usr/bin/env트릭이 작동하지 않습니다. 정확한 경로를 지정하거나 crontab에 줄을 추가하여 설정할 수 있습니다 $PATH( man 5 crontab자세한 내용).

/ usr / bin / env가를 해석 할 수 있기 때문에 $PATH스크립트를보다 이식성이있게 만듭니다.

#!/usr/local/bin/python

파이썬이 / usr / local / bin에 설치된 경우에만 스크립트를 실행합니다.

#!/usr/bin/env python

를 해석 $PATH하고의 모든 디렉토리에서 파이썬을 찾으십시오 $PATH.

따라서 스크립트는 이식성이 뛰어나고 python이 /usr/bin/python, 또는 /usr/local/bin/python, 또는 사용자 정의 디렉토리 (에 추가 된 $PATH) 로 설치된 시스템에서 수정하지 않고도 작동 /opt/local/bin/python합니다.

이식성이 env하드 코딩 된 경로보다 선호되는 유일한 이유 입니다.

주어진 시스템에서 절대 경로를 지정하는 것이 더 정확합니다. 단점은 너무 정확하다는 것입니다. Perl의 시스템 설치가 스크립트에 비해 너무 오래되었고 대신 직접 사용하고 싶다고 가정하면 스크립트를 편집하고로 변경 #!/usr/bin/perl해야 #!/home/myname/bin/perl합니다. 더 나쁜 점 /usr/bin은 일부 컴퓨터, 다른 컴퓨터 /usr/local/bin및 다른 컴퓨터 에서 Perl을 사용 하는 경우 /home/myname/bin/perl세 개의 별도 스크립트 사본을 유지 관리하고 각 컴퓨터에서 적절한 스크립트를 실행해야합니다.

#!/usr/bin/env나쁘면 깨지지 PATH만 거의 아무것도하지 않습니다. 나쁜 작업을 시도하는 PATH것은 매우 유용하지 않으며 스크립트가 실행되는 시스템에 대해 거의 알지 못하므로 절대 경로에 의존 할 수 없습니다.

거의 모든 유닉스 변형에 의존 할 수있는 두 개의 프로그램이 있습니다 : /bin/sh및 /usr/bin/env. 애매 모호하고 은퇴 한 유닉스 변종 중 일부는 /bin/env을 갖지 /usr/bin/env못했지만 그럴 가능성은 거의 없습니다. 현대 시스템은 /usr/bin/env셰방에서 널리 사용되기 때문에 정확하게 사용되었습니다. /usr/bin/env믿을 수있는 것입니다.

을 제외 /bin/sh하고 shebang에서 절대 경로를 사용해야하는 유일한 경우는 스크립트가 이식성이 없어야하는 것으로 통역사의 알려진 위치를 신뢰할 수 있습니다. 예를 들어 Linux에서만 작동하는 bash 스크립트는 안전하게 사용할 수 있습니다 #!/bin/bash. 사내에서만 사용되는 스크립트는 하우스 통역사 위치 규칙에 의존 할 수 있습니다.

#!/usr/bin/env단점이 있습니다. 절대 경로를 지정하는 것보다 유연하지만 여전히 통역사 이름을 알아야합니다. 경우에 따라 ( $PATH예 : 스크립트와 관련된 위치에 없는) 인터프리터를 실행하려고 할 수 있습니다 . 이러한 경우 표준 쉘과 원하는 인터프리터에서 모두 해석 할 수 있는 폴리 글 로트 스크립트 를 만들 수 있습니다. 예를 들어, Python 2 스크립트를 pythonPython 3 및 python2Python 2 인 시스템과 Python 2 인 시스템 python과 python2존재하지 않는 시스템 모두에서 이식 가능하게하려면 다음을 수행하십시오.

#!/bin/sh
''':'
if type python2 >/dev/null 2>/dev/null; then
  exec python2 "$0" "$@"
else
  exec python "$0" "$@"
fi
'''
# real Python script starts here
def …

특히 perl의 경우 #!/usr/bin/env두 가지 이유로 사용하는 것이 좋지 않습니다.

첫째, 휴대용이 아닙니다. 일부 모호한 플랫폼에서 env는 / usr / bin에 없습니다. 둘째, 키이스 톰슨 (Keith Thompson) 이 지적했듯이 shebang 라인에 인수를 전달하는 데 문제가 발생할 수 있습니다. 최대 휴대용 솔루션은 다음과 같습니다.

#!/bin/sh
exec perl -x "$0" "$@"
#!perl

작동 방식에 대한 자세한 내용은 'perldoc perlrun'및 -x 인수에 대한 내용을 참조하십시오.

이 둘이 구별되는 이유는 스크립트가 실행되는 방식 때문입니다.

사용하는 것이 /usr/bin/env(다른 답변에서 언급 한 바와 같이,에서하지 않은, /usr/bin그냥 한 후 실행 파일 이름을 넣을 수 없기 때문에 어떤 운영체제에) 필요 #!가 절대 경로 여야합니다 -. #!메커니즘이 쉘보다 낮은 레벨에서 작동 하기 때문 입니다. 커널 바이너리 로더의 일부입니다. 테스트 할 수 있습니다. 이것을 파일에 넣고 실행 파일로 표시하십시오.

#!bash

echo 'foo'

실행하려고 할 때 다음과 같은 오류가 인쇄됩니다.

Failed to execute process './test.sh'. Reason:
The file './test.sh' does not exist or could not be executed.

파일이 실행 파일로 표시되고로 시작하는 #!경우 커널 (알 수없는 $PATH디렉토리 또는 현재 디렉토리 : 사용자 랜드 개념)은 절대 경로를 사용하여 파일을 찾습니다. 절대 경로를 사용하는 것은 문제가 있기 때문에 (다른 답변에서 언급했듯이) 누군가가 트릭을 생각해 냈습니다. /usr/bin/env(거의 항상 해당 위치에 있음)을 사용하여 무언가를 실행할 수 $PATH있습니다.

사용에 두 가지 문제가 더 있습니다 #!/usr/bin/env

1. 인터프리터의 전체 경로를 지정하는 문제를 해결하지 않고 단지로 이동합니다 env.

   env에 있거나 파이썬에 있다고 보장 된 /usr/bin/env것보다 더 이상 보장되지 않습니다 .bash/bin/bash/usr/bin/python

2. env ARGV [0]을 인터프리터 이름으로 덮어 씁니다 (예 : bash 또는 python).

   이렇게하면 스크립트 이름이 ps출력 (또는 출력 방법 / 위치 변경)에 표시되지 않으며 예를 들어ps -C scriptname.sh

[업데이트 2016-06-04]

그리고 세번째 문제 :

3. PATH 변경 은 스크립트의 첫 번째 줄을 편집하는 것보다 더 많은 작업입니다. 특히 이러한 편집을 스크립팅하는 것이 쉽지 않습니다. 예 :

   printf "%s\n" 1 i '#!'$(type -P python2) . w | ed foo.py

   디렉토리를 $ PATH에 추가하거나 미리 추가하는 것은 상당히 쉽습니다 (파일을 영구적으로 만들기 위해 파일을 편집해야하지만 자신 ~/.profile이나 무엇이든). , 첫 번째 줄이 아님).

   PATH 디렉토리의 순서를 변경하는 것은 #!라인을 편집하는 것보다 훨씬 어렵고 어렵습니다 .

   그리고 당신은 여전히 ​​사용하는 다른 모든 문제가 #!/usr/bin/env있습니다.

   @jlliagre는 #!/usr/bin/env여러 개의 인터프리터 버전으로 스크립트를 테스트하는 데 유용한 주석 에서 "PATH / PATH 순서 만 변경하여"

   그렇게 해야하는 경우 #!스크립트 상단에 여러 줄을 두는 것이 훨씬 쉽고 (첫 번째 줄 이외의 주석 만 표시합니다) 지금 사용하려는 줄을 잘라 내고 복사하여 붙여 넣기 가 더 쉽습니다. 첫 줄.

   에서 vi, 그것은으로 커서를 이동하는 것처럼 간단 할 것이다 #!다음, 당신이 원하는 라인 입력 dd1GP또는 Y1GP. 과 같은 편집기 nano를 사용하더라도 마우스를 사용하여 복사하여 붙여 넣는 데 몇 초가 걸립니다.

전반적으로, 사용의 장점 #!/usr/bin/env은 최소한이며, 단점을 능가하는 것은 아닙니다. "편의"의 장점조차도 환상적입니다.

IMO는 운영 체제가 작업 대상이 아니라고 생각하거나 문제 를 해결 하는 데 문제 가 있다고 생각하는 특정 종류의 프로그래머가 권장하는 어리석은 아이디어 입니다.

추신 : 여기에 여러 파일의 인터프리터를 한 번에 변경하는 간단한 스크립트가 있습니다.

change-shebang.sh:

#!/bin/bash

interpreter="$1"
shift

if [ -z "$(type -P $interpreter)" ] ; then
  echo "Error: '$interpreter' is not executable." >&2
  exit 1
fi

if [ ! -d "$interpreter" ] && [ -x "$interpreter" ] ; then
  shebang='#!'"$(realpath -e $interpreter)" || exit 1
else
  shebang='#!'"$(type -P $interpreter)"
fi

for f in "$@" ; do
  printf "%s\n" 1 i "$shebang" . w | ed "$f"
done

예를 들어, change-shebang.sh python2.7 *.py또는change-shebang.sh $HOME/bin/my-experimental-ruby *.rb

여기에 다른 예를 추가하십시오.

예를 들어 env여러 rvm환경 간에 스크립트를 공유하려는 경우에도 사용 이 유용합니다 .

cmd 행에서 이것을 실행하면 #!/usr/bin/env ruby스크립트 내에서 사용될 때 어떤 루비 버전이 사용될지를 보여줍니다 .

env ruby --version

따라서를 사용할 때 env스크립트를 변경하지 않고 rvm을 통해 다른 루비 버전을 사용할 수 있습니다.

자신이나 직장을 위해 순수하게 글을 쓰고 있고 통역사의 위치가 항상 같은 곳에 있다면 반드시 직접 경로를 사용하십시오. 다른 모든 경우에는을 사용하십시오 #!/usr/bin/env.

이유는 다음과 같습니다. python사용하는 구문에 관계없이 통역사가 동일한 위치에 있었지만 많은 사람들이 다른 곳에 설치했을 수 있습니다. 대부분의 주요 프로그래밍 인터프리터는 /usr/bin/많은 최신 소프트웨어 에 있지만 기본값은 /usr/local/bin/입니다.

#!/usr/bin/env동일한 인터프리터의 여러 버전이 설치되어 있고 쉘의 기본값을 모르는 경우 항상 수정해야하기 때문에 항상 사용한다고 주장 합니다.

이식성과 호환성을 위해 사용하는 것이 좋습니다

#!/usr/bin/env bash

대신에

#!/usr/bin/bash

바이너리는 Linux / Unix 시스템에 위치 할 수있는 여러 가능성이 있습니다. 파일 시스템 계층에 대한 자세한 설명은 hier (7) 맨 페이지를 확인하십시오.

예를 들어 FreeBSD는 기본 시스템의 일부가 아닌 모든 소프트웨어를 / usr / local /에 설치 합니다. bash는 기본 시스템의 일부가 아니므로 bash 바이너리는 / usr / local / bin / bash에 설치 됩니다.

대부분의 Linux 배포판과 FreeBSD에서 실행되는 이식 가능한 bash / csh / perl / whatever 스크립트를 원할 경우 #! / usr / bin / env 를 사용해야합니다 .

또한 대부분의 리눅스 설치는 (하드)도 가지고있는 ENV 바이너리를 연결하는 것이, 메모를해야 / 빈에 / 빈 / ENV 또는 softlinked는 / usr / bin으로 하지 오두막에 사용. 따라서 #! / bin / env를 사용하지 마십시오 .