-
긴 옵션을 선호하지만, POSIX 명령을 이식성 있게 호출해야 할 때는 짧은 옵션만이 유일한 선택임. POSIX는 긴 옵션을 명시하지 않음
- 예를 들어, diff의 사양을 참조할 수 있음
- 대부분의 경우, POSIX 유틸리티에 의존하기보다는 라이브러리 바인딩을 사용하는 것이 더 나은 대안임
- grep을 호출하는 대신 libpcre 같은 것을 사용하는 것이 더 효율적일 수 있음
- git, hg, rg, ag 등 비-POSIX 유틸리티에서는 긴 옵션을 사용하는 것이 합리적임
-
문자열 보간과 명령 실행을 혼합하지 말아야 함
- 특히 명령이 셸을 통해 처리될 때 주의해야 함
- 어떤 언어든지 리스트 기반 또는 배열 기반 실행 API를 사용하여 인수를 execv(2), execvp(2) 등으로 직접 전달해야 함
-
긴 옵션을 사용해야 한다는 것에 동의하지만, 이식성을 고려해야 함
- 모든 BSD 배포판이 GNU 스타일의 긴 옵션을 지원하지 않음
- 이식성을 원한다면 짧은 옵션을 사용해야 함
-
모든 옵션 뒤, 동적 인수 앞에 “--”를 사용하는 것을 잊지 말아야 함
-
명령을 호출하기 전에 명령의 길이가 ARG_MAX보다 긴지 확인해야 함
- 예를 들어, 다음과 같은 명령이 있을 때:
-
grep --ignore-case --files-with-matches -- "hello" *.c
- 이렇게 호출해야 함:
-
CMD="grep --ignore-case --files-with-matches -- \"hello\" *.c"
-
ARG_MAX=$(getconf ARG_MAX)
-
CMD_LEN=${#CMD}
-
if (( CMD_LEN > ARG_MAX )); then
-
echo "Error: Command length ($CMD_LEN) exceeds ARG_MAX ($ARG_MAX)." >&2
-
exit 1
-
fi
-
eval "$CMD" # 경고, 파일 이름을 평가함
-
이 방법에 동의함. 또 다른 이점은 옵션이 무엇을 하는지 man 페이지에서 grep하기가 더 쉬워짐
-
스크립트를 다른 POSIX 시스템에 이식 가능하게 만들고 싶다면 짧은 옵션을 사용해야 할 수도 있음
- 긴 옵션은 표준화되지 않았음
- 스스로 트레이드오프를 결정해야 함
-
옵션을 별도의 줄에 두어 추적하고 git blame하기 쉽게 해야 함
-
스크립트를 작성할 때의 기본 규칙 중 하나임. 긴 옵션이 가능하다면 사용해야 함
-
긴 형식 옵션은 독자에게 훨씬 더 설명적임