เหตุใด ls จึงยอมรับสวิตช์ที่ซ้ำกัน

16

ฉันอยากรู้อยากเห็น - มีความแตกต่างระหว่างls -lและls -lllllllllllllllllllllllllllll?

ผลลัพธ์ดูเหมือนจะเหมือนกันและฉันสับสนว่าทำไมจึงlsอนุญาตให้สวิตช์ซ้ำกัน นี่เป็นมาตรฐานการปฏิบัติระหว่างคำสั่งส่วนใหญ่หรือไม่?

ls options

— ไมค์บี
แหล่งที่มา

17

คำตอบสั้น ๆ :

เพราะมันถูกโปรแกรมให้ละเว้นการใช้งานหลายอย่างของการตั้งค่าสถานะ

คำตอบยาว:

ที่คุณสามารถดูในรหัสที่มาของการlsมีส่วนร่วมกับฟังก์ชั่นgetopt_long()และกรณีที่สวิทช์ขนาดใหญ่:

1648       int c = getopt_long (argc, argv,
1649                            "abcdfghiklmnopqrstuvw:xABCDFGHI:LNQRST:UXZ1",
1650                            long_options, &oi);
      ....
1654       switch (c)
1655         {
      ....
1707         case 'l':
1708           format = long_format;
1709           break;
      ....
1964     }

ฟังก์ชั่นgetopt_long()อ่านพารามิเตอร์ทั้งหมดที่กำหนดให้กับโปรแกรม ในกรณี-lที่ตัวแปรformatถูกตั้งค่า ดังนั้นเมื่อคุณพิมพ์หลาย-lllllllllตัวแปรนั้นถูกตั้งค่าไว้หลายครั้ง แต่มันไม่เปลี่ยนแปลงอะไรเลย

มันเปลี่ยนสิ่งหนึ่ง คำสั่ง switch case ขนาดใหญ่นี้ต้องรันหลายครั้งเนื่องจากมีหลาย-lแฟล็ก lsต้องการอีกต่อไปเพื่อให้เสร็จสมบูรณ์ด้วย-lธงหลายรายการ แต่คราวนี้ไม่น่าพูดถึง =)

— ความสับสนวุ่นวาย
แหล่งที่มา

11

หรือจะใช้วิธีอื่นการปฏิเสธพวกเขาจะทำงานให้โปรแกรมเมอร์มากกว่าการเพิกเฉย

— ทำเครื่องหมาย

1

+0.5 สำหรับการพูดในสิ่งที่ฉันจะพูด +0.5 สำหรับการไปยังแหล่งที่มา

— CVn

@ Mark - ทำไมมันทำงานได้มากขึ้นสำหรับโปรแกรมเมอร์?

— Ryan

@ Ryan การปฏิเสธตัวเลือกพิเศษ "l" ต้องการการติดตามจำนวนที่ได้รับและการพิมพ์ข้อความแสดงข้อผิดพลาดหากมีจำนวนมากเกินไป การเพิกเฉยตัวเลือก "l" เพิ่มเติมนั้นเพียงแค่กำหนดรูปแบบของรูปแบบเป็น "long_format" ทุกครั้งที่เห็น "l"

— ทำเครื่องหมาย

@ Mark - ฉันคิดว่ามันจะง่ายกว่าถ้าจะนับ l และถ้าเกิน 1 ให้พิมพ์ข้อผิดพลาด

— Ryan

21

เพราะมันเป็นสิ่งที่ถูกต้องที่จะทำ สมมติว่าคุณมีสคริปต์ที่ทำสิ่งที่ชอบ:

ls $LS_OPTIONS -l "$dir"

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

-lอาจไม่ใช่ตัวอย่างที่ดีที่สุดสำหรับสิ่งนี้ แต่หวังว่าคุณจะเห็นว่าแนวคิดนี้มีผลอย่างไร ตัวอย่างที่ดีกว่าคือตัวเลือกคอมไพเลอร์$CFLAGSซึ่งอาจทำซ้ำตัวเลือกที่ชัดเจนในการเรียกใช้คอมไพเลอร์โดยเฉพาะ

— R .. GitHub หยุดช่วยน้ำแข็ง
แหล่งที่มา

4

สิ่งเดียวกันอาจเกิดขึ้นได้เช่นกันหากคุณกำหนดนามแฝงซึ่งเรียกlsด้วยตัวเลือกบางชุด

— kasperd

1

@kasperd: ใช่ แม้ว่าวาง-lในของคุณlsนามแฝงดูเหมือนความคิดที่ไม่ดีปัญหาเดียวกันมีแนวโน้มที่จะเกิดขึ้นกับตัวเลือกที่มีความสุขในการโต้ตอบlsนามแฝงเหมือนหรือ-p --color=auto

— . GitHub หยุดช่วยน้ำแข็ง

1

lsนามแฝงไม่ได้จะเรียกว่า llอาจจะเป็นนามแฝงสำหรับและในระบบที่มีนามแฝงว่าผมอาจจะพิมพ์ls -l ll -lart

— kasperd

11

lsไม่ได้เป็นbashคำสั่ง bashแต่ปฏิบัติการที่แยกต่างหากที่คุณจะเกิดขึ้นจากการเปิดตัว ที่กล่าวว่า-lเป็นเพียงประเภทของธงบูลีนซึ่งหากปัจจุบันทำให้เกิดlsการใช้รูปแบบยาวสำหรับการส่งออก โปรแกรมส่วนใหญ่จะเพิกเฉยต่อการใช้งานหลายครั้ง ( ls -llเหมือนกันls -l -l) ของแฟล็กดังกล่าวแม้ว่าจะมีข้อยกเว้นบางอย่าง (ตัวอย่างเช่นถ้า-vหมายถึง 'verbose' จากนั้นโปรแกรมอาจตีความการใช้งานหลายครั้งเพื่อแปลว่า

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

2

ตัวอย่างของการมี-vvv ssh

— แบร์นฮาร์ด

หรือแม้กระทั่งaptitude moo

— รุสลัน

8

ชื่อแทนของเชลล์จะค่อนข้างน่ารำคาญหากคำสั่งเช่นlsนั้นไม่อนุญาตให้ใช้ตัวเลือกซ้ำ ๆ

สมมติว่าคุณมี

alias ls='ls --color=auto'
alias rm='rm -i'

แล้วถ้าธงที่ขัดแย้งกันไม่ได้รับอนุญาตก็จะเกิดข้อผิดพลาดในการออกคำสั่งเช่นls --color=neverหรือหรือls --color=autorm -i

ดังนั้นคำสั่งเหล่านี้ถูกออกแบบมาเพื่อให้การตั้งค่าสถานะในภายหลังแทนที่คำสั่งก่อนหน้านี้

— 200_success
แหล่งที่มา

สวิตช์ที่ขัดแย้งกันบางครั้งไม่ได้รับอนุญาต (ลองใช้ rsync กับทั้งคู่--inplaceและ--delay-updatesตัวอย่าง) เครื่องมือบางอย่างใช้สิ่งใดก็ตามที่ผ่านมา rm -ifอาจเป็นตัวอย่างที่ดีที่นั่น แต่ไม่มีความขัดแย้งในตัวเลือก ls ของ ls ดังนั้นls -lและls -llไม่ใช่ปัญหาและไม่มีผลต่อการดำเนินการในลักษณะที่สำคัญใด ๆ คอมพิวเตอร์ทำซ้ำได้ดี

— CVn