일부 유틸리티는 옵션보다 먼저 피연산자를 구문 분석하는 이유는 무엇입니까?

일부 유틸리티는 옵션보다 먼저 피연산자를 구문 분석하는 이유는 무엇입니까?

~에 따르면일부 원천, UNIX 유틸리티 안내서에서는 피연산자가 항상 옵션 뒤에 처리되어야 한다고 지정합니다.

utility_name[OPTIONS][operands...]

예를 들어 일부 오래된 UNIX 유틸리티는 이러한 규칙을 정확하게 따르지 않는 것으로 알려져 있지만, find더 새롭고 잘 확립된 유틸리티도 예를 들어 명확한 설명 없이 규칙을 위반합니다 curl <url>.

이에 대한 타당한 이유가 있는지, 이에 대한 일반적인 커뮤니티의 합의는 무엇인지 알고 싶습니다.

답변1

일반적인 규칙은 매개변수가 항상 옵션 뒤에 오는 것입니다. 옵션이 아닌 첫 번째 문자열(로 시작하지 않는 명령줄의 첫 번째 문자열 -)은 옵션을 종료하고 인수를 시작합니다.

일부 도구, 특히 빌드 도구(컴파일러, 링커)는 항상 이 규칙을 위반합니다. 주목할만한 또 다른 예는 find옵션이 명령줄에 나타날 때마다 적용되기 때문에 수행되는 경우도 있으므로 옵션 앞뒤에 인수를 지정하는 방법이 필요합니다. 여기서 옵션은 인수가 다음에 나타날 경우에만 적용됩니다. 옵션은 이 매개변수에만 적용됩니다.

이 규칙을 사용하면 다음과 같은 줄을 포함하는 쉘 스크립트를 작성할 수 있습니다.

rm foobar ${more_things_to_remove}

...그리고 rm쉘 변수에 "" 같은 불쾌한 값이 있더라도 more_things_to_remove실수로 명령에 옵션을 추가하지 않도록 보장합니다 -rf.

--이 규칙은 옵션 처리를 종료하기 위해 특수 옵션을 사용하는 최근 규칙보다 우선합니다 . --옵션의 끝을 명시적으로 표시하는 더 좋은 방법은 다음과 같습니다.

rm -- foobar ${more_things_to_remove}

# and it works even if you don't need to delete something called "foobar":
rm -- ${more_things_to_remove}

그래서 최근(그리고 최근에는 이것이 수년 동안 계속되고 있음을 의미합니다) 더 많은 명령줄 파서가 이전 규칙을 깨고 옵션과 인수가 모든 곳에서 명백하게 혼합되도록 허용하는 방향으로 움직이는 것 같습니다(항상 --강제 종료 옵션) 컴파일러나 다른 도구처럼 규칙을 깨뜨릴 특별한 이유가 없더라도 마찬가지입니다.

개인적으로 어떤 유틸리티가 여전히 규칙을 준수하고 어떤 유틸리티가 그렇지 않은지 알 수 없기 때문에 항상 이전처럼 인수 앞에 옵션을 배치하고 다른 사람들의 작업 코드가 이를 역순으로 수행하는 것을 보면 조금 놀랐습니다!

관련 정보