어느 것이 더 낫습니까?
#!/usr/bin/env sh#!/bin/sh- 비어 있음/제목 없음
나는 첫 번째 것이 최고라고 생각했지만 Android와 같은 일부 Linux 기반 시스템에서는 경로 이름이 누락되었으므로 이제 "이식 가능한" 쉘 스크립트를 갖는 유일한 방법은 헤더를 포함하지 않는 것이라고 생각합니다.
답변1
이식성 측면에서 #!/bin/sh표준 Unix 또는 Linux 시스템에서 대부분 POSIX 호환 셸을 찾을 수 있다고 안전하게 가정할 수 있지만 그게 전부입니다.
FreeBSD, OpenBSD 및 NetBSD(DragonFly, PC-BSD 및 일부 기타 파생 제품 포함)에는 bash가 존재하므로 /usr/local/bin/bash(설치된 경우) 이 /usr/bin/env방법은 Linux와 BSD 간의 이식성을 제공합니다.
Android는 표준 Unix 또는 Linux 시스템이 아닙니다. 루팅되지 않은 내 Android 휴대폰에는 시스템 쉘이 /usr/bin/env없거나 심지어 /bin/bash존재하지도 않습니다 ./bin/sh/system/bin/sh
누락된 쉘 스크립트 #!(shebang)는 일부 시스템에서 이를 호출한 쉘에서 실행을 시도하거나 /bin/bash다른 시스템(예:)에서 다른 기본 인터프리터를 사용할 수 있습니다. 그리고 동시에이것Android에서는 작동할 수 있지만 다른 운영 체제에서는 작동이 보장되지 않으므로 사용자는 그렇지 않은 경우를 선택할 수 있습니다 bash. (저는 기본 셸인 FreeBSD에서 tcsh를 사용하며 셔뱅이 없는 스크립트는 호출 셸에서 해석됩니다.)
제가 앉은 자리에서 보면 이런 느낌이에요불가능한Android는 사물을 다르게 처리하므로 Android와 Android가 아닌 시스템(Linux 또는 Unix) 간에 이식 가능한 셸 스크립트를 만듭니다.
답변2
내 경험상 #!/bin/sh나는 항상 #!/bin/bash내가 개발한 몇 가지 시스템에서 올바른 환경을 찾게 됩니다. 아직 예외가 발생하지 않았습니다. 나는 또한 쉘 스크립팅 관련 텍스트에서 자주 사용되는 것을 발견했는데, 이 텍스트는 다른 독자에 대한 이식성을 염두에 두고 작성되었다고 생각합니다.
같은 말을 할 수 없습니다 #!/usr/bin/env. 일부 시스템에는 이를 설치했는데 #!/bin/env과거에 Python 스크립트가 손상되었습니다. 그래서 저는 두 번째 글머리 기호를 선택하겠습니다.
위의 진술에 대한 몇 가지 뒷받침은 다음과 같습니다.
CentOS 5.7 버전에서는 다음 메시지가 나타납니다.
$ which env
/bin/env
Ubuntu 12.04 Precision Pangolin:
$ which env
/usr/bin/env
또한 적어도 하나의 이전 시스템에는 어떤 이유로 관리자가 설치되어 있었던 것으로 기억됩니다 coreutils( /opt아마도 모범 사례는 아닐 것임). env그것이 그것의 일부이기 때문에 coreutils, 사용자는 결국 그것을 얻게 됩니다 /opt/coreutils/bin/env. 물론, 모든 시스템을 사용해 본 것은 아니므로 답변은 제한된 경험을 바탕으로 한 것입니다.