ขณะนี้ฉันกำลังสำรวจแพ็คเกจ Debian และฉันได้อ่านตัวอย่างโค้ดแล้ว และในทุกบรรทัดตัวอย่างpostinstสคริปต์เป็นรูปแบบ
some command || true
another command || trueดังนั้นหากคำสั่งบางตัวล้มเหลวบรรทัดจะส่งกลับค่าจริง แต่ฉันไม่เห็นว่าสิ่งนี้จะส่งผลกระทบต่อผลลัพธ์ของโปรแกรมอย่างไร
คำตอบ:
เหตุผลสำหรับรูปแบบนี้คือสคริปต์ผู้ดูแลในแพ็คเกจ Debian มีแนวโน้มที่จะเริ่มต้นset -eซึ่งทำให้เชลล์ออกจากทันทีที่คำสั่งใด ๆ (พูดอย่างเคร่งครัดไปป์ไลน์รายชื่อหรือคำสั่งผสม) ออกด้วยสถานะที่ไม่เป็นศูนย์ สิ่งนี้ช่วยให้มั่นใจได้ว่าข้อผิดพลาดจะไม่เกิดขึ้น: ทันทีที่มีบางอย่างผิดพลาดสคริปต์จะยกเลิก
ในกรณีที่คำสั่งในสคริปต์ได้รับอนุญาตให้ล้มเหลวการเพิ่ม|| trueให้แน่ใจว่าคำสั่งผสมที่เกิดขึ้นจะออกจากสถานะศูนย์เสมอดังนั้นสคริปต์จะไม่ยกเลิก ตัวอย่างเช่นการลบไดเรกทอรีไม่ควรเป็นข้อผิดพลาดร้ายแรง (ป้องกันไม่ให้แพคเกจถูกลบ); ดังนั้นเราจะใช้
rmdir ... || trueเนื่องจากrmdirไม่มีตัวเลือกที่จะบอกให้ละเว้นข้อผิดพลาด
set -eต้องมีการไม่มี|| trueเลยผมคิดว่ามันสำคัญที่จะให้บริบท หากคุณสังเกตเห็นสิ่งผิดปกติใน POWER ฉันขอแนะนำให้คุณใช้ไฟล์บั๊ก ( reportbug)!
set -eไม่เพียง แต่เป็น "การประชุมแบบเดเบียน" เท่านั้น แต่รูปแบบการเขียนโปรแกรมที่ดีควรใช้เสมอ ดู. เช่นdavidpashley.com/articles/writing-robust-shell-scripts
|| trueset -e เป็นบริบทที่เป็นไปได้และเป็นไปได้มากที่สุด ฉันคำนับคำตอบนี้! แม้ว่าตามจริงแล้วมันจะมีประโยชน์ทุกครั้งที่สถานะการออกถือว่าไม่เกี่ยวข้องและ (ตามที่คุณเพิ่มลิงก์บทความ) ฉันไม่ได้ใช้สถานะออกเป็นส่วนหนึ่งของการควบคุมสคริปต์ของฉัน ฉันเห็นอรรถประโยชน์ (ในset -e) แต่จะไม่ไปไกลเท่าที่บทความทำและพูดว่า "ทุกสคริปต์ที่คุณเขียนควรมี set -e ที่ด้านบน" มันเป็นรูปแบบของการเขียนโปรแกรม "เสมอ | ทุก ๆ " รวมถึงกับดักของตัวเอง - aka - แน่นอนว่า: โซลูชั่นการ์ดป่าจะALWAYSย้อนกลับมาในที่สุด aka - ไม่มีการขี่ฟรี
set -eพฤติกรรม มันอาจไม่สำคัญสำหรับคุณหากเป้าหมายเดียวของคุณคือbashและเชลล์ที่ค่อนข้างใหม่ล่าสุดที่อาศัยอยู่/bin/shแต่สถานการณ์นั้นมีความเหมาะสมมากขึ้นเมื่อคุณต้องการสนับสนุนเชลล์ / ระบบเก่า
set -eอย่างละเอียดมากที่บันทึกพฤติกรรมของกระสุนที่แตกต่างกันโดย Sven Mascheckแต่หน้านี้ยังจัดทำเอกสารเกี่ยวกับเปลือกหอยประวัติศาสตร์ / โบราณจำนวนมากที่ไม่เกี่ยวข้องในวันนี้ นอกจากนี้ยังมีสองหน้านี้ที่มีความสำคัญที่แคบลง (ค้นหา "set -e"): หน้า "lintsh" , เอกสารเชลล์แบบพกพาของ autoconf -> ข้อ จำกัด ของหน้าย่อย
แม้ว่าจะไม่ส่งผลกระทบต่อผลลัพธ์ของโปรแกรมที่เพิ่งเรียกใช้ แต่จะอนุญาตให้ผู้เรียกดำเนินการต่อราวกับว่าทุกอย่างโอเคจะมีผลต่อตรรกะในอนาคต
Rephrased: มันปิดบังสถานะข้อผิดพลาดของคำสั่งก่อนหน้า
michael@x071:[/usr/sbin]cat /tmp/false.sh
#!/bin/sh
false
michael@x071:[/usr/sbin]cat /tmp/true.sh
#!/bin/sh
false || true
michael@x071:[/usr/sbin]sh /tmp/false.sh; echo $?
1
michael@x071:[/usr/sbin]sh /tmp/true.sh; echo $?
0set -eและ|| trueยูทิลิตี้จะถูกกำหนดโดยลักษณะและเป้าหมายของ โปรแกรมเมอร์
git remote remove foo || true git remote add foo http://blah- เราต้องการละเว้นข้อผิดพลาดหากไม่มีรีโมท
||:เป็นอีกวิธีหนึ่งในการเขียนแบบนี้ (:เป็นอีกรายการในตาราง builtin ที่ชี้ไปที่true- แต่รับประกันว่าจะเป็น builtin แม้กลับไปที่ Bourne ที่กล่าวว่าสำหรับ POSIX shtrueก็รับประกันได้ว่าจะเป็น builtin - ดังนั้นจึงเป็น ความทนทานยิ่งกว่าประสิทธิภาพในเวลาที่ทันสมัยแม้ในระยะไกล)