จะ“ หัก” ไฟล์ชื่อ“ -” ได้อย่างไร?

ฉันสร้างไฟล์โดยใช้ชื่อ-(เช่นseq 10 > -) โดยไม่ตั้งใจ จากนั้นฉันก็ลองใช้lessดู แต่มันก็แค่แฮงค์

ฉันเข้าใจว่าสิ่งนี้เกิดขึ้นเพราะless -คาดว่าจะป้อนข้อมูลจากstdinดังนั้นจึงไม่ตีความ-ว่าเป็นชื่อไฟล์ ฉันพยายามless \-แต่มันก็ไม่ทำงานเหมือนกัน

ดังนั้นมีวิธีใดบ้างที่ระบุlessว่า-เป็นไฟล์ไม่ใช่ stdin?

สิ่งที่ดีที่สุดที่ฉันจะได้รับคือ:

find -name '-' -exec less {} +

less stdin

— fedorqui
แหล่งที่มา

@muru ขอบคุณสำหรับความคิดเห็น แต่สิ่งที่ซ้ำกันที่เป็นไปได้นั้นเฉพาะเจาะจงที่ฉันไม่คิดว่ามันมีคุณสมบัติที่จะ "ซ้ำซ้อน" หากมีการใช้ถ้อยคำซ้ำ ๆ กับสิ่งที่ธรรมดากว่าเช่น "วิธีเข้าถึงไฟล์ที่ขึ้นต้นด้วย" - "" อาจจะ

— fedorqui

นั่นไม่ใช่คำถามที่ซ้ำกัน กรณีสำหรับ-คนเดียวจะแตกต่างกัน -ไม่ใช่ตัวเลือก

— Stéphane Chazelas

@terdon ฉันไม่คิดว่าการมีคำตอบเดียวกันโดยตรงหมายความว่าพวกเขาซ้ำซ้อน มีบางตัวอย่างใน Meta SO: หากคำถามได้รับคำตอบด้วย "ไม่" สิ่งใดที่คำตอบที่ถูกต้องคือ "ไม่" จะซ้ำกันหรือไม่ อย่างที่ฉันได้พูดไปก่อนหน้านี้มันน่าสนใจที่จะใส่คำซ้ำให้กับผู้สมัครที่ซ้ำกัน ไม่อย่างนั้นมันไม่สมเหตุสมผลเลยที่จะส่งคำถามอื่นเช่นนี้

— fedorqui

@terdon ไม่ ทางออกที่ยอมรับไม่สามารถใช้งานได้ที่นี่ และไม่-ไม่ถือว่าเป็นตัวเลือกนั่นเป็นปัญหาที่แตกต่างอย่างสิ้นเชิงจากกรณีของการขัดแย้งที่มีรูปร่างเหมือนตัวเลือก

— Stéphane Chazelas

ไม่จำเป็นต้องใส่-ระหว่างเครื่องหมายอัญประกาศเดี่ยวเช่น'-'หรือยกเว้น\-เพราะ-มันไม่ใช่อักขระพิเศษสำหรับเชลล์ทั่วไป (อย่างน้อยที่สอดคล้องกับ POSIX) ผลลัพธ์จะเหมือนกัน

— pabouk

คำตอบ:

เพียงนำหน้าด้วย./:

less ./-

หรือใช้การเปลี่ยนเส้นทาง:

less < -

โปรดทราบว่าตั้งแต่-(ตรงข้ามกับ-xหรือ--foo--ตัวอย่าง) ถือว่าเป็นชื่อไฟล์พิเศษแทนที่จะเป็นตัวเลือกสิ่งต่อไปนี้ใช้ไม่ได้:

less -- -   # THIS DOES NOT WORK

— ฮาวเวิร์ด
แหล่งที่มา

BTW นั่นคือสิ่งที่find -name '-' -exec less {} +ทำงาน

— Stéphane Chazelas

@fedorqui ไม่ว่าจะเป็นแค่นั้น-และ./-(หรือ/path/to/-หรือ../to/-) เป็นสองเส้นทางที่ถูกต้องไปยัง-ไฟล์นั้น แต่-อาร์กิวเมนต์เป็นพิเศษถึงless(หมายถึงอ่านจาก stdin) ในขณะที่./-ไม่ได้เป็นพิเศษ

