추가 읽기

추가 읽기

~에서쉘 명령 언어POSIX 사양 페이지:

셸 명령 파일의 첫 번째 줄이 "#!" 문자로 시작하면 결과가 지정되지 않습니다.

#!POSIX가 지정되지 않은 동작인 이유는 무엇입니까? 이식성이 뛰어나고 널리 사용되는 것이 지정되지 않은 동작을 가져야 한다는 것이 당혹스럽습니다.

답변1

나는 주로 다음과 같은 이유 때문이라고 생각합니다.

  • 동작은 구현마다 크게 다릅니다. 바라보다https://www.in-ulm.de/~mascheck/various/shebang/모든 세부정보를 확인하세요.

    그러나 이제 대부분의 Unix 유사 구현의 최소 하위 집합을 지정할 수 있습니다. 예를 들어 #! *[^ ]+( +[^ ]+)?\n(이식 가능한 파일 이름 문자 집합의 문자만 포함하는 한두 단어로) 여기서 첫 번째 단어는 기본 실행 파일 절대 경로의 단어이지만 실행 파일이 setuid/setgid이고 구현이 인터프리터 경로 또는 스크립트 경로가 argv[0]인터프리터에 전달되는지 여부를 정의하는 경우 너무 길지 않으며 동작이 지정되지 않습니다.

  • POSIX는 어쨌든 실행 파일의 경로를 지정하지 않습니다. 일부 시스템에는 /bin/에 POSIX 이전 유틸리티가 있고 /usr/bin다른 곳에는 POSIX 유틸리티가 있습니다(예: Solaris 10에는 /bin/shBourne 쉘이 있고 POSIX 유틸리티는 에 있습니다 /usr/xpg4/bin. Solaris 11에서는 이를 POSIX와 더 호환되는 ksh93으로 대체하지만 대부분의 다른 시스템은 대체되었습니다. ksh93으로). 의 도구는 /bin여전히 POSIX가 아닌 고대 도구입니다. 일부 시스템은 POSIX 시스템이 아니지만 POSIX 모드/에뮬레이션을 갖추고 있습니다. 모든 POSIX 요구 사항은 시스템이 POSIX 방식으로 작동할 수 있는 문서화된 환경입니다.

    예를 들어 Windows+Cygwin을 참조하세요. 실제로 Windows+Cygwin의 경우 기본 Windows 응용 프로그램이 아닌 cygwin 응용 프로그램에서 스크립트를 호출할 때 she-bang이 존중됩니다.

    따라서 POSIX가 shebang 메커니즘을 지정하더라도 POSIX sh// sed... awk스크립트를 작성하는 데 사용할 수 없습니다(또한 shebang 메커니즘은 닫기 옵션 마커 전달을 허용하지 않기 때문에 신뢰할 수 있는 sed/ 스크립트를 작성하는 데 사용할 수 없습니다).awk

#!이제, 지정되지 않았다는 사실이 그것을 사용할 수 없다는 것을 의미하지는 않습니다. 시작), 그러나 그렇게 함으로써 POSIX는 어떠한 보장도 제공하지 않습니다.

내 경험에 따르면 shebang을 사용하면 POSIX 쉘 스크립트 작성 방식보다 더 나은 이식성이 보장됩니다. she-bang을 버리고 shPOSIX 구문으로 스크립트를 작성하고 해당 스크립트를 호출하는 모든 것이 POSIX 호환 스크립트를 호출하기를 바랍니다. sh즉, 괜찮습니다. 스크립트가 올바른 환경에서 올바른 도구에 의해 호출된다는 것을 알고 있다면 그렇지 않으면 그렇지 않습니다.

다음을 수행해야 할 수도 있습니다.

#! /bin/sh -
if : ^ false; then : fine, POSIX system by default
else
  # cover Solaris 10 or older. ": ^ false" returns false
  # in the Bourne shell as ^ is an alias for | there for
  # compatibility with the Thompson shell.
  PATH=`getconf PATH`:$PATH; export PATH
  exec /usr/xpg4/bin/sh - "$0" ${1+"$@"}
fi
# rest of script

Windows+Cygwin으로 포팅하려면 파일 이름을 .bat또는 확장명으로 지정하고 유사한 트릭을 사용하여 동일한 파일에서 cygwin을 호출해야 할 수 있습니다..ps1cmd.exepowershell.exesh

답변2

