ตัวพิมพ์เล็กในชื่อไฟล์ Linux


11

เมื่อฉันพบว่า UpperCase นั้นสามารถอ่านได้สำหรับการแยกคำตัวอักษรแรกในชื่อที่ซับซ้อนยาว ๆ ฉันมักจะให้ชื่อไฟล์ Linux บางอันกับ UpperCase ส่วนใหญ่ executables บางไดเรกทอรีเกินไป

แต่ไม่กี่สัปดาห์ที่ผ่านมาฉันได้ตั้งข้อสังเกตว่าส่วนใหญ่ของชื่อไฟล์ทั้งหมดใน linux distrib ของฉันนั้นเป็นตัวพิมพ์เล็ก ...

ดังนั้นผมจึงทำบาง googling สักครู่ที่ผ่านมาและผมพบว่าบทความนี้: ลินุกซ์ชื่อไฟล์ที่รัฐหนึ่งควรเสมอใช้ตัวพิมพ์เล็กในโลกของยูนิกซ์

... เป็นการดีที่สุดที่จะใช้ตัวพิมพ์เล็กใน Linux เสมอเว้นแต่คุณจะนึกถึงเหตุผลที่ดีในการใช้ตัวพิมพ์ใหญ่หรือตัวพิมพ์เล็ก คน Unix ส่วนใหญ่ใช้ตัวพิมพ์เล็กเกือบเฉพาะ แต่นอกเหนือจากประเด็น "วัฒนธรรม" นี้แล้วยังมีอีกเหตุผลที่ดีในการใช้ตัวพิมพ์เล็ก หากคุณกำลังแชร์หรือเข้าถึงระบบไฟล์ DOS ด้วย Linux, DOS จะไม่สามารถดูไฟล์ที่มีชื่อไฟล์ตัวพิมพ์ใหญ่หรือตัวพิมพ์เล็กผสมกันได้ ...

เป็นอย่างนั้นจริงเหรอ?


2
ใช่ว่าเป็นกรณีจริง ๆ ดูเหมือนว่าคนยูนิกซ์จะหาคีย์ shift ไม่ได้ แต่ไม่มีเหตุผลใดที่จะสนับสนุนกฎกับกรณีที่มีการผสมกันได้ มันเป็นแค่การคุยโว
Ross Patterson

คำตอบ:


20

โปรแกรมเมอร์เกลียดการใช้ปุ่ม shift (และตัวล็อคปุ่มกดเป็นสิ่งที่หลายคนพยายามทำ ) ดำเนินการต่อจากจุดที่ระบุว่า "ใช้ตัวพิมพ์เล็กเสมอ" ...

เป็นการดีที่สุดที่จะใช้ตัวพิมพ์เล็กใน Linux เสมอเว้นแต่คุณจะนึกถึงเหตุผลที่ดีในการใช้ตัวพิมพ์ใหญ่หรือตัวพิมพ์เล็ก คน Unix ส่วนใหญ่ใช้ตัวพิมพ์เล็กเกือบเฉพาะแต่นอกเหนือจากประเด็น "วัฒนธรรม" นี้แล้วยังมีอีกเหตุผลที่ดีในการใช้ตัวพิมพ์เล็ก หากคุณแชร์หรือเข้าถึงระบบไฟล์ DOS ด้วย Linux, DOS จะไม่สามารถดูไฟล์ที่มีชื่อไฟล์ตัวพิมพ์ใหญ่หรือตัวพิมพ์เล็ก

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

ไฟล์บนเครื่อง linux ของคุณนั้นเป็นของคุณ ทำกับพวกเขาตามที่คุณต้องการในแบบที่เหมาะสมกับคุณ

ฉันพบว่าการใช้ตัวพิมพ์ใหญ่สำหรับตัวอักษรนำของไดเรกทอรีทำให้ฉันนำทางได้ง่ายขึ้น การทำ 'ls' ในไดเรกทอรีจะวางไดเรกทอรีทั้งหมดที่ด้านบนของรายการโดยอัตโนมัติและแยกไดเรกทอรีออกจากไฟล์ทำให้ทั้งคู่มองเห็นและนำทางได้ง่ายขึ้น แต่อีกครั้งที่เป็นสำหรับฉัน - ทำในสิ่งที่ทำงานสำหรับคุณ