— Stéphane Chazelas

@fedorqui เป็นรูปแบบที่ไม่ได้มาตรฐานfind -name '-' -exec less {} + find . -name '-' -exec less {} +มันให้สิ้นซากต้นไม้ที่และพบว่าไฟล์และผ่านเส้นทางของไฟล์เหล่านั้นเป็นข้อโต้แย้ง. lessแทนที่-exec lessด้วย-exec echo lessเพื่อดูสิ่งที่กำลังทำงาน

— Stéphane Chazelas

@haylem --คือการทำเครื่องหมายสิ้นสุดตัวเลือก มันจะไม่ช่วยที่นี่ นั่น-ไม่ใช่ตัวเลือกมันเป็นอาร์กิวเมนต์ที่ไม่ใช่ตัวเลือกพิเศษ ดูเพิ่มเติมที่unix.stackexchange.com/a/56370 , unix.stackexchange.com/a/110756

— Stéphane Chazelas

@ Haylem ลองด้วยตัวคุณเอง --ได้รับการจัดการโดย getopt () เพื่อทำเครื่องหมายจุดสิ้นสุดของตัวเลือกที่-ไม่ได้รับการยอมรับว่าเป็นตัวเลือกโดย getopt () เพื่อที่-จะได้รับการยอมรับว่าเป็นข้อโต้แย้งปกติไม่ว่า--จะมีให้หรือไม่ และเป็นอาร์กิวเมนต์ปกติlessเช่นโปรแกรมอรรถประโยชน์ข้อความส่วนใหญ่จะถือว่าเป็นความหมาย stdin ซึ่งเราไม่ต้องการที่นี่

— Stéphane Chazelas

mv - f && less fฉันจะเป็นเพียงแค่ แก้ไขปัญหา.

— snth
แหล่งที่มา

ดีงานนี้แม้ว่ามันจะทำให้ผมนึกถึงเกี่ยวกับองค์การนาซ่าใช้จ่ายหลายล้านเพื่อพัฒนาปากกาที่จะเขียนในอวกาศในขณะที่ Cosmonauts โซเวียตใช้ดินสอ ฉันคิดว่าเราสามารถลงทุนเพื่อการวิจัยเล็กน้อยที่นี่

— fedorqui

+1 ทำไมทำให้สิ่งต่าง ๆ ซับซ้อนหากมีวิธีแก้ไขปัญหาที่ง่าย

— Mhmd

หมายเหตุ:คำตอบของฉันไม่ถูกต้องในกรณีของ OP และใช้เฉพาะกับเครื่องมือตามแบบแผนที่ระบุไว้ด้านล่างและไม่ได้อยู่ในกรณีของไฟล์ที่ชื่อ just -(dash) ซึ่งมักจะเป็นกรณีพิเศษเพื่อระบุว่าการอ่านจากมาตรฐาน คาดว่าอินพุต ดูคำตอบที่ยอมรับได้

ออกจากที่นี่เนื่องจากมีข้อมูลที่เป็นประโยชน์สำหรับกรณีอื่น ๆ ที่อาจสะดุดเมื่อค้นหาคำตอบ

รีบอีกครั้ง!

ใช้การประชุม double-dash ( --) มาตรฐานเพื่อระบุอาร์กิวเมนต์ล่าสุด:

less -- -FILENAME

ตัวอย่าง

$ echo "meh" > -badname
$ less -badname
Number is required after -b
$ less -- -badname # GREAT SUCCESS!

Whhhaattt?

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

แนะนำโดย Open Group

OpenGroup ยังกล่าวถึงในส่วนคำอธิบายโปรแกรมอรรถประโยชน์คำอธิบาย (v6) ของข้อมูลจำเพาะพื้นฐานของมัน:

พฤติกรรมเริ่มต้น: [... ] ยูทิลิตี้มาตรฐานที่ไม่ยอมรับตัวเลือก แต่ที่ยอมรับตัวถูกดำเนินการจะต้องรับรู้ "-" เป็นอาร์กิวเมนต์แรกที่จะถูกทิ้ง

