ฉันจะแยกข้อความ "การอนุญาตที่ถูกปฏิเสธ" ทั้งหมดออกจาก "ค้นหา" ได้อย่างไร?

ฉันต้องการซ่อนข้อความที่ถูกปฏิเสธสิทธิ์ทั้งหมดจาก:

find . > files_and_folders

ฉันกำลังทดลองเมื่อข้อความดังกล่าวเกิดขึ้น ฉันต้องรวบรวมโฟลเดอร์และไฟล์ทั้งหมดซึ่งมันไม่ได้เกิดขึ้น

เป็นไปได้หรือไม่ที่จะนำระดับการอนุญาตไปยังfiles_and_foldersไฟล์

ฉันจะซ่อนข้อผิดพลาดพร้อมกันได้อย่างไร

<sup>หมายเหตุ:
* คำตอบนี้อาจลึกกว่ากรณีใช้งานหมายจับและfind 2>/dev/nullอาจดีพอในหลาย ๆ สถานการณ์ มันอาจยังเป็นที่สนใจสำหรับมุมมองข้ามแพลตฟอร์มและสำหรับการอภิปรายเกี่ยวกับเทคนิคเชลล์ขั้นสูงบางอย่างในความสนใจในการค้นหาวิธีแก้ปัญหาที่แข็งแกร่งที่สุดเท่าที่จะเป็นไปได้แม้ว่าคดีที่ได้รับการปกป้องอาจเป็นสมมุติฐาน
* หากระบบของคุณได้รับการกำหนดค่าให้แสดงข้อความแสดงข้อผิดพลาดที่แปลแล้วให้นำหน้าการfindโทรด้านล่างด้วยLC_ALL=C( LC_ALL=C find ...) เพื่อให้แน่ใจว่ามีการรายงานข้อความภาษาอังกฤษเพื่อให้grep -v 'Permission denied'ทำงานได้ตามที่ต้องการ คงเส้นคงวา แต่ข้อผิดพลาดใด ๆ ที่ไม่ได้แสดงแล้วจะเป็นภาษาอังกฤษได้เป็นอย่างดี</sup>

หากคุณเปลือกbashหรือzshมีวิธีการแก้ปัญหาที่มีประสิทธิภาพในขณะที่ความเรียบง่ายที่สมเหตุสมผลโดยใช้เพียง POSIX สอดคล้องกับfindคุณลักษณะ ; ในขณะที่bashตัวมันเองไม่ได้เป็นส่วนหนึ่งของ POSIX แต่แพลตฟอร์ม Unix ที่ทันสมัยส่วนใหญ่จะมาพร้อมกับมันทำให้โซลูชันนี้สามารถพกพาได้อย่างกว้างขวาง:

find . > files_and_folders 2> >(grep -v 'Permission denied' >&2)

หมายเหตุ: มีโอกาสเล็กน้อยที่grepเอาต์พุตบางรายการอาจมาถึงหลังจาก findเสร็จสิ้นเนื่องจากคำสั่งโดยรวมไม่รอให้คำสั่งภายใน>(...)เสร็จสิ้น ในbashคุณสามารถป้องกันสิ่งนี้ได้โดยต่อท้าย| catคำสั่ง

