เมื่อกำหนดพา ธ ไปยังไดเร็กทอรีเป็นตัวแปรหรือค่าคงที่ควรลงท้ายด้วยเครื่องหมายทับหรือไม่? อนุสัญญาคืออะไร?
pwdใน Unix แสดงไดเร็กทอรีปัจจุบันของคุณโดยไม่มีเครื่องหมายทับในขณะที่แท็บที่สมบูรณ์cd /var/www/apps/มีเครื่องหมายทับท้ายซึ่งทำให้ฉันไม่แน่ใจ
เมื่อกำหนดพา ธ ไปยังไดเร็กทอรีเป็นตัวแปรหรือค่าคงที่ควรลงท้ายด้วยเครื่องหมายทับหรือไม่? อนุสัญญาคืออะไร?
pwdใน Unix แสดงไดเร็กทอรีปัจจุบันของคุณโดยไม่มีเครื่องหมายทับในขณะที่แท็บที่สมบูรณ์cd /var/www/apps/มีเครื่องหมายทับท้ายซึ่งทำให้ฉันไม่แน่ใจ
คำตอบ:
ฉันไม่รวมเครื่องหมายสแลชต่อท้ายเมื่อฉันกำหนดไดเร็กทอรีสำหรับจัดเก็บไฟล์ นั่นเป็นเพราะว่าฉันจะใช้มันอย่าง
$store_file = "$store_path/$file_id";
ฉันจะเพิ่มเครื่องหมายทับก่อนที่จะใช้ตัวแปรที่ควรจะเก็บเส้นทางไดเรกทอรี ฉันคิดว่าดีกว่าที่จะเพิ่มหนึ่งเสมอดีกว่าที่จะสงสัยว่ามีเครื่องหมายทับท้ายหรือไม่
'///' + $root + '//' + $file + '/'และมันก็ไม่สำคัญ แม้ว่าการมีเครื่องหมายทับเป็นวิธีที่ดีในการแยกแยะว่าพา ธ นั้นเป็นไฟล์หรือไดเร็กทอรี แต่จะเป็นการดีกว่าที่จะผนวกพา ธ ที่ต้องการ'/' + $rootแทนที่จะ$root + '/'เป็นเพราะคุณไม่สามารถมั่นใจได้ว่าพา ธ ที่ต่อท้ายจะมีเครื่องหมายทับ แต่คุณค่อนข้างมั่นใจได้ว่าเครื่องหมายทับหลายตัวจะถูกตีความว่าเป็นสแลชเดียวในสภาพแวดล้อมส่วนใหญ่
/tmp/store_data/จะเป็นไดเร็กทอรีในขณะที่ไม่มีความชัดเจนว่าเส้นทางเดียวกันโดยไม่มีเครื่องหมายทับคืออะไร/tmp/store_data
rm -rf $foo/$barสามารถลงท้ายด้วยrm -rf /
ฉันไปกับเครื่องหมายทับเพราะ:
"ถ้าลงท้ายด้วยเครื่องหมายทับแสดงว่าเป็นไดเร็กทอรีถ้าไม่ใช่แสดงว่าเป็นไฟล์" เป็นเรื่องง่ายที่จะจำ
อย่างน้อยในระบบปฏิบัติการที่ฉันใช้กันทั่วไปการเพิ่มเครื่องหมายทับเป็นสองเท่าทำให้ไม่มีปัญหาในขณะที่การละเว้นเครื่องหมายทับจะทำให้เกิดปัญหาใหญ่ ดังนั้นจึงปลอดภัยที่สุดที่จะใส่เครื่องหมายทับลงในตัวแปรและใช้ "$ path / $ file" เมื่อใช้มัน
A pathname that begins with two successive slashes may be interpreted in an implementation-defined manner, although more than two leading slashes shall be treated as a single slash.โดยส่วนใหญ่จะสังเกตได้ว่าเครื่องหมายทับคู่มักถูกตีความว่าเป็นเครื่องหมายทับเดียวในการใช้งานทั่วไป
ฉันรู้ว่านี่อายุ 10 ปีแล้ว แต่ฉันอยากจะทุ่มเงิน 0.02 ดอลลาร์ของฉัน
ไม่ไม่ไม่แน่นอน
เรากำลังพูดถึงระบบ Unix ในการอ้างอิงถึงไดเร็กทอรีเองมันก็เป็นโหนดเหมือนกับที่อื่น ๆ เมื่อกล่าวถึงไดเรกทอรีมันไม่ควรที่เคยมีเฉือนใช้ Escape ในชื่อ (Ref: dirname, pwd, ~, echo $HOME, echo $PATH, เอาท์พุทจากls , et al)
เมื่อพูดถึงเนื้อหาของไดเรกทอรีที่แล้วที่คุณต้องเฉือน กล่าวls /home/karl/คือมีความเหมาะสมมากกว่าls /home/karl (FTR ฉันเกือบจะทำอย่างหลังเพราะ ... ดีขี้เกียจ)
เมื่อใช้ตัวแปรที่มีไดเร็กทอรีเพื่อสร้างเส้นทางแบบเต็มไปยังไฟล์คุณมักจะคาดหวังว่าจะรวมเครื่องหมายทับ (i., e: cp ${HOME}/test ${OTHER_DIR}/ )
มันเป็นที่คาดว่าไดเรกทอรีไม่สิ้นสุดในการเฉือน ความคาดหวังใด ๆ ที่ไดเรกทอรีลงท้ายด้วยเครื่องหมายทับนั้นผิด ดังนั้นการเพิ่มเครื่องหมายทับที่ส่วนท้ายของไฟล์*_DIRค่าของตัวแปรจะเป็นการลบล้างความคาดหวัง
สำหรับความสมบูรณ์ของแท็บความคาดหวังในที่นี้คือคุณกำลังเข้าไปในไดเร็กทอรีนั้น ดังนั้นความช่วยเหลือที่ได้รับจากการทำให้แท็บเสร็จสมบูรณ์คือการนำคุณเข้าสู่ไดเร็กทอรีนั้นเพื่อให้คุณสามารถเลือกตัวเลือกถัดไปตามเนื้อหา
(อ้างอิงจากความคิดเห็น: Filepath MisconceptionsจากTalk:Path_(computing)หน้าWikipedia ขอบคุณjohn cj )
เป็นที่น่าสังเกตว่าเพียงเพราะมันไม่ถูกต้องไม่ได้หมายความว่าเครื่องมือ / แพ็คเกจ / ไลบรารีไม่เคยทำ เป็นเหตุการณ์ที่เกิดขึ้นบ่อยเกินไปที่สิ่งเหล่านี้จะเพิ่มเครื่องหมายทับเมื่อไม่มีอยู่ ดังนั้นตามที่BevanและPaul Fแนะนำทั้งคู่เมื่อใช้เครื่องมือของบุคคลที่สามจึงเป็นการดีที่สุดที่จะลบเครื่องหมายทับที่อาจมีอยู่ในชื่อไดเรกทอรี
Unix Inodes
inode (โหนดดัชนี) เป็นโครงสร้างข้อมูลในระบบไฟล์สไตล์ Unix ที่อธิบายอ็อบเจ็กต์ระบบไฟล์เช่นไฟล์หรือไดเร็กทอรี
- https://en.wikipedia.org/wiki/Inode
มาตรฐานลำดับชั้นของระบบไฟล์
มาตรฐานสำหรับระบบปฏิบัติการยูนิกซ์ระบบแฟ้ม (ระบบแฟ้ม Hierarchy มาตรฐาน AKA FHS) แสดงให้เห็นชัดเจนว่าไดเรกทอรีไม่ได้คิดว่าเป็นเรื่องที่มีการเฉือนท้าย แต่เนื้อหาไดเรกทอรีเริ่มต้นด้วยการเฉือน (ยกเว้นเพียงนี้/เพราะเราจะไม่ได้หมายถึง ระบบไฟล์รูทโดยใช้สตริงว่าง ... และไม่ควรสร้างไฟล์ที่นั่นอีกต่อไป)
- http://www.pathname.com/fhs/pub/fhs-2.3.html
- https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
/ที่แตกรูปแบบ และถ้าคุณเริ่มหาเหตุผลจากที่นี่ (แบบวนซ้ำ) คุณจะสามารถไปถึงความขัดแย้งที่อาจเป็นหัวใจของแนวทางปฏิบัติที่แตกต่างกัน (ดังที่เห็นได้จากคำตอบที่นี่) แต่เมื่อคุณยอมรับสิ่งนี้เป็นข้อยกเว้นแล้วทุกสิ่งทุกอย่างก็จะอยู่ในแนวเดียวกัน
ใช่มันควรเป็น:
ชื่อพา ธ + ชื่อไฟล์ = ตำแหน่งไฟล์แบบเต็ม
ดังนั้นเครื่องหมายทับระหว่างไดเร็กทอรีสุดท้ายและชื่อไฟล์จะต้องอยู่ที่ท้ายชื่อพา ธ หรือจุดเริ่มต้นของชื่อไฟล์ การเติมชื่อไฟล์ด้วย / หมายความว่าคุณจำเป็นต้องคำนึงถึงสิ่งนี้หากคุณต้องการเปิดไฟล์ (เช่นหากคุณคิดว่าชื่อไฟล์ที่ไม่มีคุณสมบัติอยู่ในไดเร็กทอรีการทำงานปัจจุบัน)
เมื่อใดก็ตามที่ฉันจัดเก็บพา ธ ไดเร็กทอรีหรือส่งคืนจาก API ฉันพยายามและยึดมั่นกับหลักการรักษาเครื่องหมายทับ สิ่งนี้จะหลีกเลี่ยงความคลุมเครือ 'มันเป็นไฟล์หรือไดเรกทอรี' ทั้งหมด
ภาคผนวก :
สิ่งนี้ไม่ได้มีไว้เพื่อทดแทนการใช้วิธีการที่สามารถทนต่อการเฉือนต่อท้ายหรือการขาด แม้จะใช้การประชุมนี้ฉันก็ยังใช้Path.Combine(...)และวิธีการที่คล้ายกันเสมอ
os.path.join(dir, subdir_or_file)
บางทีคุณควรคิดว่าการตัดสินใจของคุณมีความหมายอย่างไรกับไฟล์ ถ้าคุณไม่ใส่เครื่องหมายทับท้ายชื่อไดเร็กทอรีคุณจะต้องเพิ่มลงในจุดเริ่มต้นของไฟล์ชื่อ
ตอนนี้หากด้วยเหตุผลบางประการพา ธ ที่นำไปสู่ไฟล์หายไปเมื่อคุณเชื่อมต่อสตริงคุณจะจบลงด้วยสิ่ง/filenameที่ไม่ใช่แค่ไฟล์ แต่เป็นพา ธ สัมบูรณ์จากไดเร็กทอรีราก (ไม่ว่าจะอยู่ที่ใดในบริบทนั้น) .
นั่นเป็นเหตุผลที่ฉันจบเส้นทางของฉันด้วยเครื่องหมายทับและเก็บไฟล์ไว้เป็นไฟล์
./filename. แต่โดยทั่วไปแล้วควรเป็นความรับผิดชอบของรหัสที่เชื่อมต่อเส้นทางเพื่อทำอย่างถูกต้อง - และไม่ตั้งสมมติฐานด้วยวิธีใดวิธีหนึ่ง
ฉันรู้ว่านี่เป็นกระทู้เก่า แต่ฉันคิดว่าฉันจะแบ่งปันสิ่งที่ฉันทำ ถ้าเป็นไปได้ปกติฉันจะอนุญาตทั้งสองอย่างและทำสิ่งนี้ (ถ้าเป็น PHP):
$fullPath = rtrim($directory, '/') . '/filename.txt');
ด้วยวิธีนี้หากกำหนดไดเร็กทอรีไว้ในไฟล์ config ไม่สำคัญว่าบุคคลต่อไปที่จะเปลี่ยนจะมีเครื่องหมายทับหรือไม่ก็ตาม
ใน php เนื่องจากฟังก์ชัน dirname (__ FILE __) จะส่งคืนชื่อไดเร็กทอรีโดยไม่มีเครื่องหมายทับที่ท้าย ฉันมักจะยึดติดกับแบบแผนนั้น
มิฉะนั้นการใช้เครื่องหมายทับที่ท้ายชื่อไดเร็กทอรีจะขัดแย้งกับวิธีการทำงานของ dirname (.. ) จากนั้นคุณจะติดขัดกับการจัดการทั้งสองกรณีเนื่องจากคุณไม่รู้ว่าชื่อไดเร็กทอรีมาจาก dirname (.. ) หรือเนื้อหาที่กำหนดด้วยเครื่องหมายทับ
Bottom Line:อย่าใช้เครื่องหมายทับเนื่องจาก dirname (.. ) ไม่ได้
// PHP Example
dirname(__FILE__); // returns c:\my\directory without a trailing slash, so stick to it!
สำหรับภาษาอื่น ๆ ให้ตรวจสอบฟังก์ชันที่แยกชื่อพา ธ และดูว่าใช้เครื่องหมายทับต่อท้ายหรือไม่จากนั้นให้ปฏิบัติตามหลักการของภาษา
ฉันมักจะเพิ่มเครื่องหมายทับเพราะฉันมักจะใช้ไดเร็กทอรีนั้นเพื่อเพิ่ม / ดึงไฟล์ ...
ในแง่ของการอ้างอิงเว็บมันสามารถเพิ่มประสิทธิภาพได้จริงโดยทิ้งเครื่องหมายทับไว้
ใช่มีระบบไฟล์มากมายที่รองรับไฟล์ที่ไม่มีนามสกุลใด ๆ ดังนั้นควรเพิ่มเครื่องหมายทับเพื่อหลีกเลี่ยงปัญหาใด ๆ
ฉันไม่เคยเห็นการประชุมที่มั่นคงทางใดทางหนึ่ง
ค่อนข้างแน่ใจว่าไม่ว่าคุณจะตกลงอะไรคนอื่นจะมั่นใจได้ 100% ว่าควรเป็นวิธีอื่น ดังนั้นความคิดที่ดีที่สุดคืออดทนต่อสิ่งต่างๆที่ถูกกำหนดไว้ไม่ว่าจะด้วยวิธีใดก็ตาม
ในโลก. NET Path.Combine () ให้วิธีจัดการกับสิ่งนี้ - มีสิ่งที่เทียบเท่าในสภาพแวดล้อมอื่น ๆ ตั้งแต่ไฟล์ cmd ขึ้นไป
ฉันเดาว่านี่เป็นหนึ่งในกรณีที่หายากซึ่งคำตอบที่ถูกต้องในทางทฤษฎีและในทางปฏิบัตินั้นแตกต่างกัน
ดูเหมือนว่าคำตอบของ @Karl Wilbur จะถูกต้องในแง่ทฤษฎีเนื่องจากคุณควรจะสามารถแยกแยะการอ้างอิงไปยังโหนดไดเร็กทอรีจากเนื้อหาของไดเร็กทอรีได้
แต่ในทางปฏิบัติฉันจะโต้แย้งคำตอบที่ถูกต้องตรงกันข้าม:
เหตุผลที่สำคัญที่สุดคือคุณสามารถบอกได้อย่างมั่นใจว่าเส้นทาง/home/FSObjectX/นั้นเป็นโฟลเดอร์ในขณะที่/home/FSObjectXไม่ชัดเจน ไม่มีใครบอกได้ว่านี่คือไฟล์ของโฟลเดอร์
ข้อมูลจำเพาะจะต้องแม่นยำและไม่คลุมเครือเสมอเมื่อทำได้
ในกรณีส่วนใหญ่คุณจะอ้างอิงเนื้อหาของโฟลเดอร์เสมอไม่ใช่ dir node เอง
ในกรณีที่เกิดขึ้นได้ยากเหล่านี้คุณสามารถจัดการกับโค้ดได้อย่างง่ายดายโดยการลบตัวคั่นไดร์
การใช้ตัวคั่น dir คู่จะไม่ทำอันตรายใด ๆ แม้ว่าจะขาดหายไปก็ตาม
ในทางทฤษฎีข้อโต้แย้งที่ไม่ดีเนื่องจากคุณไม่ควรเขียนโค้ดโดย "โอกาส" แต่ในทางปฏิบัติข้อผิดพลาดเกิดขึ้นและบางทีการใช้ dir-sep ต่อท้ายอาจทำให้เกิดข้อผิดพลาดรันไทม์น้อยลงเล็กน้อยสำหรับผู้ใช้ปลายทาง
อ่านหัวข้อที่น่าสนใจนี้ฉันไม่พบข้อเสียใด ๆ ของการใช้ trailing dir-sep เพียงแต่ว่ามันผิดในแง่ทฤษฎี หรือว่าฉันพลาดอะไรไป?