ในบทความแรกในชุดนี้ คุณได้สร้างสคริปต์ Bash แบบบรรทัดเดียวขนาดเล็กมาก และสำรวจสาเหตุของการสร้างเชลล์สคริปต์และสาเหตุที่เป็นตัวเลือกที่มีประสิทธิภาพมากที่สุดสำหรับผู้ดูแลระบบ แทนที่จะเป็นโปรแกรมที่คอมไพล์แล้ว
ในบทความที่สองนี้ คุณจะเริ่มสร้างเทมเพลตสคริปต์ทุบตีที่สามารถใช้เป็นจุดเริ่มต้นสำหรับสคริปต์ทุบตีอื่นๆ เทมเพลตจะประกอบด้วยสิ่งอำนวยความสะดวกของวิธีใช้ คำชี้แจงสิทธิ์การใช้งาน ฟังก์ชันง่ายๆ จำนวนหนึ่ง และตรรกะบางอย่างเพื่อจัดการกับตัวเลือกเหล่านั้นและอื่นๆ ที่อาจจำเป็นสำหรับสคริปต์ที่จะอิงตามเทมเพลตนี้
ทำไมต้องสร้างเทมเพลต
เช่นเดียวกับระบบอัตโนมัติโดยทั่วไป แนวคิดเบื้องหลังการสร้างเทมเพลตคือการเป็น "ผู้ดูแลระบบที่ขี้เกียจ" เทมเพลตประกอบด้วยส่วนประกอบพื้นฐานที่คุณต้องการในสคริปต์ทั้งหมดของคุณ ประหยัดเวลาเมื่อเทียบกับการเพิ่มองค์ประกอบเหล่านั้นลงในสคริปต์ใหม่ทุกรายการ และทำให้ง่ายต่อการเริ่มสคริปต์ใหม่
แม้ว่าการใส่คำสั่ง Bash ของบรรทัดคำสั่งบางคำสั่งเข้าด้วยกันเป็นไฟล์และทำให้สามารถเรียกใช้งานได้อาจเป็นเรื่องที่น่าดึงดูดใจ แต่ก็สามารถต่อต้านได้ในระยะยาว โปรแกรม Bash ที่เขียนมาอย่างดีและมีความคิดเห็นดีพร้อมความช่วยเหลือและความสามารถในการยอมรับตัวเลือกบรรทัดคำสั่งเป็นจุดเริ่มต้นที่ดีสำหรับผู้ดูแลระบบที่ดูแลโปรแกรม ซึ่งรวมถึงโปรแกรมที่ คุณ เขียนและบำรุงรักษา
ข้อกำหนด
คุณควรสร้างชุดข้อกำหนดสำหรับทุกโครงการที่คุณทำเสมอ ซึ่งรวมถึงสคริปต์ แม้ว่าจะเป็นรายการง่ายๆ ที่มีเพียงสองหรือสามรายการเท่านั้น ฉันเคยมีส่วนร่วมในหลายโครงการที่ล้มเหลวโดยสิ้นเชิงหรือไม่สามารถตอบสนองความต้องการของลูกค้าได้ โดยปกติแล้วจะเนื่องมาจากไม่มีข้อกำหนดหรือข้อเขียนที่ไม่ค่อยดี
ข้อกำหนดสำหรับเทมเพลต Bash นี้ค่อนข้างง่าย:
- สร้างเทมเพลตที่สามารถใช้เป็นจุดเริ่มต้นสำหรับโครงการการเขียนโปรแกรม Bash ในอนาคต
- เทมเพลตควรเป็นไปตามแนวทางปฏิบัติในการเขียนโปรแกรม Bash มาตรฐาน
- ต้องมี:
- ส่วนหัวที่สามารถใช้เพื่ออธิบายการทำงานของโปรแกรมและบันทึกการเปลี่ยนแปลง
- คำชี้แจงสิทธิ์การใช้งาน
- ส่วนการทำงาน
- ฟังก์ชันช่วยเหลือ
- ฟังก์ชันสำหรับทดสอบว่าผู้ใช้โปรแกรมเป็น root หรือไม่
- วิธีการประเมินตัวเลือกบรรทัดคำสั่ง
โครงสร้างพื้นฐาน
สคริปต์ทุบตีพื้นฐานมีสามส่วน Bash ไม่มีวิธีกำหนดส่วนต่าง ๆ แต่ขอบเขตระหว่างส่วนนั้นมีความชัดเจน
- สคริปต์ทั้งหมดต้องขึ้นต้นด้วย shebang (#! ) และนี่จะต้องเป็นบรรทัดแรกในโปรแกรม Bash ใดๆ
- ส่วนฟังก์ชันต้องเริ่มหลัง shebang และก่อนเนื้อความของโปรแกรม เพื่อเป็นส่วนหนึ่งของความต้องการของฉันในการจัดทำเอกสารทุกอย่าง ฉันแสดงความคิดเห็นก่อนแต่ละฟังก์ชันพร้อมคำอธิบายสั้นๆ เกี่ยวกับสิ่งที่ตั้งใจจะทำ ฉันยังรวมความคิดเห็นไว้ในฟังก์ชันเพื่ออธิบายเพิ่มเติม โปรแกรมสั้นๆ ง่ายๆ อาจไม่ต้องการฟังก์ชัน
- ส่วนหลักของโปรแกรมจะอยู่หลังส่วนฟังก์ชัน นี่อาจเป็นคำสั่ง Bash เดียวหรือหลายพันบรรทัด หนึ่งในโปรแกรมของฉันมีโค้ดน้อยกว่า 200 บรรทัดโดยไม่นับความคิดเห็น โปรแกรมเดียวกันนั้นมีความคิดเห็นมากกว่า 600 บรรทัด
นั่นคือทั้งหมดที่มี—เพียงสามส่วนในโครงสร้างของโปรแกรม Bash ใดๆ
ความคิดเห็นชั้นนำ
ฉันมักจะเพิ่มมากกว่านี้ด้วยเหตุผลหลายประการ อันดับแรก ฉันเพิ่มความคิดเห็นสองสามส่วนทันทีหลังจาก shebang ส่วนความคิดเห็นเหล่านี้เป็นทางเลือก แต่ฉันพบว่ามีประโยชน์มาก
ส่วนความคิดเห็นแรกคือชื่อโปรแกรมและคำอธิบายและประวัติการเปลี่ยนแปลง ฉันเรียนรู้รูปแบบนี้ขณะทำงานที่ IBM และมีวิธีการบันทึกการพัฒนาโปรแกรมในระยะยาวและการแก้ไขใดๆ ที่ใช้กับรูปแบบนี้ นี่เป็นจุดเริ่มต้นสำคัญในการจัดทำเอกสารโปรแกรมของคุณ
ส่วนความคิดเห็นที่สองคือคำชี้แจงลิขสิทธิ์และใบอนุญาต ฉันใช้ GPLv2 และดูเหมือนว่าจะเป็นคำสั่งมาตรฐานสำหรับโปรแกรมที่ได้รับอนุญาตภายใต้ GPLv2 หากคุณใช้ใบอนุญาตโอเพ่นซอร์สอื่น ไม่เป็นไร แต่ฉันขอแนะนำให้เพิ่มคำสั่งที่ชัดเจนในโค้ดเพื่อขจัดความสับสนที่อาจเกิดขึ้นเกี่ยวกับการให้สิทธิ์ใช้งาน บทความของ Scott Peterson ซอร์สโค้ดคือใบอนุญาต ช่วยอธิบายเหตุผลเบื้องหลังสิ่งนี้
ตอนนี้สคริปต์มีลักษณะดังนี้:
#!/bin/bash
################################################################################
# scriptTemplate #
# #
# Use this template as the beginning of a new program. Place a short #
# description of the script here. #
# #
# Change History #
# 11/11/2019 David Both Original code. This is a template for creating #
# new Bash shell scripts. #
# Add new history entries as needed. #
# #
# #
################################################################################
################################################################################
################################################################################
# #
# Copyright (C) 2007, 2019 David Both #
# LinuxGeek46@both.org #
# #
# This program is free software; you can redistribute it and/or modify #
# it under the terms of the GNU General Public License as published by #
# the Free Software Foundation; either version 2 of the License, or #
# (at your option) any later version. #
# #
# This program is distributed in the hope that it will be useful, #
# but WITHOUT ANY WARRANTY; without even the implied warranty of #
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the #
# GNU General Public License for more details. #
# #
# You should have received a copy of the GNU General Public License #
# along with this program; if not, write to the Free Software #
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA #
# #
################################################################################
################################################################################
################################################################################
echo "hello world!"
เรียกใช้โปรแกรมที่แก้ไขแล้วเพื่อตรวจสอบว่ายังใช้งานได้ตามที่คาดไว้
เกี่ยวกับการทดสอบ
ตอนนี้เป็นเวลาที่ดีที่จะพูดคุยเกี่ยวกับการทดสอบ
"ยังมีจุดบกพร่องอีกตัวอยู่เสมอ"
— กฎกีฏวิทยาไซเบอร์เนติกของลูบาร์สกี้
ลูบาร์สกี้—ใครก็ตาม— ถูกต้อง คุณจะไม่พบข้อบกพร่องทั้งหมดในโค้ดของคุณ สำหรับทุกจุดบกพร่องที่ฉันพบ ดูเหมือนว่าจะมีจุดบกพร่องอื่นๆ เกิดขึ้นเสมอ ซึ่งมักจะเกิดขึ้นในช่วงเวลาที่ไม่เหมาะสมอย่างยิ่ง
การทดสอบไม่ได้เป็นเพียงเกี่ยวกับโปรแกรมเท่านั้น นอกจากนี้ยังเกี่ยวกับการตรวจสอบด้วยว่าปัญหา ไม่ว่าจะเกิดจากฮาร์ดแวร์ ซอฟต์แวร์ หรือวิธีที่ผู้ใช้ค้นหาเพื่อทำลายสิ่งต่างๆ อย่างไม่มีที่สิ้นสุด ซึ่งน่าจะได้รับการแก้ไขแล้วจริงๆ สิ่งที่สำคัญไม่แพ้กัน การทดสอบก็คือการทำให้มั่นใจว่าโค้ดนั้นใช้งานง่ายและอินเทอร์เฟซนั้นเหมาะสมกับผู้ใช้
การปฏิบัติตามกระบวนการที่กำหนดไว้อย่างดีเมื่อเขียนและทดสอบเชลล์สคริปต์สามารถนำไปสู่ผลลัพธ์ที่สม่ำเสมอและมีคุณภาพสูง ขั้นตอนของฉันง่าย:
- สร้างแผนการทดสอบอย่างง่าย
- เริ่มการทดสอบตั้งแต่เริ่มต้นการพัฒนา
- ทำการทดสอบขั้นสุดท้ายเมื่อโค้ดเสร็จสมบูรณ์
- ย้ายไปใช้งานจริงและทดสอบเพิ่มเติม
แผนการทดสอบ
มีรูปแบบต่างๆ มากมายสำหรับแผนการทดสอบ ฉันได้ทำงานอย่างเต็มที่ตั้งแต่มีทุกอย่างอยู่ในหัวของฉัน โน้ตสองสามตัวที่จดไว้บนกระดาษ และไปจนถึงชุดแบบฟอร์มที่ซับซ้อนซึ่งต้องการคำอธิบายโดยละเอียดของการทดสอบแต่ละรายการ รหัสการทำงานใดที่จะทดสอบ สิ่งที่การทดสอบจะทำได้สำเร็จ และสิ่งที่ป้อนข้อมูลและผลลัพธ์ควรเป็นอย่างไร
การพูดในฐานะผู้ดูแลระบบที่เคยเป็นผู้ทดสอบ (แต่ไม่ใช่ตอนนี้) ฉันพยายามใช้พื้นที่ตรงกลาง การมีแผนการทดสอบข้อเขียนสั้นๆ อย่างน้อยจะช่วยให้มั่นใจได้ถึงความสม่ำเสมอจากการทดสอบหนึ่งครั้งไปยังครั้งต่อไป รายละเอียดที่คุณต้องการขึ้นอยู่กับว่าการพัฒนาและการทดสอบของคุณเป็นทางการเพียงใด
ตัวอย่างเอกสารแผนการทดสอบที่ฉันพบโดยใช้ Google นั้นซับซ้อนและมีไว้สำหรับองค์กรขนาดใหญ่ที่มีกระบวนการพัฒนาและทดสอบที่เป็นทางการมาก แม้ว่าแผนการทดสอบเหล่านั้นจะดีสำหรับผู้ที่มี "การทดสอบ" ในตำแหน่งงาน แต่ก็ใช้ไม่ได้กับสภาพการทำงานที่วุ่นวายและขึ้นอยู่กับเวลาของผู้ดูแลระบบ เช่นเดียวกับงานด้านอื่นๆ ส่วนใหญ่ ผู้ดูแลระบบจำเป็นต้องมีความคิดสร้างสรรค์ ต่อไปนี้คือรายการสั้นๆ ที่ควรพิจารณารวมถึงในแผนการทดสอบของคุณ ปรับเปลี่ยนให้เหมาะกับความต้องการของคุณ:
- ชื่อและคำอธิบายสั้นๆ ของซอฟต์แวร์ที่กำลังทดสอบ
- คำอธิบายคุณลักษณะซอฟต์แวร์ที่จะทดสอบ
- เงื่อนไขเริ่มต้นสำหรับการทดสอบแต่ละครั้ง
- หน้าที่ที่ต้องติดตามสำหรับการทดสอบแต่ละครั้ง
- คำอธิบายผลลัพธ์ที่ต้องการสำหรับการทดสอบแต่ละครั้ง
- การทดสอบเฉพาะที่ออกแบบมาเพื่อทดสอบผลลัพธ์เชิงลบ
- ทดสอบวิธีที่โปรแกรมจัดการกับอินพุตที่ไม่คาดคิด
- คำอธิบายที่ชัดเจนของสิ่งที่ถือว่าผ่านหรือล้มเหลวสำหรับการทดสอบแต่ละครั้ง
- การทดสอบที่คลุมเครือ ซึ่งอธิบายไว้ด้านล่าง
รายการนี้ควรให้แนวคิดบางประการในการสร้างแผนการทดสอบของคุณ ผู้ดูแลระบบส่วนใหญ่ควรรักษาความเรียบง่ายและไม่เป็นทางการ
ทดสอบแต่เนิ่นๆ—ทดสอบบ่อยๆ
ฉันเริ่มทดสอบเชลล์สคริปต์ของฉันเสมอทันทีที่ฉันทำส่วนแรกที่ทำงานได้สำเร็จ สิ่งนี้เป็นจริงไม่ว่าฉันจะเขียนโปรแกรมบรรทัดคำสั่งสั้นๆ หรือสคริปต์ที่เป็นไฟล์ปฏิบัติการ
ฉันมักจะเริ่มสร้างโปรแกรมใหม่ด้วยเทมเพลตเชลล์สคริปต์ ฉันเขียนโค้ดสำหรับฟังก์ชัน Help และทดสอบ ซึ่งมักจะเป็นส่วนเล็กๆ น้อยๆ ของกระบวนการนี้ แต่ช่วยให้ฉันเริ่มต้นได้ และทำให้แน่ใจได้ว่าสิ่งต่างๆ ในเทมเพลตทำงานอย่างถูกต้องตั้งแต่เริ่มแรก ณ จุดนี้ ง่ายต่อการแก้ไขปัญหาเกี่ยวกับส่วนเทมเพลตของสคริปต์หรือแก้ไขให้ตรงตามความต้องการที่เทมเพลตมาตรฐานไม่ทำ
เมื่อเทมเพลตและฟังก์ชัน Help ใช้งานได้แล้ว ฉันจะไปยังการสร้างเนื้อความของโปรแกรมโดยเพิ่มความคิดเห็นเพื่อจัดทำเอกสารขั้นตอนการเขียนโปรแกรมที่จำเป็นเพื่อให้เป็นไปตามข้อกำหนดของโปรแกรม ตอนนี้ฉันเริ่มเพิ่มโค้ดเพื่อให้เป็นไปตามข้อกำหนดที่ระบุไว้ในแต่ละความคิดเห็น โค้ดนี้อาจจำเป็นต้องเพิ่มตัวแปรที่เริ่มต้นในส่วนนั้นของเทมเพลต ซึ่งตอนนี้กำลังกลายเป็นเชลล์สคริปต์
นี่คือจุดที่การทดสอบเป็นมากกว่าแค่การป้อนข้อมูลและการตรวจสอบผลลัพธ์ ต้องใช้การทำงานพิเศษเล็กน้อย บางครั้งฉันเพิ่มคำสั่งที่พิมพ์ผลลัพธ์กลางของรหัสที่ฉันเพิ่งเขียนและตรวจสอบว่า สำหรับสคริปต์ที่ซับซ้อนกว่านี้ ฉันเพิ่ม -t ตัวเลือกสำหรับ "โหมดทดสอบ" ในกรณีนี้ รหัสทดสอบภายในจะทำงานก็ต่อเมื่อ -t ป้อนตัวเลือกในบรรทัดคำสั่ง
การทดสอบครั้งสุดท้าย
หลังจากที่โค้ดเสร็จสมบูรณ์ ฉันกลับไปทำการทดสอบคุณลักษณะและฟังก์ชันทั้งหมดโดยใช้อินพุตที่รู้จักเพื่อสร้างเอาต์พุตเฉพาะ ฉันยังทดสอบอินพุตแบบสุ่มเพื่อดูว่าโปรแกรมสามารถจัดการกับอินพุตที่ไม่คาดคิดได้หรือไม่
การทดสอบขั้นสุดท้ายมีจุดประสงค์เพื่อตรวจสอบว่าโปรแกรมทำงานตามหลักที่ตั้งใจไว้ ส่วนใหญ่ของการทดสอบขั้นสุดท้ายคือการทำให้แน่ใจว่าฟังก์ชันที่ทำงานก่อนหน้านี้ในวงจรการพัฒนาจะไม่ถูกทำลายโดยโค้ดที่เพิ่มหรือเปลี่ยนแปลงในภายหลังของวงจร
หากคุณได้ทดสอบสคริปต์ขณะที่คุณเพิ่มโค้ดใหม่เข้าไป คุณอาจคิดว่าไม่ควรมีเซอร์ไพรส์ใดๆ ในระหว่างการทดสอบครั้งสุดท้าย ผิด! มีเซอร์ไพรส์อยู่เสมอระหว่างการทดสอบขั้นสุดท้าย เสมอ. คาดหวังความประหลาดใจเหล่านั้นและพร้อมที่จะใช้เวลาแก้ไข หากไม่มีข้อบกพร่องใด ๆ ที่ค้นพบระหว่างการทดสอบขั้นสุดท้าย ก็ไม่มีประโยชน์ที่จะทำการทดสอบขั้นสุดท้ายเลยใช่หรือไม่
การทดสอบในการผลิต
ห๊ะ—อะไรนะ
"จนกว่าจะมีการผลิตโปรแกรมอย่างน้อยหกเดือน ข้อผิดพลาดที่อันตรายที่สุดจะถูกค้นพบ"
— สมมุติฐานการเขียนโปรแกรมของ Troutman
ใช่ ตอนนี้การทดสอบในการผลิตถือว่าเป็นเรื่องปกติและเป็นที่น่าพอใจ จากการเป็นผู้ทดสอบด้วยตัวเองแล้ว เรื่องนี้ก็ดูสมเหตุสมผล "แต่เดี๋ยวก่อน! มันอันตราย" คุณพูด ประสบการณ์ของฉันคือไม่มีอันตรายมากไปกว่าการทดสอบอย่างละเอียดและเข้มงวดในสภาพแวดล้อมการทดสอบเฉพาะ ในบางกรณี ไม่มีทางเลือกเพราะไม่มีสภาพแวดล้อมการทดสอบ—เฉพาะการผลิตเท่านั้น
ผู้ดูแลระบบไม่ใช่คนแปลกหน้าสำหรับความจำเป็นในการทดสอบสคริปต์ใหม่หรือสคริปต์ที่แก้ไขในการผลิต เมื่อใดก็ตามที่สคริปต์ถูกย้ายไปสู่การผลิต นั่นจะกลายเป็นบททดสอบขั้นสุดท้าย สภาพแวดล้อมการผลิตถือเป็นส่วนที่สำคัญที่สุดของการทดสอบนั้น ไม่มีสิ่งใดที่ผู้ทดสอบสามารถฝันถึงในสภาพแวดล้อมการทดสอบที่สามารถจำลองสภาพแวดล้อมการผลิตที่แท้จริงได้อย่างเต็มที่
แนวปฏิบัติการทดสอบแบบใหม่ที่ถูกกล่าวหาในการผลิตเป็นเพียงการรับรู้ถึงสิ่งที่ผู้ดูแลระบบรู้จักมาโดยตลอด การทดสอบที่ดีที่สุดคือการผลิต ตราบใดที่ไม่ใช่การทดสอบเพียงอย่างเดียว
การทดสอบแบบคลุมเครือ
นี่เป็นอีกคำศัพท์หนึ่งที่ทำให้ฉันต้องกลอกตา ความหมายที่สำคัญของมันคือความเรียบง่าย:ให้ใครซักคนมากดแป้นจนกว่าจะมีบางอย่างเกิดขึ้น และดูว่าโปรแกรมจะจัดการกับมันได้ดีเพียงใด แต่มันมีอะไรมากกว่านั้นจริงๆ
การทดสอบแบบคลุมเครือนั้นเหมือนกับเวลาที่ลูกชายของฉันถอดรหัสเกมในเวลาไม่ถึงนาทีด้วยการสุ่มอินพุต นั่นเป็นการสิ้นสุดความพยายามของฉันในการเขียนเกมให้เขา
แผนการทดสอบส่วนใหญ่ใช้อินพุตที่เฉพาะเจาะจงมากซึ่งสร้างผลลัพธ์หรือผลลัพธ์ที่เฉพาะเจาะจง ไม่ว่าการทดสอบจะกำหนดผลลัพธ์ที่เป็นบวกหรือลบว่าเป็นความสำเร็จ การทดสอบก็ยังคงถูกควบคุม และอินพุตและผลลัพธ์จะถูกระบุและคาดหวัง เช่น ข้อความแสดงข้อผิดพลาดเฉพาะสำหรับโหมดความล้มเหลวเฉพาะ
การทดสอบแบบคลุมเครือเป็นเรื่องเกี่ยวกับการจัดการกับการสุ่มในทุกแง่มุมของการทดสอบ เช่น เงื่อนไขการเริ่มต้น การป้อนข้อมูลแบบสุ่มมากและไม่คาดคิด การเลือกชุดค่าผสมแบบสุ่ม หน่วยความจำต่ำ CPU ระดับสูงที่แข่งขันกับโปรแกรมอื่น อินสแตนซ์หลายรายการของโปรแกรมที่อยู่ระหว่างการทดสอบ และเงื่อนไขสุ่มอื่นๆ ที่คุณคิดได้เพื่อใช้กับการทดสอบ
ฉันพยายามทำการทดสอบที่คลุมเครือตั้งแต่ต้น หากสคริปต์ทุบตีไม่สามารถจัดการกับการสุ่มที่มีนัยสำคัญในช่วงแรกๆ ของมัน ก็ไม่น่าจะดีขึ้นเมื่อคุณเพิ่มโค้ดเพิ่มเติม นี่เป็นเวลาที่ดีในการตรวจจับปัญหาเหล่านี้และแก้ไขปัญหาในขณะที่โค้ดค่อนข้างง่าย การทดสอบที่คลุมเครือเล็กน้อยในแต่ละขั้นตอนยังมีประโยชน์ในการค้นหาปัญหาก่อนที่จะถูกปิดบังด้วยโค้ดเพิ่มเติม
หลังจากเขียนโค้ดเสร็จแล้ว ฉันชอบทำการทดสอบแบบคลุมเครือมากกว่านี้ ทำการทดสอบที่คลุมเครืออยู่เสมอ ฉันรู้สึกประหลาดใจกับผลลัพธ์บางอย่างอย่างแน่นอน การทดสอบสิ่งที่คาดหวังเป็นเรื่องง่าย แต่ผู้ใช้มักไม่ทำสิ่งที่คาดหวังด้วยสคริปต์
ตัวอย่างสถานที่ท่องเที่ยวที่กำลังมา
บทความนี้ประสบความสำเร็จเพียงเล็กน้อยในการสร้างเทมเพลต แต่ส่วนใหญ่พูดถึงการทดสอบ เนื่องจากการทดสอบเป็นส่วนสำคัญในการสร้างโปรแกรมทุกประเภท ในบทความถัดไปในชุดนี้ คุณจะเพิ่มฟังก์ชันความช่วยเหลือพื้นฐานพร้อมกับโค้ดบางส่วนเพื่อตรวจหาและดำเนินการกับตัวเลือกต่างๆ เช่น -h ไปยังเทมเพลตสคริปต์ทุบตีของคุณ
ทรัพยากร
- วิธีตั้งโปรแกรมด้วย Bash:ไวยากรณ์และเครื่องมือ
- วิธีตั้งโปรแกรมด้วย Bash:ตัวดำเนินการเชิงตรรกะและการขยายเชลล์
- วิธีตั้งโปรแกรมด้วย Bash:Loops
บทความชุดนี้มีเนื้อหาบางส่วนมาจากเล่มที่ 2 บทที่ 10 ของหลักสูตรการเรียนรู้ด้วยตนเองเกี่ยวกับ Linux แบบสามส่วนของ David Both การใช้งานและการดูแลระบบ Linux—Zero to SysAdmin