• >(...)เป็น (ไม่ค่อยได้ใช้) การส่งออก ทดแทนกระบวนการที่ช่วยให้การเปลี่ยนเส้นทางออก (ในกรณีนี้, stderrเอาท์พุท ( 2>) เพื่อ stdin ภายในคำสั่ง>(...).
  นอกจากbashและzsh, kshการสนับสนุนพวกเขาเช่นกันในหลักการแต่พยายามที่จะรวมกับการเปลี่ยนเส้นทางจากstderrเช่นเดียวกับที่นี่ ( 2> >(...)) ดูเหมือนว่าจะถูกละเว้นใน (เงียบksh 93u+)

  • grep -v 'Permission denied'กรองออก ( -v) ทุกบรรทัด (จากfindกระแส stderr คำสั่ง) ที่มีวลีPermission deniedและผลเส้นที่เหลือให้ stderr ( >&2)

วิธีนี้คือ:

• ที่มีประสิทธิภาพ : grepจะใช้กับข้อความแสดงข้อผิดพลาดเท่านั้น(และไม่ใช่การรวมกันของพา ธ ไฟล์และข้อความแสดงข้อผิดพลาดซึ่งอาจนำไปสู่ผลบวกปลอม) และข้อความแสดงข้อผิดพลาดอื่น ๆ

• ผลข้างเคียงฟรี : findรหัสออกของจะถูกเก็บรักษาไว้: การไม่สามารถเข้าถึงรายการระบบไฟล์อย่างน้อยหนึ่งรายการที่พบผลลัพธ์ในรหัสออก1(แม้ว่าจะไม่บอกคุณว่ามีข้อผิดพลาดอื่น ๆนอกเหนือจากรายการที่ถูกปฏิเสธการอนุญาตเกิดขึ้นหรือไม่)

โซลูชันที่สอดคล้องกับ POSIX:

โซลูชันที่สอดคล้องกับ POSIX อย่างสมบูรณ์อาจมีข้อ จำกัด หรือต้องการงานเพิ่มเติม

หากfindเอาต์พุตของจะถูกจับในไฟล์อย่างไรก็ตาม (หรือถูกระงับทั้งหมด) ดังนั้นโซลูชันที่อิงกับไพพ์ไลน์จากคำตอบของ Jonathan Lefflerนั้นเรียบง่ายแข็งแกร่งและสอดคล้องกับ POSIX:

find . 2>&1 >files_and_folders | grep -v 'Permission denied' >&2

โปรดทราบว่าคำสั่งของเรื่องเปลี่ยนเส้นทางนี้2>&1จะต้องมาเป็นครั้งแรก

จับเอาท์พุท stdout ในไฟล์ขึ้นด้านหน้าช่วยให้2>&1การส่งเฉพาะข้อความผิดพลาดที่ผ่านท่อซึ่งgrepสามารถแล้วไม่น่าสงสัยเกี่ยวกับการใช้งาน

เพียงข้อเสียคือว่ารหัสทางออกโดยรวมจะเป็นgrepคำสั่งที่ไม่find's ซึ่งในกรณีนี้หมายถึง: ถ้ามีไม่มีข้อผิดพลาดเลยหรือเพียงข้อผิดพลาดได้รับอนุญาตปฏิเสธรหัสทางออกจะได้รับ1(การส่งสัญญาณความล้มเหลว ) มิฉะนั้น ( ข้อผิดพลาดอื่นที่ไม่ใช่การปฏิเสธสิทธิ์) 0- ซึ่งตรงกันข้ามกับเจตนา
ที่กล่าวว่าfindรหัสทางออกของไม่ค่อยใช้บ่อยเพราะมันมักจะสื่อข้อมูลเล็ก ๆ น้อย ๆ เกินความล้มเหลวขั้นพื้นฐานเช่นผ่านเส้นทางที่ไม่มีอยู่
อย่างไรก็ตามกรณีเฉพาะของบางคนเท่านั้นเส้นทางการป้อนข้อมูลที่เป็นไม่สามารถเข้าถึงได้เนื่องจากการขาดการสิทธิ์ที่จะสะท้อนให้เห็นในfind's รหัสออก (ทั้งในและ GNU BSD find): ถ้าข้อผิดพลาดสิทธิ์ปฏิเสธเกิดขึ้นใด ๆ1ของไฟล์ที่ประมวลผลรหัสทางออกที่ถูกกำหนดเป็น

รูปแบบที่อยู่ต่อไปนี้ที่:

find . 2>&1 >files_and_folders | { grep -v 'Permission denied' >&2; [ $? -eq 1 ]; }

ตอนนี้โค้ดทางออกบ่งชี้ว่ามีข้อผิดพลาดอื่น ๆ นอกเหนือจากที่ Permission deniedเกิดขึ้นหรือไม่: 1ถ้าเป็นเช่น0นั้น
กล่าวอีกนัยหนึ่ง: รหัสออกตอนนี้สะท้อนให้เห็นถึงเจตนาที่แท้จริงของคำสั่ง: success ( 0) ถูกรายงานหากไม่มีข้อผิดพลาดเกิดขึ้นทั้งหมดหรือเฉพาะข้อผิดพลาดที่ได้รับอนุญาตปฏิเสธเกิดขึ้น
นี่คือเนื้อหาที่ดียิ่งขึ้นกว่าเพียงแค่ส่งfindรหัสออกผ่านเหมือนในโซลูชันที่ด้านบน

gniourf_gniourfในความคิดเห็นเสนอข้อตกลงทั่วไป (ตาม POSIX) ยังคงของการแก้ปัญหานี้โดยใช้การเปลี่ยนเส้นทางที่ซับซ้อนซึ่งทำงานแม้กับพฤติกรรมเริ่มต้นของการพิมพ์เส้นทางไฟล์ไปยังstdout :

{ find . 3>&2 2>&1 1>&3 | grep -v 'Permission denied' >&3; } 3>&2 2>&1

กล่าวโดยย่อ: ตัวอธิบายไฟล์ที่กำหนดเอง3ถูกใช้เพื่อสลับ stdout ( 1) และ stderr ( 2) ชั่วคราวเพื่อให้สามารถส่งข้อความแสดงข้อผิดพลาดเพียงอย่างเดียวgrepผ่าน stdout ได้

โดยไม่ต้องเปลี่ยนเส้นทางเหล่านี้ทั้งข้อมูล (เส้นทางแฟ้ม) และข้อความผิดพลาดจะได้รับการประปาgrepผ่าน stdout และgrepจากนั้นก็จะไม่สามารถที่จะแยกแยะความแตกต่างระหว่างข้อผิดพลาด Permission deniedและ (สมมุติ) ไฟล์ที่มีชื่อที่เกิดขึ้นจะมีPermission deniedคำพูดที่ว่า

เช่นเดียวกับในโซลูชันแรกรหัสทางออกที่รายงานจะเป็นgrep'ไม่ใช่find' แต่สามารถใช้วิธีแก้ไขแบบเดียวกับข้างต้นได้

หมายเหตุเกี่ยวกับคำตอบที่มีอยู่:

• มีหลายจุดที่จะต้องทราบเกี่ยวกับคำตอบของไมเคิล Brux ของ , find . ! -readable -prune -o -print:

  • มันต้องGNU find ; มันไม่ทำงานบน macOS แน่นอนว่าถ้าคุณต้องการคำสั่งให้ทำงานกับ GNU findเท่านั้นสิ่งนี้จะไม่เป็นปัญหาสำหรับคุณ

  • Permission deniedข้อผิดพลาดบางอย่างอาจยังคงปรากฏ: find ! -readable -pruneรายงานข้อผิดพลาดดังกล่าวสำหรับรายการลูกของไดเรกทอรีที่ผู้ใช้ปัจจุบันได้rรับอนุญาต แต่ไม่มีxสิทธิ์ (ปฏิบัติการ) เหตุผลก็คือว่าเพราะไดเรกทอรีของตัวเองเป็นที่อ่าน-pruneไม่ได้ดำเนินการและความพยายามที่จะลงมาลงในไดเรกทอรีที่แล้วก่อให้เกิดข้อผิดพลาด ที่กล่าวว่ากรณีทั่วไปคือการrอนุญาตจะหายไป

  • หมายเหตุ: ประเด็นต่อไปนี้เป็นเรื่องของปรัชญาและ / หรือกรณีการใช้งานที่เฉพาะเจาะจงและคุณอาจตัดสินใจว่ามันไม่เกี่ยวข้องกับคุณและคำสั่งนั้นเหมาะกับความต้องการของคุณเป็นอย่างดีโดยเฉพาะอย่างยิ่งถ้าเพียงแค่พิมพ์เส้นทางเท่านั้น

    • หากคุณคิดว่าการกรองข้อความแสดงข้อผิดพลาดที่ได้รับอนุญาตนั้นเป็นงานแยกต่างหากที่คุณต้องการใช้กับคำสั่งใด ๆ findแนวทางที่ตรงกันข้ามของการป้องกันข้อผิดพลาดที่ถูกปฏิเสธในเชิงรุกต้องมีการนำเสนอ "สัญญาณรบกวน" ลงในfindคำสั่ง ความซับซ้อนและตรรกะข้อผิดพลาด
    • ยกตัวอย่างเช่นตัวมากขึ้นได้รับการโหวตความคิดเห็นเกี่ยวกับคำตอบของไมเคิล (เช่นการเขียนนี้) ความพยายามที่จะแสดงให้เห็นว่าการขยายคำสั่งโดยรวมถึงการ-nameกรองดังนี้
      find . ! -readable -prune -o -name '*.txt'
      นี้ แต่ไม่ได้ทำงานตามที่ตั้งใจไว้เพราะต่อท้าย-printการดำเนินการที่จำเป็น (คำอธิบายสามารถพบได้ในคำตอบนี้ ) รายละเอียดปลีกย่อยดังกล่าวสามารถแนะนำข้อบกพร่อง

• วิธีการแก้ปัญหาครั้งแรกในคำตอบของโจนาธาน Leffler ของ , find . 2>/dev/null > files_and_foldersเป็นตัวเขาเองรัฐ สุ่มสี่สุ่มห้าเงียบทุกข้อความผิดพลาด (และวิธีแก้ปัญหาคือยุ่งยากและไม่แข็งแกร่งอย่างเต็มที่ในขณะที่เขายังอธิบาย) อย่างไรก็ตามในทางปฏิบัติการพูดเป็นวิธีแก้ปัญหาที่ง่ายที่สุดเนื่องจากคุณอาจมีเนื้อหาที่จะสันนิษฐานว่าข้อผิดพลาดใด ๆ และทั้งหมดจะเกี่ยวข้องกับการอนุญาต

• คำตอบหมอกของ , sudo find . > files_and_folders, กระชับและจริงจัง แต่ไม่รอบคอบสำหรับสิ่งอื่นมากกว่าแค่พิมพ์ชื่อไฟล์เพื่อความปลอดภัยเพราะคุณใช้เป็นรากของผู้ใช้ "คุณมีความเสี่ยงทั้งระบบของคุณจะถูก messed ขึ้นจากข้อผิดพลาดในการหา หรือเวอร์ชันที่เป็นอันตรายหรือการเรียกที่ไม่ถูกต้องซึ่งเขียนสิ่งที่ไม่คาดคิดซึ่งไม่สามารถเกิดขึ้นได้หากคุณใช้สิ่งนี้ด้วยสิทธิ์ปกติ "(จากความคิดเห็นเกี่ยวกับคำตอบของหมอกโดยtripleee )

• วิธีการแก้ปัญหาครั้งที่ 2 ในคำตอบ viraptor ของ , find . 2>&1 | grep -v 'Permission denied' > some_fileจะเสี่ยงต่อการบวกเท็จ (เนื่องจากส่งส่วนผสมของ stdout และ stderr ผ่านท่อ) และอาจแทนการรายงานไม่ใช่ข้อผิดพลาด -permission ปฏิเสธผ่าน stderr จับพวกเขาควบคู่ไปกับเส้นทางการส่งออก ในไฟล์เอาต์พุต

ใช้:

find . 2>/dev/null > files_and_folders

สิ่งนี้ซ่อนไม่เพียงPermission deniedข้อผิดพลาดแน่นอน แต่ข้อความข้อผิดพลาดทั้งหมด

หากคุณต้องการเก็บข้อผิดพลาดอื่น ๆ ที่เป็นไปได้เช่นฮ็อปมากเกินไปบน symlink แต่ไม่ใช่สิทธิ์ที่ถูกปฏิเสธคุณอาจต้องเดาได้เลยว่าคุณไม่มีไฟล์จำนวนมากที่เรียกว่า 'สิทธิ์ถูกปฏิเสธ' และลอง:

find . 2>&1 | grep -v 'Permission denied' > files_and_folders

หากคุณต้องการกรองข้อผิดพลาดมาตรฐานอย่างเคร่งครัดคุณสามารถใช้โครงสร้างที่ซับซ้อนยิ่งขึ้น:

find . 2>&1 > files_and_folders | grep -v 'Permission denied' >&2

I / O เปลี่ยนเส้นทางในคำสั่ง:find 2>&1 > files_and_folders |ไพพ์เปลี่ยนทิศทางเอาต์พุตมาตรฐานไปยังgrepคำสั่งและใช้ก่อน การ2>&1ส่งข้อผิดพลาดมาตรฐานไปยังตำแหน่งเดียวกับเอาต์พุตมาตรฐาน (ไปป์) > files_and_foldersส่งออกมาตรฐาน ( แต่ข้อผิดพลาดไม่ได้มาตรฐาน) ไปยังแฟ้ม ผลลัพธ์สุทธิคือข้อความที่เขียนไปยังข้อผิดพลาดมาตรฐานจะถูกส่งไปป์และเอาต์พุตปกติของfindถูกเขียนไปยังไฟล์ grepกรองออกมาตรฐาน (คุณสามารถตัดสินใจว่า selective คุณต้องการให้เป็นและอาจมีการเปลี่ยนแปลงการสะกดคำขึ้นอยู่กับสถานที่และ O / S) และสุดท้าย>&2หมายความว่าข้อความแสดงข้อผิดพลาดที่เหลืออยู่ (เขียนไปยังเอาต์พุตมาตรฐาน) ไปที่ข้อผิดพลาดมาตรฐานอีกครั้ง การเปลี่ยนเส้นทางครั้งสุดท้ายอาจถือว่าเป็นตัวเลือกที่เทอร์มินัล แต่เป็นความคิดที่ดีมากที่จะใช้มันในสคริปต์เพื่อให้ข้อความแสดงข้อผิดพลาดปรากฏขึ้นบนข้อผิดพลาดมาตรฐาน

มีรูปแบบที่ไม่มีที่สิ้นสุดในชุดรูปแบบนี้ขึ้นอยู่กับสิ่งที่คุณต้องการจะทำ นี้จะทำงานบนความแตกต่างใด ๆ ของระบบปฏิบัติการยูนิกซ์กับอนุพันธ์เปลือกบอร์น (ทุบตี, Korn, ... ) และรุ่นใด ๆ POSIX findสอดคล้องของ

หากคุณต้องการปรับให้เข้ากับรุ่นที่findคุณมีในระบบของคุณอาจมีตัวเลือกอื่นให้เลือก findโดยเฉพาะอย่างยิ่งGNU มีตัวเลือกมากมายที่ไม่สามารถใช้ได้ในรุ่นอื่น - ดูคำตอบที่ยอมรับในปัจจุบันสำหรับชุดตัวเลือกดังกล่าว

ใช้:

find . ! -readable -prune -o -print

หรือโดยทั่วไป

find <paths> ! -readable -prune -o <other conditions like -name> -print

• การหลีกเลี่ยง "การอนุญาตที่ถูกปฏิเสธ"
• และอย่าระงับข้อความผิดพลาด (อื่น ๆ )
• และรับสถานะทางออก 0 ("ประมวลผลไฟล์ทั้งหมดสำเร็จแล้ว")

ทำงานร่วมกับ: find (GNU findutils) 4.4.2 พื้นหลัง:

• การ-readableทดสอบตรงกับไฟล์ที่อ่านได้ !ประกอบการผลตอบแทนจริงเมื่อการทดสอบเป็นเท็จ และ! -readableตรงกับไดเรกทอรีที่ไม่สามารถอ่านได้ (& ไฟล์)
• การ-pruneกระทำที่ไม่ลงไปในไดเรกทอรี
• ! -readable -prune สามารถแปลเป็น: หากไดเรกทอรีไม่สามารถอ่านได้อย่าลงไปในนั้น
• การ-readableทดสอบจะพิจารณารายการการควบคุมการเข้าถึงบัญชีและการอนุญาตอื่น ๆ ซึ่งการ-permทดสอบจะข้ามไป

ดูfindmanpage (1)สำหรับรายละเอียดเพิ่มเติมมากมาย

หากคุณต้องการเริ่มการค้นหาจากรูท "/" คุณอาจจะเห็นบางสิ่งที่ผลลัพธ์เช่น:

find: /./proc/1731/fdinfo: Permission denied
find: /./proc/2032/task/2032/fd: Permission denied

เป็นเพราะได้รับอนุญาต เพื่อแก้ปัญหานี้:

1. คุณสามารถใช้คำสั่ง sudo:

   sudo find /. -name 'toBeSearched.file'

มันถามรหัสผ่านของผู้ใช้ super เมื่อป้อนรหัสผ่านคุณจะเห็นผลลัพธ์สิ่งที่คุณต้องการ หากคุณไม่ได้รับอนุญาตให้ใช้คำสั่ง sudo ซึ่งหมายความว่าคุณไม่มีรหัสผ่านของผู้ใช้ขั้นสูงให้ถามผู้ดูแลระบบก่อนเพื่อเพิ่มคุณลงในไฟล์ sudoers

2. คุณสามารถใช้การเปลี่ยนเส้นทางเอาต์พุตข้อผิดพลาดมาตรฐานจาก (โดยทั่วไปแสดง / หน้าจอ) ไปยังไฟล์บางไฟล์และหลีกเลี่ยงการเห็นข้อความแสดงข้อผิดพลาดบนหน้าจอ! เปลี่ยนเส้นทางไปที่ไฟล์พิเศษ / dev / null:

   find /. -name 'toBeSearched.file' 2>/dev/null

3. คุณสามารถใช้เปลี่ยนเส้นทางข้อผิดพลาดมาตรฐานจาก (โดยทั่วไปแสดง / หน้าจอ) ไปยังเอาต์พุตมาตรฐาน (โดยทั่วไปแสดง / หน้าจอ), จากนั้นไพพ์ด้วยคำสั่ง grep พร้อมพารามิเตอร์ -v "invert" เพื่อไม่ให้เห็นบรรทัดเอาต์พุตที่ 'ปฏิเสธสิทธิ์' คู่คำ:

   find /. -name 'toBeSearched.file' 2>&1 | grep -v 'Permission denied'

ฉันต้องใช้:

find / -name expect 2>/dev/null

ระบุชื่อของสิ่งที่ฉันต้องการค้นหาแล้วบอกให้เปลี่ยนเส้นทางข้อผิดพลาดทั้งหมดไปยัง / dev / null

คาดหวังว่าจะเป็นที่ตั้งของโปรแกรมคาดหวังที่ฉันค้นหา

stderrไปที่Pipe /dev/nullโดยใช้2> / dev / null

find . -name '...' 2>/dev/null

คุณยังสามารถใช้-permและเพรดิเคต-pruneเพื่อหลีกเลี่ยงการลดระดับลงในไดเรกทอรีที่อ่านไม่ได้ (ดูเพิ่มเติมฉันจะลบคำสั่งพิมพ์ "สิทธิ์ปฏิเสธ" ออกจากโปรแกรมค้นหาได้อย่างไร - Unix & Linux Stack Exchange ):

find . -type d ! -perm -g+r,u+r,o+r -prune -o -print > files_and_folders

ข้อผิดพลาดมาตรฐานเปลี่ยนเส้นทาง ตัวอย่างเช่นหากคุณใช้ bash ในเครื่องยูนิกซ์คุณสามารถเปลี่ยนเส้นทางข้อผิดพลาดมาตรฐานไปที่ / dev / null เช่นนี้:

find . 2>/dev/null >files_and_folders

ในขณะที่วิธีการข้างต้นไม่ได้จัดการเคสสำหรับ Mac OS X เนื่องจาก Mac Os X ไม่รองรับ-readableสวิตช์นี่คือวิธีที่คุณสามารถหลีกเลี่ยงข้อผิดพลาด 'สิทธิ์ที่ถูกปฏิเสธ' ในเอาต์พุตของคุณ นี่อาจช่วยใครซักคน

find / -type f -name "your_pattern" 2>/dev/null.

หากคุณกำลังใช้คำสั่งอื่นด้วยfindเช่นหากต้องการค้นหาขนาดของไฟล์ของรูปแบบบางอย่างในไดเรกทอรี2>/dev/nullจะยังคงใช้งานได้ตามที่แสดงด้านล่าง

find . -type f -name "your_pattern" -exec du -ch {} + 2>/dev/null | grep total$.

นี่จะส่งคืนขนาดทั้งหมดของไฟล์ของรูปแบบที่กำหนด จดบันทึก2>/dev/nullคำสั่งเมื่อสิ้นสุดการค้นหา

ข้อผิดพลาดเหล่านั้นจะถูกพิมพ์ออกไปยังข้อผิดพลาดมาตรฐาน (fd 2) หากต้องการกรองออกเพียงเปลี่ยนเส้นทางข้อผิดพลาดทั้งหมดไปที่ / dev / null:

find . 2>/dev/null > some_file

หรือก่อนเข้าร่วม stderr และ stdout แล้ว grep out ข้อผิดพลาดเฉพาะเหล่านั้น:

find . 2>&1 | grep -v 'Permission denied' > some_file

คำตอบง่ายๆ:

find . > files_and_folders 2>&-

2>&-ปิด ( -) บ่งไฟล์ข้อผิดพลาดมาตรฐาน ( 2) เพื่อให้ข้อความแสดงข้อผิดพลาดทั้งหมดถูกปิดเสียง

• รหัสออกจะยังคงอยู่1หากมีPermission deniedข้อผิดพลาดใด ๆที่จะพิมพ์ออกมา

คำตอบที่แข็งแกร่งสำหรับ GNU find:

find . -type d \! \( -readable -executable \) -prune -print -o -print > files_and_folders

ส่งตัวเลือกเพิ่มเติมไปfindที่-prune(ป้องกันไม่ให้ลงไป) แต่ยังคง-printไดเรกทอรีใด ๆ ( ) ที่ไม่มี ( ) มีทั้งและสิทธิ์หรือ ( ) ไฟล์อื่น ๆ-typed\!-readable-executable-o-print

• -readableและ-executableตัวเลือกต่าง ๆ คือส่วนขยาย GNU ไม่ใช่ส่วนหนึ่งของมาตรฐาน POSIX
• อาจยังคงส่งคืน ' Permission denied' สำหรับไฟล์ผิดปกติ / เสียหาย (เช่นดูรายงานข้อผิดพลาดที่ส่งผลกระทบต่อระบบไฟล์ที่ติดตั้งคอนเทนเนอร์โดยใช้lxcfs<v2.0.5)

คำตอบที่แข็งแกร่งที่ทำงานร่วมกับ POSIX ใด ๆfind(GNU, OSX / BSD, ฯลฯ )

{ LC_ALL=C find . 3>&2 2>&1 1>&3 > files_and_folders | grep -v 'Permission denied'; [ $? = 1 ]; } 3>&2 2>&1

ใช้ไพพ์ไลน์เพื่อส่งผ่านข้อผิดพลาดมาตรฐานไปยังgrepลบบรรทัดทั้งหมดที่มี'Permission denied'สตริง

LC_ALL=Cชุดสถาน POSIXใช้ตัวแปรสภาพแวดล้อม , 3>&2 2>&1 1>&3และ3>&2 2>&1 อธิบายซ้ำไฟล์ไปยังท่อกระแสมาตรฐานข้อผิดพลาดgrepและ[ $? = 1 ]การใช้งาน[]เพื่อกลับรหัสข้อผิดพลาดที่ส่งกลับโดยที่ใกล้เคียงกับพฤติกรรมเดิมของgrepfind

• จะกรอง'Permission denied'ข้อผิดพลาดใด ๆเนื่องจากการเปลี่ยนเส้นทางเอาต์พุต (เช่นหากfiles_and_foldersไฟล์นั้นไม่สามารถเขียนได้)

เพื่อหลีกเลี่ยงเพียงคำเตือนที่ได้รับอนุญาตปฏิเสธบอกให้ค้นหาเพื่อละเว้นไฟล์ที่อ่านไม่ได้โดยการตัดออกจากการค้นหา เพิ่มนิพจน์เป็นหรือในการค้นหาของคุณเช่น

find / \! -readable -prune -o -name '*.jbd' -ls

นี้ส่วนใหญ่จะบอกว่า(ตรงกับไฟล์อ่านได้ยากและตัดออกจากรายการ)หรือ(ตรงกับชื่อเหมือน .jbd * และแสดง [กับ LS]) (จำไว้ว่าโดยค่าเริ่มต้นนิพจน์คือ AND'd ด้วยกันเว้นแต่คุณจะใช้ - หรือ) คุณต้องการ -ls ในนิพจน์ที่สองมิฉะนั้นการค้นหาอาจเพิ่มการกระทำเริ่มต้นเพื่อแสดงการจับคู่อย่างใดอย่างหนึ่งซึ่งจะแสดงไฟล์ทั้งหมดที่อ่านไม่ได้ .

แต่ถ้าคุณกำลังมองหาไฟล์จริงในระบบของคุณมักจะไม่มีเหตุผลที่จะค้นหาใน / dev ซึ่งมีไฟล์จำนวนมากดังนั้นคุณควรเพิ่มการแสดงออกที่ไม่รวมไดเรกทอรีเช่น:

find / -mount \! -readable -prune  -o  -path /dev -prune  -o  -name '*.jbd' -ls

ดังนั้น(จับคู่ไฟล์ที่อ่านไม่ได้และตัดออกจากรายการ)หรือ(จับคู่พา ธ / dev และตัดออกจากรายการ)หรือ(จับคู่ไฟล์เช่น .jbd * และแสดง)

ใช้

sudo find / -name file.txt

มันโง่ (เพราะคุณยกระดับการค้นหา) และไม่ปลอดภัย แต่เขียนให้สั้นกว่านั้นมาก

คำตอบข้างต้นไม่เหมาะกับฉัน สิ่งที่ฉันพบบนอินเทอร์เน็ตเน้นที่: ซ่อนข้อผิดพลาด ไม่มีใครจัดการกระบวนการส่งคืนรหัส / ออกจากรหัสอย่างถูกต้อง ฉันใช้คำสั่ง find ภายในสคริปต์ทุบตีเพื่อค้นหาบางไดเรกทอรีจากนั้นตรวจสอบเนื้อหาของพวกเขา ฉันประเมินคำสั่งพบความสำเร็จโดยใช้โค้ดทางออก: ค่าเป็นศูนย์หรือไม่เช่นนั้นจะล้มเหลว

คำตอบที่ให้ไว้ข้างต้นโดยไมเคิล Bruxทำงานบางครั้ง แต่ฉันมีหนึ่งสถานการณ์ที่มันล้มเหลว! ฉันค้นพบปัญหาและแก้ไขด้วยตัวเอง ฉันต้องการตัดไฟล์เมื่อ:

it is a directory AND has no read access AND/OR has no execute access

ดูปัญหาสำคัญที่นี่คือ: และ / หรือ ลำดับเงื่อนไขที่แนะนำหนึ่งที่ดีที่ฉันอ่านคือ:

-type d ! -readable ! -executable -prune

มันไม่ได้ผลเสมอไป นี่หมายความว่าลูกพรุนจะถูกกระตุ้นเมื่อการแข่งขัน:

it is directory AND no read access AND no execute access

นิพจน์ลำดับนี้ล้มเหลวเมื่อได้รับสิทธิ์การเข้าถึงเพื่ออ่าน แต่ไม่มีการเข้าถึงเพื่อดำเนินการ

หลังจากการทดสอบฉันรู้เรื่องนั้นและเปลี่ยนเชลล์สคริปท์เป็น:

nice find / home * / -maxdepth 5 -follow \
    \ (-type d -a ! \ (-ableable -a -executable \) \) -prune \
    -o \
    \ (-type d -a -readable -a - executable -a -name "$ {m_find_name}" \) -print

กุญแจสำคัญที่นี่คือการวาง "ไม่จริง" สำหรับการแสดงออกรวม:

has read access AND has execute access

มิฉะนั้นจะไม่สามารถเข้าถึงได้อย่างสมบูรณ์ซึ่งหมายถึง: ตัดออก สิ่งนี้พิสูจน์แล้วว่าเหมาะกับฉันในสถานการณ์หนึ่งซึ่งแนวทางแก้ไขก่อนหน้านี้ล้มเหลว

ฉันให้รายละเอียดทางเทคนิคด้านล่างสำหรับคำถามในส่วนความเห็น ฉันขอโทษถ้ารายละเอียดมากเกินไป

• ¿ทำไมต้องใช้คำสั่งดี ผมมีความคิดที่นี่ ตอนแรกฉันคิดว่ามันจะเป็นการดีหากลดลำดับความสำคัญของกระบวนการเมื่อค้นหาระบบไฟล์ทั้งหมด ฉันรู้ว่ามันไม่มีเหตุผลสำหรับฉันเนื่องจากสคริปต์ของฉันถูก จำกัด อยู่เพียงไม่กี่ไดเรกทอรี ฉันลด -maxdepth เหลือ 3
• ¿ทำไมต้องค้นหาภายใน / home * /? มันไม่เกี่ยวข้องกับหัวข้อนี้ ฉันติดตั้งแอปพลิเคชั่นทั้งหมดด้วยมือผ่านซอร์สโค้ดคอมไพล์กับผู้ใช้ที่ไม่มีสิทธิพิเศษ (ไม่ใช่รูท) มีการติดตั้งภายใน "/ home" ฉันสามารถมีไบนารีและหลายรุ่นอยู่ด้วยกัน ฉันต้องการค้นหาไดเรกทอรีทั้งหมดตรวจสอบและสำรองข้อมูลในแบบมาสเตอร์ทาส ฉันสามารถมี "/ home" มากกว่าหนึ่งรายการ (ดิสก์หลายแผ่นที่ทำงานภายในเซิร์ฟเวอร์เฉพาะ)
• ¿ทำไมต้องใช้ -follow ผู้ใช้อาจสร้างลิงก์สัญลักษณ์ไปยังไดเรกทอรี มันมีประโยชน์ขึ้นอยู่กับฉันต้องเก็บบันทึกเส้นทางที่แน่นอน

คุณสามารถใช้ grep -v invert-match

-v, --invert-match        select non-matching lines

แบบนี้:

find . > files_and_folders
cat files_and_folders | grep -v "permission denied" > files_and_folders

ควรที่จะใช้เวทย์มนตร์

- = สำหรับ MacOS = -

สร้างคำสั่งใหม่โดยใช้นามแฝงเพียงเพิ่มในบรรทัด ~ / .bash_profile:

alias search='find / -name $file 2>/dev/null'

และในหน้าต่าง Terminal ใหม่คุณสามารถเรียกมันได้:

$ file=<filename or mask>; search

ตัวอย่างเช่น:

$ file = ฯลฯ ; ค้นหา

หากคุณใช้ CSH หรือ TCSH นี่คือวิธีแก้ไข:

( find . > files_and_folders ) >& /dev/null

หากคุณต้องการส่งออกไปยังสถานี:

( find . > /dev/tty ) >& /dev/null

อย่างไรก็ตามตามที่อธิบายไว้ใน "csh-whynot" คุณไม่ควรใช้ CSH