โซลูชันที่แนะนำของฉัน:
find . -mindepth 1 -maxdepth 1 -type d '(' -exec mkdir -- '{}'/pictures \; -o -exec printf 'Could not create: [[%s/pictures]] ??\n' '{}' \; ')';
หรือ
(for d in ./* ; do [ -d "$d" ] && { mkdir -- "$d"/pictures || printf 'Could not create [[%s/pictures]]... permissions problem, disk is full?\n' "$d";};done;);
หรือ
(for d in * ; do [ -d "$d" ] && { mkdir -- "$d"/pictures || printf 'Could not create [[%s/pictures]]... permissions problem, disk is full?\n' "$d";};done;);
ต่อไปนี้เป็นตัวอย่าง:
(for d in ./* ; do [ -d "$d" ] && { mkdir "$d"/pictures || printf 'Could not create [[%s/pictures]]... permissions problem, disk is full?\n' "$d";};done;);
อันสุดท้ายนี้ใช้งานได้ แต่ฉันไม่แนะนำเลยมันอยู่ที่นี่เพื่อแสดงวิธีการใช้งาน ./* แทน * สามารถช่วยลดความเสี่ยงในบางกรณีเป็นการขยาย ./* จะเป็นเช่นเดียวกับ * แต่นำหน้าด้วย ./ ดังนั้นจึงเป็นเส้นทางที่ถูกต้องด้วยและแม้ว่าค่าใด ๆ เหล่านั้นจะถูกใช้อย่างไม่ระมัดระวังเหมือนใน mkdir "$d"/picturesมันจะทำให้ไม่มีปัญหา (หรือน้อยกว่าปัญหาขึ้นอยู่กับบริบท)
ทั้งหมดจะทำงานกับชื่อที่มี (ช่องว่าง) แท็บ CR, LF ... ตัวอักษรใด ๆ ในชื่อ (ยกเว้น /และนั่นเป็นเพราะไม่ได้รับอนุญาตในชื่อเพียงเพื่อแยกชื่อหนึ่งจากชื่ออื่นในเส้นทางและเป็นไดเรกทอรีราก) ดังนั้นโดยทั่วไปมันจะทำงานกับเส้นทางใด ๆ
สำหรับทุกคนที่ได้อ่านคำตอบที่ใช้ตัวแปรสำหรับชื่อระบบไฟล์: อย่าทำตามตัวอย่างเหล่านั้นในขณะที่เขียนทั้งหมดผิดและมีปัญหาที่พบบ่อยในพวกเขาทั้งหมด: ตัวแปรไม่ได้ยกมา แต่ใน ทุกกรณีที่นี่พวกเขาควรจะ (ถ้าไม่มีตัวอักษรที่มีปัญหาในชื่อมันจะทำแบบเดียวกัน แต่ในกรณีนั้นมันเป็นวิธีที่ดีที่จะเสนอราคา)
แต่สิ่งนี้ไม่ได้ใช้เฉพาะกับตัวแปรที่มีชื่อระบบไฟล์เท่านั้นการอ้างถึงการแทนที่ตัวแปรเดี่ยวทุกครั้งควรทำเมื่อเป็นไปได้
มีสถานการณ์น้อยมากที่เราไม่ต้องการอ้างถึงตัวแปรเชลล์ และในเนื้อหาทั้งหมดนั้นควรตรวจสอบสามครั้งในสถานการณ์ที่คุณไม่ควรระวังมากเกินไป สถานการณ์เหล่านั้นหายากมากและสามารถหลีกเลี่ยงได้เกือบตลอดเวลา
มีข้อยกเว้นคือ: เอกสารที่นี่, การแทนที่ภายในพวกเขาทำงานเหมือนที่พวกเขาอ้างถึงแล้ว, การแทนที่ภายในการแทนที่ภายในเอกสารที่นี่ - ประพฤติตามปกติ
(*) ฉันเคยเห็นมะเร็งชนิดนี้แพร่กระจายไปมากพอแล้วและมีคนจำนวนมากถามว่าทำไมคำสั่งทำลายในบางกรณี / เส้นทาง ... และ 'ช่วย' โดยเขียนใหม่ครึ่งหนึ่งของสคริปต์เมื่อคู่ของ " จะมีการแก้ไขบรรทัดที่กระทำผิด
ฉันคิดว่าฉันจะได้รับ 'ฉันอ้าง vars และ substitutions เหมือนไม่มีพรุ่งนี้!' พิมพ์บนเสื้อยืด)
ในขณะที่เขียนและ IMHO ไม่มีคำตอบเดียวที่ยอมรับได้ (ไม่ยอมรับโดยไม่คัดค้าน) และนั่นเป็นสิ่งที่ยอมรับไม่ได้!
ในบรรทัดสุดท้ายของคำถาม OP ถามวิธีการ mkdir */pictures และฉันถือว่าสิ่งนี้เป็นคำร้องสำหรับโซลูชันทั่วไปที่ไม่ได้ตั้งสมมติฐานเกี่ยวกับชื่อของไดเรกทอรีย่อย
บล็อกโค้ดที่สองจากคำตอบของ Nelson ( mkdir {1..777}/pictures; ) ใช้งานได้และไม่มีข้อผิดพลาดหรือการปฏิบัติที่ไม่ดี (ถ้าเราไม่นับการบังคับใช้ bash เป็นหนึ่ง xD) แต่จะใช้ได้เฉพาะในสถานการณ์ EXACT ที่อธิบายไว้ในส่วนแรกของคำถามและเฉพาะใน bash หรือการใช้งานเชลล์อื่น ๆ {n..m} การขยายรั้งสำหรับการสร้างตามลำดับของหลาย ๆ args จากที่หนึ่ง บล็อกโค้ดแรกในคำตอบนั้นสมควรที่จะถูกละเว้นเท่านั้นมันผิดอย่างมาก
หนึ่งโดย mdpc แก้ไขโดย Gareth ค่อนข้างยอมรับได้เกือบสมบูรณ์แบบ:
find . -mindepth 1 -maxdepth 1 -type d -exec mkdir {}/pictures \;
แม้จะมีความจริงที่ว่าการใช้มันตามที่เป็นอยู่อาจสิ้นสุดลงในการสังหารหมู่ แต่มันสามารถทำให้สมบูรณ์แบบได้โดยการแก้ไขเพื่อให้ดูเหมือน:
find . -mindepth 1 -maxdepth 1 -type d -exec mkdir -- '{}'/pictures \;
(นี่เป็นครั้งแรกในรายการวิธีแก้ปัญหาในคำตอบของฉัน)
มันรวมถึง -- ระหว่างตัวเลือก (ธง) สำหรับ mkdir (หรือ mkdir ตัวเอง) และข้อโต้แย้ง:
เป็นวิธีปฏิบัติที่ดีที่จะทำเช่นนั้นเสมอเมื่อตัวอักษรเริ่มต้นของอาร์กิวเมนต์แรกนั้นไม่ได้ hardcoded ลงในคำสั่งเพื่อป้องกันไม่ให้พยายามแยกอาร์กิวเมนต์เป็นตัวเลือกที่เป็นไปได้ (แฟล็ก) ซึ่งสามารถทำได้ด้วยคำสั่งเกือบทั้งหมด (มีข้อยกเว้นบางประการพบว่าตัวเองเป็นสิ่งที่ชัดเจน)
โปรดทราบว่าฉันยกมา {}มันถูกต้องมากขึ้นที่จะใช้ '{}', หรือ \{\}เนื่องจากวิธีการนี้จะไม่มีความหมายพิเศษใด ๆ สำหรับ posix shell แม้แต่คนเส็งเคร็ง
กล่าวโดยย่อ: มีเพียงสองวิธีเท่านั้นที่ไม่มีข้อผิดพลาด แต่มีวิธีหนึ่งที่ใช้ "bashism" ดังนั้นจะไม่ทำงานในหลาย ๆ เชลล์และอีกวิธีหนึ่งอาจแก้ไขได้มากกว่า (ไม่ดีพอสำหรับคนที่จะเรียนรู้ script-fu จาก ) ค่อนข้างน่าผิดหวัง ฉันคาดหวังไว้สูงเกินไปฉันเดา ...
ฉันไม่ได้บอกว่าจะไม่มีคำตอบใดที่เหมาะกับสถานการณ์นั้นแน่นอนส่วนใหญ่ แต่แน่นอนว่าส่วนใหญ่จะไม่ถูกต้องรหัส (ฉันไม่ได้หมายถึงไวยากรณ์ไม่เพียง แต่อย่างน้อย) และ / หรือรวมถึงการปฏิบัติที่ไม่ดีบางอย่าง (บางคนแม้แต่ความโหดร้ายที่แท้จริง)
แหล่งที่มา: ชนิดของความหลงใหลเกี่ยวกับมาตรฐานและความถูกต้องของรหัสและเอกสารจาก http://www.opengroup.org/ , ประคน, ทุบตีคนและแม้กระทั่งอินเทอร์เน็ตที่ลึก! : แต่แหล่งที่มาที่เชื่อถือได้ไม่ใช่คำตอบจากคนที่รู้เท่าทันถึงคำพูดที่ถูกต้อง - guys (มีอย่างน้อยสองคำตอบที่ดูเหมือนว่าในคำถามนี้ไม่มีความผิดที่ตั้งใจเกิดขึ้นไม่มีใคร รู้ทุกอย่าง)
bashการเขียนสคริปต์นับเป็นโปรแกรมหรือไม่