인쇄 사용법 / 도움말 (–help)에 대한 모범 사례는 무엇입니까? 전혀 관리하기

UNIX CLI 용 도구를 작성할 때 프로그램에서 도움말 및 / 또는 사용법을 인쇄하려면 어떻게해야합니까?

나는 보통을 사용 fprintf(stderr, "help text here");하지만 그것에 몇 가지 문제가 있습니다.

  • 먼저을 사용해야하는지 잘 모르겠습니다 stderr. 괜찮 stdout습니까 , 아니면 사용해야 합니까?
  • 상상할 수 있듯이 도구의 옵션 수에 따라 도움말 텍스트가 매우 깁니다. 이제 보통 "strings like that\n"두 번째 매개 변수 에 여러 개 를 넣습니다 . 그러나 이것은 내 소스 코드를 50 줄 이상의 도움말 텍스트로 채 웁니다. 전혀 관리하기 쉽지 않습니다. 대신 어떻게해야합니까?
  • 도구가 C 또는 C와 같은 언어로 작성되지 않은 경우 가능한 경우 여기에서 문서 를 사용하는 경향이 있습니다 (대부분 Perl에서 두드러짐). 나는 그것을 C에서 사용할 수 없지만 사용할 수있는 것이 있습니까?
  • 나는에 넣어 고려하고 headerfile.h돌며 것은 #define HELP "help text here", 내가 야생에서 본 적이 없어, 나는 실제로 그것을 사용해야하는지 여부를 알 수 없습니다.

이상적으로는 텍스트를 외부 파일에 넣고 포함시킬 수있었습니다. #include그러나 그것을 사용 하는 것은 잘못 된 것 같습니다. 그러면 어떻게해야합니까?

아이디어는 쉽게 관리 할 수있는 도움말 텍스트를 갖는 것입니다. 소스 코드 안에 넣는 것은 실제로 편리하지 않습니다.

답변

대상 플랫폼의 내부에서 영감을 얻으십시오

BSD의 소스 코드를 살펴보십시오. 예를 들면 다음과 같습니다.

  • usage(void)NetBSD의 /usr/bin/uname도구 [ source ] :

    usage(void)
{
    fprintf(stderr, "usage: uname [-amnprsv]\n");
    exit(EXIT_FAILURE);
}

  • usage(void)NetBSD 용 /usr/bin/telnet[ source ]

  • usage(void)OpenBSD 용 /bin/ls[ source ]

대안을 살펴보십시오

그리고 그들이 나아지는지 스스로 결정하십시오. Google CodeSearch를 사용하여 다음과 같은 다른 사람을 찾을 수 있습니다.

  • SkyLoad의 사용법 [ 출처 ]

보시다시피, 위에 나열된 BSD 시스템 통합 도구와 이들 사이의 다른 스타일. 그것은 당신 이 하나 또는 다른 것을 따라야 한다는 것을 의미하지는 않습니다 . 그러나 일반적으로 주변을 둘러보고 일관된 솔루션을 찾는 것이 좋습니다.

50 가지 라인에 대한 비표준 솔루션 …

50 줄의 텍스트를 피하지 않으려면 텍스트 파일에서 도움말을 읽으십시오 (일반 텍스트로 작성하거나 man소스를 만든 경우 직접 소스를 구문 분석 할 수 있음). 나는 본질적으로 안전하지 않고 실패 지점을 소개하는 핵심 시스템 프로그램에 대해서는 다소 우아한 방법 (텍스트 문서조차도 볼 수 있음)을 발견했습니다. 다른 사람들은 그것이 메시지 usage나 help메시지에 대해 무겁다 고 주장 할 것입니다 .

의심스러운 경우 거인을 따르십시오.

답변

내가 사용 stdout도움말 오류가 아니기 때문에.

이것이 C에서 긴 도움이된다면 here-docs를 모방하려고합니다.

printf("This is the help for MyWonderfulApp\n"
       "Options are:\n"
       "    --help: display what you are reading now\n"
       "    --quiet: output nothing\n");

그러나 대부분 전용 태그를 man사용하여 페이지를 작성 nroff -man합니다. 인앱 도움말은 해당 man페이지 를 참조하여 구성됩니다 .

답변

내가 당신을 것 경우 그냥의 소스를 열어 것 grep, tail, cat, your_other_favorite_unix_shell_command그것이이 어떻게하는지 볼 수 있도록합니다. 나는 그들의 길을 잘 생각하고 많은 사람들이 유지할 수 있다고 확신합니다.

약 stderr이나 stdout. 오류가 있거나 stderr정보가있는 경우 쓰기가 정말 간단 stdout합니다. 예를 들어, 잘못된 옵션으로 도구를 실행하는 경우 오류가 표시 될 수 있습니다 (예 :이 도구 Use --help for usage는에 속해 있음) stderr. 유효한 옵션으로 도구를 실행하는 경우 --help사용하십시오 stdout.

코드 근처에 긴 도움말 문자열을 사용하지 않는 것이 좋습니다. 헤더 파일의 #define은 완벽하지만 괜찮은 개인 취향입니다. 명령 줄 도구의 코드를 읽어야하는 경우 도움말 문자열이 사용자가 제공 한 옵션을 처리하는 파일 안에있는 것이 좋습니다.

답변

gnu getopts 라이브러리를 사용합니다 . 도움이되는 예제 는이 샘플 프로젝트 , 특히 parser.y 의 맨 아래에있는 주요 메소드를 참조하십시오 .

그것이 중괄호로 싸여 있기 때문에, 내가 사용하는 vim 편집기는 선을 함께 접을 수 있으며 필요하지 않을 때조차도 눈에 띄지 않습니다.

답변

C를 사용하거나 Boost 라이브러리에 의존하지 않으려면 GNU를 고수하십시오 getopt. 그렇지 않으면 도움말을 자동으로 인쇄 하는 부스트 프로그램 옵션 을 선호합니다 .

또한 옵션 처리와 관련하여 올바른 옵션 중 하나를 모범 사례 중 하나로 추측하는 것이 좋습니다. 나는 Git에서 그것을 배웠고 이제는 내 프로젝트에서 같은 것을 사용합니다. 사용자가 알 수없는 명령 행 옵션을 입력하면 기본적으로 Damerau–Levenshtein 거리를 사용하여 최상의 일치 항목을 인쇄합니다.

나는 당신 이 예로서 사용할 수 있는 작은 기사를 썼습니다 .

그것이 도움이되기를 바랍니다 🙂

답변

분명히 cout << 또는 printf () 코드 에 홀 페이지를 작성하는 것은 번거 롭습니다. 특히 단락을 변경하고 다시 채워야하는 경우 더욱 그렇습니다. 따라서 텍스트를 보다 쉽게 ​​형식화 할 수있는 emacs 와 같은 별도의 파일에서 해당 텍스트를 편집하는 것이 좋습니다 .

그런 다음 다음 sed 스크립트를 사용하여 해당 텍스트 파일을 유효한 C 헤더 파일로 변환 할 수 있습니다 .

s/\"/\\\"/g
s/$/\\n"/
s/^/"/
1i\
const char *helpStr =
$a\
;

그런 다음 헤더 파일을 소스 코드 에 # include- 하면 다음을 사용하여 간단히 텍스트를 작성할 수 있습니다.

cout << helpStr;

답변