실행 파일 이름에 "#"이 있으면 위험합니까?

실행 파일 이름에 "#"이 있으면 위험합니까?

이것은 FAQ일 수 있습니다. 사기라면 기꺼이 해결해 드리겠습니다. 하지만 사기라면 어떻게 찾을 수 있을지 모르겠습니다. 또한 문법 관련 문서를 찾는 방법을 간단하게 알려주는 답변을 받고 싶습니다. ( man bash우리는 오랜 친구입니다.)

쉘 스크립트의 이름을 "f#"로 지정하고 싶습니다.

#!/bin/sh
dotnet fsi "$@"

이는 Bash 명령줄에서 F# 프로그래밍 언어 실행 파일을 시작하는 바로 가기 역할을 합니다.

놀랍게도 이것은 "#"이 쉘 주석 문자임에도 불구하고 작동합니다. 스크립트에 매개변수를 전달할 수도 있습니다.

$ f# hello.fsx
Hello World from F`
$

이전 명령을 스크립트에 포함하고 문제 없이 스크립트를 실행할 수 있습니다. (!)

"#"은 앞에 공백이 있거나 줄의 시작 부분에 있는 경우에만 주석을 도입하는 것이 규칙인 것 같습니다. 그렇지 않으면 bash에서 일반 문자로 처리됩니다. 그렇죠?

"f#"을 스크립트 이름으로 사용하면 나중에 나를 귀찮게 할 수 있는 분명하지 않은 문제가 있습니까?

답변1

모든 버전의 bash 및 zsh를 포함하여 모든 sh 유사 쉘에서 #시작하십시오 .논평단어의 시작 부분에 있을 때. 이는 스크립트 또는 중첩된 셸의 시작 부분에 있거나(예 $(# this is a comment: 종결자는 )별도의 줄에 있어야 함) 앞에 공백 문자가 있거나 연산자 문자(이 중 하나 &|;<>)가 앞에 있어야 함을 의미합니다. 나중에는 댓글이 시작 f#되지 않습니다 f.

특별한 의미를 갖는 곳도 있지만 #, bash에서는 첫 번째 문자가 아닌 단어의 일부일 때 나타나는 경우가 생각나지 않고, bash에서는 단어를 기대합니다. (bash가 뭔가 다른 것을 기대할 때 이는 확실히 특별한 의미를 갖습니다. 예를 들어 #변수 이름의 일부로 사용할 수는 없습니다 .) zsh에서는 #다음과 같습니다.와일드카드extended_glob(항상 활성화) 옵션이 설정된 경우. #별칭에는 문제가 없지만(별칭은 글로빙 전에 확장됨) 스크립트 이름에는 문제가 있습니다.

이는 쉘에만 적용됩니다. 다른 도구에는 문제가 있을 수 있습니다 #. 구성 파일의 주석 문자로 흔히 발생합니다. 예를 들어 #확장에 Git 별칭을 포함 할 수 있는지 잘 모르겠습니다 .

답변2

이것2022년 9월 GNU Bash 버전 5.2 참조 매뉴얼"#으로 시작하는 단어는 해당 단어와 해당 줄의 나머지 모든 문자를 무시합니다."를 의미합니다. 단어는 "셸에서 하나의 단위로 처리되는 일련의 문자입니다. 단어에는 따옴표가 없는 메타 문자가 포함될 수 없습니다." "#" 문자는 메타문자의 일부가 아닙니다.

bash 2.05에 대한 문서는 그다지 정확하지 않지만 1.14.7 이전의 여러 버전의 bash에 대한 GNU 소스 코드를 분석한 결과 "#" 문자는 단어의 일부가 될 수 있으므로 "f#"의 일부가 될 수 있습니다.

현재의 많은 "/bin/sh" 경로는 실제로 bash 쉘입니다. 그래서 거기에는 별로 위험이 없습니다.

따라서 트랩은 bash에서 나오지 않지만 다른 도구에서 나올 수 있습니다. 예를 들어 유효하지 않은Bash용 BNF 구문이는 bash 스크립트를 해석하는 다른 도구의 구현을 오해할 수 있습니다.

Bash V2 BNF 발췌:

<ALPHA> ::= a|b|c|d|e|f|g|h|i|j|k|l|m|n|o|p|q|r|s|t|u|v|w|x|y|z|
             A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P|Q|R|S|T|U|V|W|X|Y|Z

<DIGIT> ::= 0|1|2|3|4|5|6|7|8|9

<NUMBER> ::= <DIGIT>
           | <NUMBER> <DIGIT>

<WORD> ::= <ALPHA>
         | <WORD> <ALPHA>
         | <WORD> '_'

문제는 주로 (따옴표가 없는) "#"을 주석의 시작으로 해석하는 프로그램이 있다는 것입니다. 아마도 가장 "성가신" 것은 코드 스타일 포맷터일 것입니다.아름다운올바르게 처리하지만 다른 사람들은 그렇지 않을 수도 있습니다.

진짜 문제는 편집기의 스타일입니다. vim은 다른 여러 환경과 마찬가지로 단어 내의 "#"을 주석의 시작 부분으로 처리합니다. 따라서 "f#" 인터프리터에 대한 인수에 잘못된 색상 코드를 제공하게 됩니다. 이러한 구문 강조 표시에는 버그가 있으며 개별적으로 수정하는 것이 그리 어렵지는 않지만 상당수가 있습니다... vim 8.2의 일부 버전은 색상 코드를 지정해야 하지만 다른 vim 8.2 버전은 그렇지 않습니다. 차이점은 아마도 vim 8.2 패치 중 하나에 있을 것입니다.

"f#"이 개인적인 용도로 사용되거나 제어할 수 있는 시스템에 있는 한 안전해야 합니다. 저는 글로벌(전역) 사용에 더 주의할 것입니다. 저는 그것이 데비안에 배포되는 인스턴스를 보는 것을 선호하지 않습니다.

관련 정보