모든 POSIX 호환 쉘의 동작은 일관된 것 같습니다. 여기서는 흔들릴 필요가 없다고 생각합니다.

당신은 충분히 깊이 보지 않았습니다.

1980년대 초 이 메커니즘은아니요사실상의 표준화. Dennis Ritchie가 이를 구현했지만 AT&T 측에서는 아직 구현이 대중의 손에 닿지 않았습니다. 실제로는 공개적으로만 사용 가능하며 BSD에서만 알려져 있습니다. AT&T Unix에서는 사용할 수 없는 실행 가능한 쉘 스크립트가 있습니다. 그러므로 그것을 표준화하는 것은 불합리하다. 이는 많은 doco 중 하나인 현대 doco에 의해 예시됩니다.

BSD는 #! interpretera로 시작하는 파일의 직접 실행을 허용하는 반면 SysV는 a.out 파일의 직접 실행만 허용합니다. 이는 프로그램의 인터프리터가 (보통) 실행되기 exec…()위해서는 BSD 프로그램의 루틴 중 하나의 인스턴스가 SysV에서 변경되어야 할 수도 있음을 의미합니다 ./bin/sh
— 스티븐 프리드(1988). "시스템 X 버전 Y 프로그래밍".호주 Unix 시스템 사용자 그룹 뉴스레터. 9권 4호. 111.

여기서 중요한 것은 쉘을 보고 있는데, 실행 가능한 쉘 스크립트가 존재한다는 것은 실제로는 그 기능에 문제가 있다는 것입니다 exec…(). 쉘의 기능은 다음과 같습니다전구 물질오늘날에도 여전히 일부 셸에서 발견되는 실행 가능한 스크립팅 기계의 일부는 exec…p()다소 오해의 소지가 있습니다. 이와 관련하여 표준에서 다루어야 할 것은 exec…()스크립트의 작동 방식과 POSIX가 처음 생성된 시기를 설명하는 것 입니다.처음부터 대상 운영 체제의 주요 부분에서 실행되지 않습니다..

사소한 질문은 특히 스크립트 인터프리터를 위한 매직 넘버 메커니즘으로서 그 이후로 표준화가 이루어지지 않은 이유입니다.가지다AT&T Universe 측에서 대중에게 공개 exec…()되었으며시스템 5 인터페이스 정의, 1990년대로 접어들면서:

인터프리터 파일은 다음 형식의 줄로 시작합니다.

#! 경로 이름[매개변수]
어디경로명통역사에 대한 경로이며,아르기닌선택적 매개변수입니다. 인터프리터 파일을 사용 하면 exec시스템은 exec지정된 인터프리터를 사용합니다.
exec. System V 인터페이스 정의. 1991년 1권.

불행하게도 이 동작은 1980년대와 마찬가지로 오늘날에도 여전히 다르며 표준화할 실제 공통 동작이 없습니다. 일부 Unices(예: 유명한 HP-UX 및 FreeBSD)는 스크립트에 대한 해석기로 스크립트를 지원하지 않습니다. 첫 번째 줄이 공백으로 구분된 하나, 둘 또는 그 이상의 요소인지 여부는 MacOS(및 2005년 이전 FreeBSD 버전)와 다른 운영 체제에 따라 다릅니다. 지원되는 최대 경로 길이는 다양합니다. POSIX 이식 가능한 파일 이름 문자 세트 외부의 문자는 앞뒤 공백과 마찬가지로 까다롭습니다. 0번째, 1번째, 2번째 매개변수에 대한 최종 결과도 까다롭고 시스템마다 크게 다릅니다. 일부는 현재 POSIX와 호환되지만아니요-Unix 시스템은 여전히 ​​그러한 메커니즘을 지원하지 않으며 이를 시행하면 더 이상 POSIX와 호환되지 않는 것으로 변환됩니다.

추가 읽기

답변3

다른 답변에서 지적했듯이 구현은 다양합니다. 이는 표준화를 어렵게 만든다.그리고기존 스크립트와의 역호환성을 유지합니다. 이는 최신 POSIX 시스템에서도 마찬가지입니다. 예를 들어 Linux는 shebang 줄을 공백으로 완전히 표시하지 않습니다. macOS에서는 스크립트 해석기가 다른 스크립트가 되는 것을 허용하지 않습니다.

또한보십시오http://en.wikipedia.org/wiki/Shebang_(Unix)#이식성

관련 정보