어떤 사람이 여러 배포 스크립트를 작성하고 있다고 상상해 보세요.
이러한 셸 스크립트는 주석이 많이 달렸고 연결되어 있으며 사람이 읽을 수 있도록 설계되었습니다.
예를 들어, README.md 또는 INSTALL.md로 변환하여 저장소 친화적으로 만드는 것이 편리하지 않습니까?
왜 이런 일을 할 수 있습니까? 첫째, 중복되는 부분이 많을 수 있는 중복된 노력을 피할 수 있습니다. 이것도 어울리겠다단일 진실 원칙
답변1
스크립트에서 보다 일반적인 문서 대신 이 문서를 사용하면 #
다른 형태의 문서로 원활하게 전환할 수 있습니다. 예를 들어:
#!/bin/sh
case $1 in (*-h*)
sed '/^:/,/^DOC/!d;s/^:/cat/' "$0" |sh -s "$@"
exit;;esac
: <<DOC
Enter as many lines of documentation as you might need -
just don't begin any but the first with : or the last with DOC.
"Quotes are " fine - and $params can be expanded if you
don't quote the DOC delimiter.
DOC
... #shell script
... #more of same
: <<\DOC
- *Markdown Comment* -
- or you can quote the delimiter and be more
free to use `backquotes` or whatever you like.
You can mark the comments up in markdown
in the first place, and print them w/ `"$0" -h`.
DOC
바라보다여기 문서의 tldp 예제 19-2더 알아보기.
답변2
답변3
형식에 관계없이 프로그램의 복잡한 부분이 어떻게 작동하는지 설명하는 설명은 Readme 파일에 거의 나타나지 않습니다.
-h
호출 프로그램의 출력을 readme 파일이나 페이지로 사용하는 일부 패키지가 이미 있습니다 man
. 예를 들어 GNU사람들을 도와주세요예를 들면 이렇게 합니다.
IMO, 쉘 스크립트가 너무 복잡해져서 광범위한 문서(사용법이나 작업 설명)가 필요한 경우 Python/Perl/Ruby로 다시 작성하는 것을 고려해야 합니다.
답변4
나에게는 스크립트의 소스 코드에서 직접 Markdown 문서를 생성하려는 것처럼 들립니다. 나에게 이것은 noweb과 매우 비슷해 보이지만 noweb은 (내가 아는 한) 마크다운을 문서 형식으로 지원하지 않습니다. 하지만 이에 대한 지원을 추가할 수도 있습니다.