ນີ້ແມ່ນຄໍາສັ່ງ perlpodstyle ທີ່ສາມາດດໍາເນີນການໄດ້ໃນ OnWorks ຜູ້ໃຫ້ບໍລິການໂຮດຕິ້ງຟຣີໂດຍໃຊ້ຫນຶ່ງໃນຫຼາຍບ່ອນເຮັດວຽກອອນໄລນ໌ຂອງພວກເຮົາເຊັ່ນ Ubuntu Online, Fedora Online, Windows online emulator ຫຼື MAC OS online emulator
ໂຄງການ:
NAME
perlpodstyle - ຄູ່ມືແບບ Perl POD
ລາຍລະອຽດ
ເຫຼົ່ານີ້ແມ່ນຄໍາແນະນໍາທົ່ວໄປສໍາລັບວິທີການຂຽນເອກະສານ POD ສໍາລັບ Perl scripts ແລະ
ໂມດູນ, ອີງຕາມຄໍາແນະນໍາທົ່ວໄປສໍາລັບການຂຽນຫນ້າ UNIX man ທີ່ດີ. ທັງໝົດນີ້
ແນ່ນອນ, ຄໍາແນະນໍາແມ່ນທາງເລືອກ, ແຕ່ການປະຕິບັດຕາມພວກມັນຈະເຮັດໃຫ້ເອກະສານຂອງເຈົ້າມີຫຼາຍຂຶ້ນ
ສອດຄ່ອງກັບເອກະສານອື່ນໆໃນລະບົບ.
ຊື່ຂອງໂຄງການທີ່ຖືກບັນທຶກໄວ້ແມ່ນໄດ້ຮັບການຂຽນແບບທໍາມະດາເປັນຕົວຫນາ (ໃຊ້ B<>)
ບ່ອນໃດກໍຕາມທີ່ມັນເກີດຂຶ້ນ, ເຊັ່ນດຽວກັນກັບທາງເລືອກຂອງໂຄງການທັງຫມົດ. ການໂຕ້ຖຽງຄວນຂຽນເປັນຕົວອຽງ
(I<>). ຊື່ຟັງຊັນແມ່ນຂຽນຕາມປະເພນີເປັນຕົວອຽງ; ຖ້າທ່ານຂຽນຫນ້າທີ່ເປັນ
ຟັງຊັນ(), Pod::Man will take care of this for you. ລະຫັດຕົວຫນັງສືຫຼືຄໍາສັ່ງຄວນຈະເປັນ
ໃນ C<>. ການອ້າງອີງໃສ່ຫນ້າຜູ້ຊາຍອື່ນໆຄວນຈະຢູ່ໃນຮູບແບບ "manpage(section)" ຫຼື
“ລ ", ແລະ Pod::Man ອັດຕະໂນມັດຈະຈັດຮູບແບບທີ່ເຫມາະສົມ
ຮູບແບບທີສອງ, ດ້ວຍ L<>, ຖືກໃຊ້ເພື່ອຮ້ອງຂໍໃຫ້ຜູ້ຈັດຮູບແບບ POD ສ້າງລິ້ງໄປຫາໜ້າຜູ້ຊາຍ
ຖ້າເປັນໄປໄດ້. ເປັນຂໍ້ຍົກເວັ້ນ, ປົກກະຕິຫນຶ່ງຈະຍົກເວັ້ນພາກສ່ວນໃນເວລາທີ່ອ້າງອີງໃສ່ໂມດູນ
ເອກະສານເນື່ອງຈາກມັນບໍ່ຊັດເຈນວ່າເອກະສານຂອງໂມດູນພາກໃດຈະຢູ່ໃນ; ໃຊ້
“ລ " ສໍາລັບການອ້າງອີງໂມດູນແທນ.
ການອ້າງອິງເຖິງໂປລແກລມຫຼືຫນ້າທີ່ອື່ນແມ່ນປົກກະຕິໃນຮູບແບບການອ້າງອີງຫນ້າ man
ດັ່ງນັ້ນເຄື່ອງມືການອ້າງອິງຂ້າມສາມາດໃຫ້ຜູ້ໃຊ້ມີການເຊື່ອມຕໍ່ແລະຄ້າຍຄືກັນ. ມັນ
ເປັນໄປໄດ້ເພື່ອ overdo ນີ້, ເຖິງແມ່ນວ່າ, ສະນັ້ນລະມັດລະວັງບໍ່ໃຫ້ clutter ເອກະສານຂອງທ່ານເກີນໄປ
markup ຫຼາຍ. ການອ້າງອິງເຖິງໂຄງການອື່ນໆທີ່ບໍ່ໄດ້ຖືກມອບໃຫ້ເປັນການອ້າງອີງຫນ້າ man
ຄວນຈະຖືກຫຸ້ມຢູ່ໃນ B<>.
ຫົວຂໍ້ຕົ້ນຕໍຄວນຈະຖືກກໍານົດໂດຍໃຊ້ຄໍາສັ່ງ "=head1", ແລະເປັນປະຫວັດສາດ
ຂຽນໃນຮູບແບບ ALL UPPER CASE ທີ່ຫນ້າປະຫລາດໃຈຫຼາຍ; ນີ້ບໍ່ແມ່ນການບັງຄັບ, ແຕ່ວ່າມັນແມ່ນ
ແນະນໍາຢ່າງແຂງແຮງເພື່ອໃຫ້ພາກສ່ວນຕ່າງໆມີຊື່ທີ່ສອດຄ່ອງກັນໃນທົ່ວຊອບແວທີ່ແຕກຕ່າງກັນ
ຊຸດ. ສ່ວນຫົວເລັກນ້ອຍອາດຈະຖືກລວມເຂົ້າໂດຍໃຊ້ "=head2", ແລະໂດຍທົ່ວໄປແລ້ວໃນກໍລະນີປະສົມ.
ພາກສ່ວນມາດຕະຖານຂອງໜ້າຄູ່ມືແມ່ນ:
NAME
ພາກບັງຄັບ; ຄວນເປັນລາຍການທີ່ຂັ້ນດ້ວຍເຄື່ອງໝາຍຈຸດຂອງໂປຣແກຣມ ຫຼືຟັງຊັນ
ເອກະສານໂດຍຫນ້າ POD ນີ້, ເຊັ່ນ:
foo, bar - ໂຄງການທີ່ຈະເຮັດບາງສິ່ງບາງຢ່າງ
ຕົວດັດສະນີຫນ້າຄູ່ມືມັກຈະເລືອກທີ່ສຸດກ່ຽວກັບຮູບແບບຂອງພາກນີ້, ດັ່ງນັ້ນ
ຢ່າເອົາຫຍັງໃສ່ໃນມັນຍົກເວັ້ນເສັ້ນນີ້. ທຸກໆໂຄງການຫຼືຫນ້າທີ່ບັນທຶກໂດຍ
ໜ້າ POD ນີ້ຄວນຈະຖືກຈັດໃສ່ໃນລາຍການ, ແຍກດ້ວຍເຄື່ອງໝາຍຈຸດ ແລະ ຍະຫວ່າງ. ສໍາລັບໂມດູນ Perl,
ພຽງແຕ່ໃຫ້ຊື່ໂມດູນ. A dash ດຽວ, ແລະພຽງແຕ່ dash ດຽວ, ຄວນແຍກອອກ
ບັນຊີລາຍຊື່ຂອງບັນດາໂຄງການຫຼືຫນ້າທີ່ຈາກຄໍາອະທິບາຍ. ຢ່າໃຊ້ເຄື່ອງໝາຍໃດໆເຊັ່ນ C<>
ຫຼື B<> ບ່ອນໃດກໍໄດ້ໃນແຖວນີ້. ຟັງຊັນບໍ່ຄວນມີຄຸນສົມບັດ "()" ຫຼື
ມັກ. ຄໍາອະທິບາຍຄວນຈະເຫມາະສົມໃນເສັ້ນດຽວ, ເຖິງແມ່ນວ່າໂຄງການຜູ້ຊາຍ
ແທນທີ່ dash ດ້ວຍສອງສາມແຖບ.
ສະຫຼຸບສັງລວມ
ສະຫຼຸບການນຳໃຊ້ສັ້ນໆສຳລັບບັນດາໂຄງການ ແລະໜ້າທີ່. ພາກນີ້ແມ່ນບັງຄັບສໍາລັບ
ພາກທີ 3 ຫນ້າ. ສໍາລັບເອກະສານໂມດູນ Perl, ປົກກະຕິແລ້ວມັນສະດວກທີ່ຈະມີ
ເນື້ອໃນຂອງພາກນີ້ແມ່ນເປັນຕັນ verbatim ສະແດງໃຫ້ເຫັນບາງ (ໂດຍຫຍໍ້) ຕົວຢ່າງຂອງປົກກະຕິ
ວິທີການທີ່ໂມດູນຖືກນໍາໃຊ້.
ລາຍລະອຽດ
ລາຍລະອຽດຂະຫຍາຍແລະການສົນທະນາຂອງໂຄງການຫຼືຫນ້າທີ່, ຫຼືຮ່າງກາຍຂອງ
ເອກະສານສໍາລັບຫນ້າຜູ້ຊາຍທີ່ບັນທຶກບາງສິ່ງບາງຢ່າງອື່ນ. ຖ້າຍາວໂດຍສະເພາະ, ມັນ
ເປັນຄວາມຄິດທີ່ດີທີ່ຈະແຍກມັນອອກເປັນສ່ວນຍ່ອຍ "=head2" ຄໍາສັ່ງເຊັ່ນ:
=head2 ການນໍາໃຊ້ປົກກະຕິ
=head2 ຄຸນສົມບັດຂັ້ນສູງ
=head2 ການຂຽນໄຟລ໌ການຕັ້ງຄ່າ
ຫຼືອັນໃດກໍໄດ້ທີ່ເໝາະສົມກັບເອກະສານຂອງເຈົ້າ.
ສໍາລັບໂມດູນ, ໂດຍທົ່ວໄປແລ້ວນີ້ແມ່ນບ່ອນທີ່ເອກະສານຂອງການໂຕ້ຕອບທີ່ສະຫນອງໃຫ້ໂດຍ
ໂມດູນໄປ, ປົກກະຕິແລ້ວໃນຮູບແບບຂອງບັນຊີລາຍຊື່ທີ່ມີ "=item" ສໍາລັບແຕ່ລະການໂຕ້ຕອບ.
ຂຶ້ນຢູ່ກັບວ່າມີການໂຕ້ຕອບຫຼາຍປານໃດ, ທ່ານອາດຈະຕ້ອງການເອົາເອກະສານນັ້ນໃສ່
ແຍກຕ່າງຫາກວິທີການ, ຫນ້າທີ່, ວິທີການຂອງຫ້ອງຮຽນ, ຫຼື INSTANCE METHODS ແທນ ແລະ
ບັນທຶກພາກສ່ວນ DESCRIPTION ສໍາລັບພາບລວມ.
OPTIONS
ລາຍລະອຽດຂອງແຕ່ລະຕົວເລືອກເສັ້ນຄໍາສັ່ງທີ່ປະຕິບັດໂດຍໂຄງການ. ນີ້
ຄວນແຍກອອກຈາກຄຳອະທິບາຍສຳລັບການນຳໃຊ້ຕົວແຍກເຊັ່ນ Pod::Usage. ນີ້
ປົກກະຕິແລ້ວແມ່ນນໍາສະເຫນີເປັນບັນຊີລາຍຊື່, ແຕ່ລະທາງເລືອກເປັນ "=item". ສະເພາະ
ສະຕຣິງທາງເລືອກຄວນຈະຖືກຫຸ້ມຢູ່ໃນ B<>. ຄ່າໃດນຶ່ງທີ່ຕົວເລືອກໃຊ້ຄວນຈະເປັນ
ຫຸ້ມຢູ່ໃນ I<>. ຕົວຢ່າງ, ພາກສ່ວນສໍາລັບທາງເລືອກ --ພາກ=ຕໍ່ໄປ ຈະ
ແນະນຳດ້ວຍ:
=ລາຍການ B<--section>=I
ທາງເລືອກທີ່ຄ້າຍຄືກັນ (ເຊັ່ນທັງຮູບແບບສັ້ນແລະຍາວ) ຖືກແຍກອອກດ້ວຍເຄື່ອງຫມາຍຈຸດແລະ a
space ຢູ່ໃນແຖວ "=item" ດຽວກັນ, ຫຼືເລືອກລາຍການເປັນລາຍການຂອງຕົນເອງທີ່ມີ a
ອ້າງເຖິງຊື່ canonical. ສໍາລັບຕົວຢ່າງ, ນັບຕັ້ງແຕ່ --ພາກ ຍັງສາມາດຂຽນເປັນ
-s, ຂ້າງເທິງຈະເປັນ:
=ລາຍການ B<-s> I , B<--section>=I
ແນະນຳໃຫ້ຂຽນຕົວເລືອກສັ້ນກ່ອນ ເພາະມັນອ່ານງ່າຍກວ່າ. ຍາວ
ທາງເລືອກແມ່ນຍາວພຽງພໍທີ່ຈະແຕ້ມຕາກັບມັນຢ່າງໃດກໍຕາມແລະທາງເລືອກສັ້ນສາມາດຖ້າບໍ່ດັ່ງນັ້ນ
ໄດ້ຮັບການສູນເສຍໃນສິ່ງລົບກວນສາຍຕາ.
ສົ່ງຄືນ VALUE
ສິ່ງທີ່ໂຄງການຫຼືຫນ້າທີ່ກັບຄືນມາ, ຖ້າປະສົບຜົນສໍາເລັດ. ພາກສ່ວນນີ້ສາມາດຖືກຍົກເວັ້ນສໍາລັບ
ໂປລແກລມທີ່ມີລະຫັດອອກທີ່ຊັດເຈນບໍ່ສໍາຄັນ, ໃຫ້ພວກເຂົາກັບຄືນ 0 ໃນຄວາມສໍາເລັດ
ແລະບໍ່ແມ່ນສູນຂອງຄວາມລົ້ມເຫລວຕາມມາດຕະຖານ. ມັນຄວນຈະມີຢູ່ສະເຫມີສໍາລັບຫນ້າທີ່.
ສໍາລັບໂມດູນ, ມັນອາດຈະເປັນປະໂຫຍດທີ່ຈະສະຫຼຸບມູນຄ່າກັບຄືນຈາກການໂຕ້ຕອບຂອງໂມດູນ
ທີ່ນີ້, ຫຼືມັນອາດຈະເປັນປະໂຫຍດກວ່າທີ່ຈະປຶກສາຫາລືກ່ຽວກັບຄ່າກັບຄືນແຍກຕ່າງຫາກໃນ
ເອກະສານຂອງແຕ່ລະຫນ້າທີ່ຫຼືວິທີການທີ່ໂມດູນໃຫ້.
ຄວາມຜິດພາດ
ຂໍ້ຍົກເວັ້ນ, ລະຫັດກັບຄືນຄວາມຜິດພາດ, ສະຖານະການອອກ, ແລະການຕັ້ງຄ່າ errno. ປົກກະຕິແລ້ວໃຊ້ສໍາລັບ
ເອກະສານການທໍາງານຫຼືໂມດູນ; ເອກະສານໂຄງການໃຊ້ DIAGNOSTICS ແທນ. ໄດ້
ກົດລະບຽບທົ່ວໄປແມ່ນຄວາມຜິດພາດທີ່ພິມອອກເປັນ "STDOUT" ຫຼື "STDERR" ແລະມີຈຸດປະສົງເພື່ອ
ຜູ້ໃຊ້ສຸດທ້າຍຖືກບັນທຶກໄວ້ໃນ DIAGNOSTICS ໃນຂະນະທີ່ຂໍ້ຜິດພາດຜ່ານພາຍໃນໄປຫາການໂທ
ໂປລແກລມແລະມີຈຸດປະສົງສໍາລັບນັກຂຽນໂປລແກລມອື່ນແມ່ນບັນທຶກໄວ້ໃນ ERRORS. ໃນເວລາທີ່ເອກະສານ
ຟັງຊັນທີ່ກໍານົດ errno, ບັນຊີລາຍຊື່ເຕັມຂອງຄ່າ errno ທີ່ເປັນໄປໄດ້ຄວນໄດ້ຮັບການໃຫ້
ທີ່ນີ້.
ທິດສະດີວິທະຍາ
ຂໍ້ຄວາມທີ່ເປັນໄປໄດ້ທັງຫມົດທີ່ໂຄງການສາມາດພິມອອກແລະສິ່ງທີ່ພວກເຂົາຫມາຍຄວາມວ່າ. ເຈົ້າອາດຈະຕ້ອງການ
ປະຕິບັດຕາມຮູບແບບເອກະສານດຽວກັນກັບເອກະສານ Perl; ເບິ່ງ perldiag(1) ສໍາລັບ
ລາຍລະອຽດເພີ່ມເຕີມ (ແລະເບິ່ງແຫຼ່ງ POD ເຊັ່ນກັນ).
ຖ້າເປັນໄປໄດ້, ກະລຸນາໃສ່ລາຍລະອຽດກ່ຽວກັບສິ່ງທີ່ຜູ້ໃຊ້ຄວນເຮັດເພື່ອແກ້ໄຂຂໍ້ຜິດພາດ;
ບັນທຶກຄວາມຜິດພາດທີ່ຊີ້ບອກວ່າ "buffer ວັດສະດຸປ້ອນແມ່ນນ້ອຍເກີນໄປ" ໂດຍບໍ່ມີການບອກ
ຜູ້ໃຊ້ວິທີການເພີ່ມຂະຫນາດຂອງ input buffer (ຫຼືຢ່າງຫນ້ອຍບອກເຂົາເຈົ້າວ່າມັນ
ເປັນໄປບໍ່ໄດ້) ບໍ່ມີປະໂຫຍດຫຼາຍ.
ຕົວຢ່າງ
ໃຫ້ຕົວຢ່າງບາງການນຳໃຊ້ໂປຣແກຣມ ຫຼືຟັງຊັນ. ບໍ່ skimp; ຜູ້ໃຊ້ມັກຈະຊອກຫາສິ່ງນີ້
ສ່ວນທີ່ເປັນປະໂຫຍດທີ່ສຸດຂອງເອກະສານ. ຕົວຢ່າງແມ່ນໂດຍທົ່ວໄປແລ້ວເປັນ
ວັກ verbatim.
ບໍ່ພຽງແຕ່ນໍາສະເຫນີຕົວຢ່າງໂດຍບໍ່ມີການອະທິບາຍສິ່ງທີ່ມັນເຮັດ. ເພີ່ມສັ້ນ
ວັກທີ່ເວົ້າວ່າສິ່ງທີ່ຕົວຢ່າງຈະເຮັດສາມາດເພີ່ມມູນຄ່າຂອງຕົວຢ່າງ
ຢ່າງມະຫາສານ.
ENVIRONMENT
ຕົວແປສະພາບແວດລ້ອມທີ່ໂຄງການເປັນຫ່ວງເປັນໄຍ, ປົກກະຕິແລ້ວນໍາສະເຫນີເປັນບັນຊີລາຍຊື່ການນໍາໃຊ້
"=over", "=item", ແລະ "=back". ຍົກຕົວຢ່າງ:
= ຫຼາຍກວ່າ 6
=ລາຍການໜ້າຫຼັກ
ໃຊ້ເພື່ອກໍານົດໄດເລກະທໍລີເຮືອນຂອງຜູ້ໃຊ້. F<.forc> ໃນນີ້
ໄດເລກະທໍລີຖືກອ່ານສໍາລັບລາຍລະອຽດການຕັ້ງຄ່າ, ຖ້າມັນມີຢູ່.
=ກັບຄືນ
ເນື່ອງຈາກຕົວແປສະພາບແວດລ້ອມແມ່ນປົກກະຕິແລ້ວຢູ່ໃນຕົວພິມໃຫຍ່ທັງຫມົດ, ບໍ່ມີການພິເສດເພີ່ມເຕີມ
ໂດຍທົ່ວໄປແລ້ວການຈັດຮູບແບບແມ່ນຈໍາເປັນ; ພວກເຂົາເຈົ້າກໍາລັງ glaring ພຽງພໍທີ່ມັນເປັນ.
ເອກະສານ
ໄຟລ໌ທັງຫມົດທີ່ໃຊ້ໂດຍໂຄງການຫຼືຫນ້າທີ່, ປົກກະຕິແລ້ວນໍາສະເຫນີເປັນບັນຊີລາຍຊື່, ແລະສິ່ງທີ່ມັນ
ໃຊ້ພວກມັນສໍາລັບ. ຊື່ໄຟລ໌ຄວນຖືກໃສ່ໃນ F<>. ມັນເປັນສິ່ງສໍາຄັນໂດຍສະເພາະກັບ
ໄຟລ໌ເອກະສານທີ່ອາດຈະຖືກແກ້ໄຂ.
ຂໍ້ຄວນລະວັງ
ສິ່ງທີ່ຕ້ອງເບິ່ງແຍງເປັນພິເສດ, ບາງຄັ້ງເອີ້ນວ່າ ຄຳເຕືອນ.
ບັກ
ສິ່ງທີ່ແຕກຫັກຫຼືພຽງແຕ່ເຮັດວຽກບໍ່ຖືກຕ້ອງ.
ຄວາມຕ້ອງການ
ແມງໄມ້ທີ່ທ່ານບໍ່ໄດ້ວາງແຜນທີ່ຈະແກ້ໄຂ. :-)
ຫມາຍເຫດ
ຄໍາຄິດເຫັນອື່ນໆ.
ຜູ້ຂຽນ
ໃຜຂຽນມັນ (ໃຊ້ AUTHORS ສໍາລັບຫຼາຍໆຄົນ). ມັນເປັນຄວາມຄິດທີ່ດີທີ່ຈະລວມເອົາຂອງທ່ານ
ທີ່ຢູ່ອີເມລປະຈຸບັນ (ຫຼືບາງທີ່ຢູ່ອີເມລທີ່ບົດລາຍງານ bug ຄວນຈະຖືກສົ່ງໄປ) ຫຼື
ບາງຂໍ້ມູນຕິດຕໍ່ອື່ນໆເພື່ອໃຫ້ຜູ້ໃຊ້ມີວິທີການຕິດຕໍ່ກັບເຈົ້າ. ຈື່ໄວ້
ເອ ກະ ສານ ຂອງ ໂຄງ ການ ທີ່ ມີ ແນວ ໂນ້ມ ທີ່ ຈະ roam ທໍາ ມະ ຊາດ ສໍາ ລັບ ການ ໄກ ດົນ ກວ່າ ທີ່ ທ່ານ ຄາດ ຫວັງ ແລະ
ເລືອກວິທີການຕິດຕໍ່ທີ່ອາດຈະຢູ່ໄດ້.
ປະຫວັດຄວາມເປັນ
ບັນດາໂຄງການທີ່ມາຈາກແຫຼ່ງອື່ນໆບາງຄັ້ງກໍ່ມີອັນນີ້. ບາງຄົນຮັກສາ ກ
ບັນທຶກການດັດແກ້ຢູ່ທີ່ນີ້, ແຕ່ມັນມັກຈະຍາວແລະຖືກຮັກສາໄວ້ດີກວ່າ
ໄຟລ໌ແຍກຕ່າງຫາກ.
ລິຂະສິດ ແລະໃບອະນຸຍາດ
ສໍາລັບລິຂະສິດ
ລິຂະສິດ YEAR ຊື່ຂອງເຈົ້າ
(ບໍ່, (C) ແມ່ນບໍ່ຈໍາເປັນ. ບໍ່, "ສະຫງວນສິດທັງຫມົດ" ແມ່ນບໍ່ຈໍາເປັນ.)
ສໍາລັບການອອກໃບອະນຸຍາດວິທີທີ່ງ່າຍທີ່ສຸດແມ່ນການນໍາໃຊ້ໃບອະນຸຍາດດຽວກັນກັບ Perl ຕົວຂອງມັນເອງ:
ຫ້ອງສະຫມຸດນີ້ແມ່ນຊອບແວຟຣີ; ເຈົ້າອາດຈະແຈກຢາຍມັນຄືນໃໝ່ ແລະ/ຫຼື
ປັບປຸງແກ້ໄຂພາຍໃຕ້ເງື່ອນໄຂດຽວກັນກັບ Perl ຕົວຂອງມັນເອງ.
ນີ້ເຮັດໃຫ້ມັນງ່າຍສໍາລັບຄົນທີ່ຈະໃຊ້ໂມດູນຂອງທ່ານກັບ Perl. ໃຫ້ສັງເກດວ່າການອອກໃບອະນຸຍາດນີ້
ຕົວຢ່າງບໍ່ແມ່ນການຮັບຮອງຫຼືຄວາມຕ້ອງການ, ແນ່ນອນເຈົ້າມີອິດສະຫຼະທີ່ຈະເລືອກ
ໃບອະນຸຍາດໃດໆ.
ເບິ່ງຍັງ
ຫນ້າຜູ້ຊາຍອື່ນເພື່ອກວດສອບການອອກ, ຄື ຜູ້ຊາຍ(1) ຜູ້ຊາຍ(7) ງູເຫົ່າ(8), ຫຼື catman(8).
ໂດຍປົກກະຕິແລ້ວ ລາຍຊື່ໜ້າຜູ້ຊາຍທີ່ແຍກກັນດ້ວຍເຄື່ອງໝາຍຈຸດ, ຫຼືຫຍໍ້ໜ້າໃຫ້
ຊື່ຂອງວຽກອ້າງອີງ. ຜູ້ອ້າງອີງຫນ້າ, ຖ້າພວກເຂົາໃຊ້ມາດຕະຖານ
ແບບຟອມ "name(section)" , ບໍ່ຈໍາເປັນຕ້ອງໃສ່ໃນ L<> (ເຖິງແມ່ນວ່າມັນຖືກແນະນໍາ),
ແຕ່ສິ່ງອື່ນໆໃນພາກນີ້ອາດຈະເປັນເວລາທີ່ເຫມາະສົມ.
ຖ້າແພັກເກັດມີລາຍຊື່ທາງໄປສະນີ, ໃຫ້ໃສ່ URL ຫຼືຄໍາແນະນໍາການສະໝັກຢູ່ບ່ອນນີ້.
ຖ້າຊຸດມີເວັບໄຊທ໌, ໃຫ້ໃສ່ URL ທີ່ນີ້.
ເອກະສານຂອງຫໍສະໝຸດວັດຖຸ ຫຼືໂມດູນອາດຈະຕ້ອງການໃຊ້ CONSTRUCTORS ແລະ
ພາກສ່ວນວິທີການ, ຫຼື CLASS METHODS ແລະ INSTANCE METHODS, ສໍາລັບລາຍລະອຽດ
ເອກະສານຂອງພາກສ່ວນຂອງຫ້ອງສະຫມຸດແລະບັນທຶກພາກສ່ວນ DESCRIPTION ສໍາລັບ an
ພາບລວມ. ໂມດູນຂະຫນາດໃຫຍ່ທີ່ມີການໂຕ້ຕອບຟັງຊັນອາດຈະຕ້ອງການໃຊ້ FUNCTIONS ສໍາລັບຄ້າຍຄືກັນ
ເຫດຜົນ. ບາງຄົນໃຊ້ OVERVIEW ເພື່ອສະຫຼຸບຄໍາອະທິບາຍຖ້າມັນຂ້ອນຂ້າງຍາວ.
ການຈັດລໍາດັບພາກສ່ວນແຕກຕ່າງກັນ, ເຖິງແມ່ນວ່າ NAME ຈະຕ້ອງເປັນພາກສ່ວນທໍາອິດສະເໝີ (ທ່ານຈະແຕກບາງສ່ວນ
man page systems ຖ້າບໍ່ດັ່ງນັ້ນ), ແລະ NAME, SYNOPSIS, DESCRIPTION, ແລະ Options ໂດຍທົ່ວໄປແລ້ວ.
ເກີດຂຶ້ນຄັ້ງທໍາອິດແລະໃນລໍາດັບນັ້ນຖ້າຫາກວ່າປະຈຸບັນ. ໂດຍທົ່ວໄປ, SEE ALSO, AUTHOR, ແລະຄ້າຍຄືກັນ
ອຸປະກອນການຄວນຈະຖືກປະໄວ້ສໍາລັບການສຸດທ້າຍ. ບາງລະບົບຍັງຍ້າຍຄຳເຕືອນ ແລະບັນທຶກໃຫ້ຢູ່ຕໍ່ໄປ. ໄດ້
ຄໍາສັ່ງທີ່ໃຫ້ຂ້າງເທິງຄວນຈະສົມເຫດສົມຜົນສໍາລັບຈຸດປະສົງສ່ວນໃຫຍ່.
ບາງລະບົບໃຊ້ CONFORMING TO ເພື່ອສັງເກດການປະຕິບັດຕາມມາດຕະຖານທີ່ກ່ຽວຂ້ອງ ແລະ MT-LEVEL ກັບ
ບັນທຶກຄວາມປອດໄພສໍາລັບການນໍາໃຊ້ໃນໂຄງການ threaded ຫຼືຕົວຈັດການສັນຍານ. ຫົວຂໍ້ເຫຼົ່ານີ້ແມ່ນ
ເປັນປະໂຫຍດຕົ້ນຕໍໃນເວລາທີ່ບັນທຶກພາກສ່ວນຂອງຫ້ອງສະຫມຸດ C.
ສຸດທ້າຍ, ເປັນຫມາຍເຫດທົ່ວໄປ, ພະຍາຍາມບໍ່ໃຊ້ຈໍານວນຫຼາຍເກີນໄປຂອງເຄື່ອງຫມາຍ. ຕາມເອກະສານ
ທີ່ນີ້ແລະໃນ Pod::ຜູ້ຊາຍ, ທ່ານສາມາດອອກຈາກຕົວແປ Perl ໄດ້ຢ່າງປອດໄພ, ຊື່ຫນ້າທີ່, ຫນ້າຜູ້ຊາຍ
ການອ້າງອິງ, ແລະສິ່ງທີ່ຄ້າຍຄື unadorned ໂດຍ markup ແລະນັກແປ POD ຈະຄິດອອກ
ສໍາລັບທ່ານ. ນີ້ເຮັດໃຫ້ມັນງ່າຍຂຶ້ນຫຼາຍທີ່ຈະແກ້ໄຂເອກະສານຕໍ່ມາ. ໃຫ້ສັງເກດວ່າຈໍານວນຫຼາຍ
ຜູ້ແປທີ່ມີຢູ່ແລ້ວຈະເຮັດຜິດກັບທີ່ຢູ່ອີເມວເມື່ອຫໍ່ດ້ວຍ L<>, ດັ່ງນັ້ນ
ຢ່າເຮັດແນວນັ້ນ.
ໃຊ້ perlpodstyle ອອນໄລນ໌ໂດຍໃຊ້ບໍລິການ onworks.net