ข้อกำหนดสำหรับการรับรู้ "-" เป็นเพราะการใช้งานที่สอดคล้องกันจำเป็นต้องมีวิธีการป้องกันตัวถูกดำเนินการจากตัวเลือกโดยพลการใด ๆ ที่การดำเนินการอาจให้เป็นส่วนขยาย ตัวอย่างเช่นถ้ารายการยูทิลิตี้มาตรฐาน foo แสดงว่าไม่มีตัวเลือกและแอปพลิเคชันที่จำเป็นต้องให้ชื่อพา ธ ที่มียัติภังค์ชั้นนำมันสามารถทำได้อย่างปลอดภัยดังนี้:
foo -- -myfile
และหลีกเลี่ยงปัญหาใด ๆ กับ -m ที่ใช้เป็นส่วนขยาย

และในหลักเกณฑ์ไวยากรณ์ของยูทิลิตี้ (v7):

หลักเกณฑ์ 10: ข้อแรก - อาร์กิวเมนต์ที่ไม่ใช่ตัวเลือกอาร์กิวเมนต์ควรได้รับการยอมรับเป็นตัวคั่นที่ระบุถึงจุดสิ้นสุดของตัวเลือก อาร์กิวเมนต์ใด ๆ ต่อไปนี้ควรถือเป็นตัวถูกดำเนินการแม้ว่าจะเริ่มต้นด้วยอักขระ '-'

แนะนำโดย Bash

ที่นี่คัดลอกมาจากคู่มือทุบตีเกี่ยวกับ builtins ของมันสนับสนุน:

เว้นแต่จะระบุไว้เป็นอย่างอื่นคำสั่ง builtin แต่ละตัวจะบันทึกไว้ในส่วนนี้ว่ายอมรับตัวเลือกที่นำหน้าด้วย - ยอมรับ - เพื่อบ่งบอกถึงจุดสิ้นสุดของตัวเลือก

บิวด์อิน:, จริง, เท็จและทดสอบไม่ยอมรับตัวเลือกและไม่ควรปฏิบัติต่อ - เป็นพิเศษ exit, logout, break, continue, let และ shift builtins ยอมรับและประมวลผลอาร์กิวเมนต์ที่ขึ้นต้นด้วย - โดยไม่ต้อง - บิวด์อินอื่นที่ยอมรับอาร์กิวเมนต์ แต่ไม่ได้ระบุว่าเป็นตัวเลือกการยอมรับตีความอาร์กิวเมนต์ที่ขึ้นต้นด้วย - เป็นตัวเลือกที่ไม่ถูกต้องและจำเป็นต้องมี - เพื่อป้องกันการตีความนี้

โปรดทราบว่าเสียงก้องไม่ได้แปล - หมายถึงจุดสิ้นสุดของตัวเลือก

อ่านเพิ่มเติม

— haylem
แหล่งที่มา

+1: โซลูชันแบบพกพาและเป็นอิสระจากคำสั่งส่วนใหญ่ง่ายต่อการจดจำและพิจารณา "แนวทางปฏิบัติที่ดีที่สุด"

— mveroone

@Kwaio มีการอ้างอิงเกี่ยวกับ "แนวปฏิบัติที่ดีที่สุด" ไหม? แค่รู้สึกอยากรู้เกี่ยวกับมัน

— fedorqui

คำตอบนั้นใช้กับข้อโต้แย้งที่ดูเหมือนตัวเลือก ไม่ใช่กรณี-ที่ไม่มีตัวเลือก การใช้./-หรือการเปลี่ยนเส้นทางเมื่อเป็นไปได้โดยทั่วไปเป็นวิธีการที่ดีที่สุดเท่าที่จะหลีกเลี่ยงชนิดอื่น ๆ ของปัญหาเช่นfoo=barของหรือว่าawk -ดูเพิ่มเติมที่unix.stackexchange.com/a/56370 , unix.stackexchange.com/a/110756

— Stéphane Chazelas

ในฐานะที่เป็นStéphaneกล่าวนี้ไม่ตอบคำถาม จะยังคงพยายามอ่านจาก stdin less -- -

— Michał Politowski

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

— Stéphane Chazelas