Hacker News 의견

• 긴 옵션을 선호하지만, 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하기 쉽게 해야 함

• 스크립트를 작성할 때의 기본 규칙 중 하나임. 긴 옵션이 가능하다면 사용해야 함

  • 그렇게 하는 것이 너무 합리적임

• 긴 형식 옵션은 독자에게 훨씬 더 설명적임

  • 오타가 덜 발생함