1
DOS? จริงๆ? นั่นไม่เกี่ยวข้องอีกต่อไป
Maximus Minimus

3
@ mh01 ฉันเคยพิจารณา EBCDIC ที่ไม่เกี่ยวข้องจนกระทั่งเมื่อปีที่แล้วฉันต้องจัดการกับระบบที่ส่งชุดอักขระนั้นแทนที่จะเป็น ascii ฉันเคยเห็นระบบ OpenVMS รอบ ๆ (รุ่นล่าสุดเป็นเพียง 2 ปีที่ผ่านมาไม่เลวสำหรับบางสิ่งที่มีรุ่นแรกเมื่อ 35 ปีที่แล้ว) ... และระบบไฟล์ของมันยังไม่ตรงตามความเป็นจริง เห็นได้ชัดว่าแม็คมีทั้งกรณีที่สำคัญและกรณีตาย (และอบไอน้ำและ Photoshop ไม่ชอบกรณีที่ระบบไฟล์ที่สำคัญในแม็ค ) กรณีตายมีชีวิตอยู่

3
ไม่พูดถึงเครื่องเดสก์ท็อปส่วนใหญ่ที่รันระบบไฟล์ Windows แบบไม่ตรงตามตัวพิมพ์ใหญ่
Kilian Foth

จุดดีเกี่ยวกับ case-insensitivity เทียบกับการสงวน case แต่ถ้าคุณมีไฟล์ต่าง ๆ ที่แตกต่างกันในการใส่ชื่อไฟล์เท่านั้นฉันคิดว่ามีปัญหานอกเหนือจากการถ่ายโอนไปยังระบบไฟล์ case-insensitive ที่อาจทำให้เกิดความสับสน ..
CVN

9

"การมุ่งเน้นผู้บริโภค" (อะไรก็ตามที่อาจหมายถึง) ประเพณีมีแนวโน้มที่จะใช้ Title Case แม้ในโลก Unix นี่เป็นกรณีที่องค์กรต้องสงสัยมีคนที่คิดว่างานทั้งหมดต้องคำนึงถึงประสบการณ์ของผู้ใช้

ยกตัวอย่างเช่นเดสก์ท็อูบุนตูของฉันมีโฟลเดอร์ในไดเรกทอรีบ้านเรียกว่าDownloads, Pictures, Documentsและอื่น ๆ กันไปสำหรับแล็ปท็อปของฉัน OSX (ใช่มันจะนับมันของ BSD) แม้ว่ามันจะคุ้มค่าที่จะชี้ให้เห็นว่า Apple ยังคงตั้งชื่อไดเรกทอรีระบบของตัวเองด้วย titlecase (เช่น/Library/Audio/Apple Loops/) ในขณะที่รักษาระบบไฟล์พื้นฐาน "คลาสสิค" ทั้งหมดเป็นตัวพิมพ์เล็กทั้งหมด (เช่น/usr/libexec/dtrace/) แต่ไม่มีการแจกจ่ายลีนุกซ์ฉันรู้ว่าใช้ titlecase ที่ไหนก็ได้นอกโฮมไดเร็กตอรี่ของผู้ใช้.

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

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


จุดที่ดี แต่ฉันจะเพิ่มช่องว่างหรือขีดล่างง่ายต่อการอ่านแล้วอูฐหรือกรณี Pascal
jk

4

เกี่ยวกับอาร์กิวเมนต์ DOS: ระบบไฟล์ DOS / Windows จะเห็นไฟล์ของคุณโดยไม่คำนึงถึงตัวพิมพ์ใหญ่และสามารถจัดการได้ ระบบไฟล์ DOS ที่เก่ามากไม่รองรับชื่อไฟล์ที่เกิน 8.3 แต่ FAT32 ก็สามารถจัดการชื่อไฟล์ที่ยาวได้ ปัญหาเพียงอย่างเดียวคือในขณะที่ระบบไฟล์ DOS / Windows รักษากรณี (ในกรณีส่วนใหญ่รสชาติบางกรณีทิ้งชื่อไฟล์ที่เหมาะกับรูปแบบ 8.3) พวกเขาจะไม่ได้เป็นกรณี ๆไปเมื่อเทียบกับชื่อไฟล์; Windows ถือว่า "foobar", "Foobar", "FOOBAR" และ "fOObAr" เป็นชื่อไฟล์เดียวกัน

ที่กล่าวว่าส่วนใหญ่เป็นวัฒนธรรม แต่มีพื้นหลังบางอย่าง เหตุผลที่การประชุมนี้โดยเฉพาะอย่างยิ่งการติดอยู่ในโลกที่ใช้ระบบปฏิบัติการยูนิกซ์คือการใช้งาน มีสองข้อโต้แย้งหลักที่นี่:

  • การแยกคำโดยใช้ตัวอักษรที่ไม่ใช่ตัวอักษรดีกว่าเพื่อความสะดวกสบายในการอ่านมากกว่าการใช้ปลอกเพื่อทำเครื่องหมายขอบเขตของคำ หากคุณไม่ได้ทำการเปรียบเทียบราคาการเปรียบเทียบกับก่อนหน้านี้หนึ่งและการแจ้งเตือนที่ไม่เป็นไปได้ที่จะอ่าน (และแน่นอนสามเณรแยกออกจากกันที่ไม่เป็นอันตราย)
  • อักษรตัวพิมพ์เล็กมีรูปร่างที่หลากหลายมากกว่าตัวพิมพ์ใหญ่ซึ่งจะนำไปสู่รูปทรงคำที่หลากหลายมากขึ้น สิ่งนี้ทำให้ TEXT เป็นลายลักษณ์อักษรใน LOWERCASE ง่ายต่อการอ่านมากกว่า TEXT WRITTEN ในระดับสูง

ข้อสังเกตเหล่านี้ง่ายต่อการตรวจสอบและพวกเขายังได้รับการยืนยันจากการวิจัยทางวิทยาศาสตร์

นอกจากนี้วัฒนธรรม UNIX ชอบการประชุมที่ไม่เพียง แต่อ่านง่าย แต่ยังง่ายต่อการเขียน แฮกเกอร์ UNIX มักจะเป็นคนที่ใช้เวลาส่วนใหญ่ในการใช้แป้นพิมพ์และหลายคนใช้ทั้งระบบการพิมพ์ดีดแบบเป็นทางการหรือการดัดแปลงส่วนบุคคลเพื่อการเขียนโปรแกรม แนวคิดของการอยู่ในแถวบ้านนั้นมีความสำคัญเช่นกันดังนั้นผู้คนจึงต้องการหลีกเลี่ยงการใช้กุญแจที่ไม่สามารถเข้าถึงได้จากแถวบ้านโดยเฉพาะอย่างยิ่งปุ่ม Shift

หากคุณรวมข้อ จำกัด ทั้งสามข้อเข้าด้วยกันมันจะมีเพียงแบบแผนเดียวที่สมเหตุสมผลall-lowercase-with-dashesเท่านั้น


3
@StephaneRolland: การติดตามการตั้งชื่อที่สอดคล้องกันในสิ่งต่าง ๆ เช่นตัวระบุในภาษาการเขียนโปรแกรมที่แตกต่างกันและชื่อไฟล์ไม่ฉลาด มีความสอดคล้องกันในแต่ละอาณาจักรและยึดมั่นในอนุสัญญาที่จัดตั้งขึ้น แต่อย่าพยายามหาข้อตกลงหนึ่งข้อเพื่อควบคุมพวกเขาทั้งหมด ตัวแปร Java ไม่ใช่ชื่อตาราง SQL และไม่มีชื่อไฟล์เช่นกัน
tdammers

@StephaneRolland - ผมเชื่อว่าคำที่คุณต้องการคือsnake_case
cchamberlain
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.