ดำเนินการเป็น. test แทน. / Test

26

หากว่าฉันอยู่ในโฟลเดอร์เดียวกับไฟล์ที่เรียกใช้งานได้ฉันจะต้องพิมพ์สิ่งนี้เพื่อเรียกใช้งาน:

./file

ฉันไม่ต้องการพิมพ์/เพราะ/ยากสำหรับฉันที่จะพิมพ์

มีวิธีที่ง่ายกว่าในการเรียกใช้ไฟล์หรือไม่? เป็นการดีที่จะมีไวยากรณ์ง่ายๆเช่น:

.file

หรืออย่างอื่นนอกจากง่ายกว่าต้องใส่/ตัวอักษรตรงนั้น

อาจมีวิธีใส่บางอย่างใน/binไดเรกทอรีหรือสร้างนามแฝงสำหรับล่ามเพื่อที่ฉันจะได้ใช้:

p file

filenames executable

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

9

อาจจะสลับ / ด้วยคีย์อื่นโดยใช้ xmodmap? อย่างน้อยก็ง่ายกว่าที่จะพิมพ์

— Guy

26

ในฐานะที่เป็นบันทึกด้านข้าง/มีการใช้อย่างกว้างขวางใน Unix ส่วนใหญ่เป็นตัวคั่นไดเรกทอรี คุณน่าจะหาวิธีที่ง่ายกว่าในการพิมพ์

— chrylis -on strike-

7

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

— JFA

1

@JFA รูปแบบแป้นพิมพ์ส่วนใหญ่ที่ใช้ในทวีปยุโรปและอเมริกาใต้วาง/shift-7 ซึ่งค่อนข้างยากที่จะพิมพ์แม้ว่าจะไม่ได้รับบาดเจ็บก็ตาม

— nitro2k01

6

แก้ไขประวัติ: " ทำไมจึงไม่สามารถสั่งการเชื่อมต่อเครือข่ายเพื่อทำการสืบค้นอินเทอร์เน็ตทั้งหมดผ่านรีโมตโฮสต์ผ่าน ssh บนพอร์ต 22 "

— ಠ_ಠ

35

อาจเป็น "ความเสี่ยง" แต่คุณสามารถมีได้ ในเส้นทางของคุณ

ตามที่ได้กล่าวไว้ในที่อื่นสิ่งนี้อาจเป็นอันตรายได้เสมอ อยู่ที่จุดสิ้นสุดของ PATH แทนที่จะเป็นจุดเริ่มต้น

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

1

อย่ามองว่ามันเป็น "ความเสี่ยง": เส้นทางของฉันเป็นอย่างนั้นมานานก่อน linux และมันไม่เคยทำให้เกิดปัญหาน้อยที่สุด

— jamesqf

21

@jamesqf มีความเสี่ยงเพราะถ้าคุณcdไปยังไดเรกทอรีที่เขียนได้ทั่วโลกและลองใช้คำสั่งที่ไม่ได้อยู่ในเส้นทางของคุณคุณอาจสั่งให้ปฏิบัติการ (อาจเป็นอันตราย) ด้วยชื่อเดียวกันกับที่คนเขียนไปยังเส้นทางนั้น มันแย่กว่านี้ถ้าคุณใส่.จุดเริ่มต้นของเส้นทางของคุณ ในกรณีดังกล่าวการเรียกใช้งานที่เป็นอันตรายที่เรียกว่าlsจะถูกดำเนินการหากคุณพยายามโทรlsในไดเรกทอรีนั้น

— bytesized

2

โปรดหลีกเลี่ยงสิ่งนี้ด้วยเหตุผลที่ระบุไว้ข้างต้น pคำสั่งจะดีกว่า

— กุยโด้

11

@jamesqf เมื่อเป็นระบบ "ของคุณ" และมีเพียงคุณเท่านั้นที่ใช้มันไม่ได้แย่ขนาดนั้น ปัญหาเกิดขึ้น (และมีผู้ดูแลระบบ Unix หลายคนในช่วงหลายปีที่ผ่านมา) บนระบบผู้ใช้หลายคน เมื่อ.เริ่มต้นPATHผู้ใช้ที่เป็นอันตรายทั้งหมดต้องทำคือวางlsคำสั่งปลอมในไดเรกทอรีของพวกเขาและชักชวนให้ผู้ดูแลระบบ "ดูสิ่งที่แปลก" และพวกเขาเข้าถึงรูทได้

— TripeHound

1

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

— yellowantphil

71

.จะป้อนอัตโนมัติให้กับ./ (พิมพ์.และกดTab) อย่างน้อยในเชลล์ Bash สมัยใหม่ดังนั้นคุณไม่ควรใช้PATHโซลูชันที่ซับซ้อนหรือไม่ปลอดภัย (เช่นการดัดแปลง)

หากยังไม่เสร็จสมบูรณ์โดยอัตโนมัติคุณอาจต้องติดตั้งแพคเกจ "bash-completion"

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

คุณแน่ใจไหม? .มีผู้สมัครที่เสร็จสมบูรณ์หลายคน: .(ปัจจุบัน dir), ..(ผู้ปกครองหลัก), .คำสั่ง (ซึ่งทุบตีให้นามแฝงที่ไม่เป็นมาตรฐานsourceสำหรับ) และ dotfiles ใด ๆ ที่มีอยู่ บางทีbash-completionแพ็คเกจจะไม่สนใจสิ่งนี้ ฉันพบว่ามันน่ารำคาญอย่างยิ่ง (เช่นทำให้เป็นไปไม่ได้ที่จะแท็บชื่อ dir ที่สมบูรณ์ในmakeบรรทัดคำสั่งและโดยทั่วไปแล้วน่ากลัวกับ makefiles ที่เต็มไปด้วยกฎเกณฑ์โดยปริยาย) ดังนั้นฉันจึงล้างมันเสมอ

— . ..

3

ฉันลองแล้วใช่มันจะทำให้เป็นแบบอัตโนมัติโดยสมบูรณ์ ในเกือบทุกกรณีนั่นคือสิ่งที่ผู้ใช้ทั่วไปต้องการ: ฉันไม่คิดว่าฉันเคยเห็น dotfile ที่ควรใช้งานได้การรันบางอย่างในไดเรกทอรีย่อยนั้นมีความธรรมดามากกว่าการใช้บางอย่างในไดเรกทอรีหลักและ IMO ก็ทำเช่นนั้น งานที่ดีในการค้นหาmakeเป้าหมาย

— l0b0

ด้วย bash 3.2 มันไม่ได้เติมข้อความอัตโนมัติ นี่อาจเป็นสิ่งใหม่ใน bash 4 หรือไม่

— Calimo

2

@Calimo มีแนวโน้มใหม่ใน bash-completion เวอร์ชั่นล่าสุด มันไกลจากการเปลี่ยนแปลงพื้นฐาน

— l0b0

42

หรือ .. บางทีให้ล่ามชื่อแทนในไฟล์ bashrc แล้วก็ง่ายๆ
   p  file

เป็นไปได้ที่จะเขียนฟังก์ชันดังกล่าว:

p() {
 ./"$@"
}

~/.bashrcในของคุณ แล้วคุณจะสามารถทำงานแทนp app arguments ./app argumentsวิธีนี้ใช้ได้กับไฟล์ประเภทใดก็ได้รวมถึงสคริปต์และไบนารี

"$@"ขยายไปยังรายการอาร์กิวเมนต์ที่ยกมาอย่างเหมาะสมผ่านไปยังฟังก์ชั่น (รักษาอักขระพิเศษทั้งหมดจาก glob หรือการขยายตัวตัวแปร) และตามที่ @Scott ชี้ให้เห็นว่าbashฉลาดพอที่จะเพิ่ม./ไปยังส่วนแรกของพวกเขารักษาส่วนที่เหลือ

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

แม้ว่าจะใช้งานทั่วไปน้อยกว่าสำหรับการเรียกใช้แอปภายใต้คำสั่งอื่นเช่นต้องการstrace -f p appดูการโทรของระบบหรือ$(which time) p appดูว่าใช้เวลานานเท่าใด pในฐานะสคริปต์ที่ใช้งานได้จะทำงานได้ดีขึ้นในสองตัวอย่างที่ฉันคาดการณ์ไว้ วิธีการแก้ปัญหาไม่สามารถทำงานร่วมกับldd p appแม้จะldd ยังมีความแตกต่างในการกำหนดเส้นทางแบบเต็มอาจจะด้วยเหตุผลเช่นนี้

— sourcejedi

ใช่แทนที่p app argsด้วย./app argsในทางที่มองไม่เห็นให้กับทุกคนจะต้องมีท่อป้อนข้อมูลผ่านเปลือกชนิดของ preprocessor บางอย่างและจะทำให้ทุกประเภทของสนุกเมื่อเปลี่ยนตัวเกิดขึ้นในสถานที่ที่ไม่ได้ตั้งใจ :)

— aitap

1

ในกรณีนี้ไม่ควรจะมีคำพูดที่ไม่มีรอบ$@? มิฉะนั้นจะส่งผ่านอาร์กิวเมนต์ใหญ่หนึ่งรายการไปยังโปรแกรม

— Kroltan

7

@ Kroltan ไม่$@เป็นอาร์เรย์ เมื่อขยายภายใน"พารามิเตอร์แต่ละตัวจะขยายเป็นคำแยกต่างหาก $*ทำงานในแบบที่คุณคิด

— 8bittree

3

ฉันเชื่อว่าคุณทำให้สิ่งนี้ซับซ้อนโดยไม่จำเป็นและนั่นp() { ./"$@"; }คือทั้งหมดที่คุณต้องการ

— สกอตต์

11

คุณสามารถใส่.ของคุณ$PATHโดยเพิ่มเช่นPATH=$PATH:.ของคุณ/etc/profileด้วยวิธีนี้คุณสามารถดำเนินการfileโดยการเขียนfileเว้นแต่จะอยู่ในโฟลเดอร์อื่น ๆ ในเส้นทางของคุณ (เช่น/usr/bin/) โปรดทราบว่านี่ไม่ใช่ความคิดที่ดี

เหตุใดจึงไม่ดี: สมมติว่าคุณอยู่ในสถานการณ์ที่คุณไม่ไว้วางใจเนื้อหาของไดเรกทอรีอย่างเต็มที่ - คุณดาวน์โหลดมาจากที่อื่นและคุณต้องการตรวจสอบก่อนเรียกใช้หรือคุณเป็นผู้ดูแลระบบ ผู้ใช้โดยค้นหาในโฮมไดเร็กตอรี่ของคุณ, ฯลฯ . คุณต้องการแสดงรายการไดเร็กตอรี่, ดังนั้นคุณลองพิมพ์ ls, แต่โอ๊ะโอ, คุณพิมพ์ผิด, และจบลงด้วยการพิมพ์ sl แทน. ผู้เขียนของไดเรกทอรีที่เป็นอันตรายนี้คาดหวังสิ่งนี้และวางเชลล์สคริปต์ไว้ในชื่อ "sl" ซึ่งรัน 'rm -rf --no-keep-root /' (หรือสิ่งที่เป็นอันตรายมากกว่าเช่นการติดตั้ง rootkit)

(ขอบคุณ @Muzer สำหรับคำอธิบาย)

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

13

แม้ว่าฉันจะเห็นด้วยอย่างเต็มที่มันอาจจะอธิบายได้อย่างชัดเจนว่าทำไมนี่จึงไม่ใช่ความคิดที่ดี

— ymbirtt

16

เหตุใดจึงไม่ดี: สมมติว่าคุณอยู่ในสถานการณ์ที่คุณไม่ไว้วางใจเนื้อหาของไดเรกทอรีอย่างเต็มที่ - คุณดาวน์โหลดมาจากที่อื่นและคุณต้องการตรวจสอบก่อนเรียกใช้หรือคุณเป็นผู้ดูแลระบบ ผู้ใช้โดยค้นหาในโฮมไดเร็กตอรี่ของคุณ, ฯลฯ . คุณต้องการแสดงรายการไดเร็กตอรี่, ดังนั้นคุณลองพิมพ์ ls, แต่โอ๊ะโอ, คุณพิมพ์ผิด, และจบลงด้วยการพิมพ์ sl แทน. ผู้เขียนของไดเรกทอรีที่เป็นอันตรายนี้คาดหวังสิ่งนี้และวางเชลล์สคริปต์ไว้ในชื่อ "sl" ซึ่งรัน 'rm -rf --no-keep-root /' (หรือสิ่งที่เป็นอันตรายมากกว่าเช่นการติดตั้ง rootkit)

— Muzer

2

ควรอธิบายว่าหากไดเรกทอรีปัจจุบันอยู่ที่จุดเริ่มต้นของ $ PATH แต่ผู้โจมตีสามารถแทนที่คำสั่ง ls หรือคำสั่งทั่วไปอื่น ๆ ได้

— Délisson Junio

@Muzer Huuugeหมวกเหล็กวิลาดที่นี่

— Sombrero Chicken

4

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

— Muzer

10

คุณสามารถโทรหาล่ามได้เช่น

bash test

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

#!/usr/bin/env python3

คุณจะโทร

python3 test

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

7

ล่ามเพียงตีความรหัสพวกเขาจะไม่เรียกใช้ไฟล์ไบนารี

— Mc Kernel

คำตอบนี้ค่อนข้างสมเหตุสมผลเพราะบางทีล่ามสามารถให้นามแฝงในไฟล์ bashrc

5

@McKernel จุดที่ดีก็ทำงานได้เฉพาะในกรณีที่มีล่ามไม่ได้สำหรับ executables เรียบเรียง

— Zanna

2

มีล่ามสำหรับไฟล์ประมวลผลที่รวบรวมได้:/lib/ld.so

— Dmitry Kudriavtsev

7

เท่าที่ฉันรู้ไม่มีวิธีที่จะทำให้มันประสบความสำเร็จเว้นแต่คุณจะรวมไฟล์ในเส้นทาง env ดังนั้นคุณสามารถเรียกใช้มันเพียงแค่พิมพ์: file

.fileจะไม่ทำงานเนื่องจากเป็นชื่อไฟล์อื่น มันเป็นไฟล์ที่เรียกว่าไม่.file./file

ฉันรู้สึกว่าสแลชอาจพิมพ์ยากสำหรับคุณเพราะเลย์เอาต์ที่ไม่ใช่ภาษาอังกฤษใช่มั้ย ในกรณีนั้นมันก็เกิดขึ้นกับฉันดังนั้นฉันมักจะสลับเค้าโครงแป้นพิมพ์เป็นภาษาอังกฤษโดยกด Alt + Shift ใน Windows (ฉันใช้ Linux จาก ssh)

— Mc Kernel
แหล่งที่มา

7

มีคนแนะนำให้เพิ่ม.การPATHซึ่งเป็นอันตรายเพราะมันสร้างความเสี่ยงที่คุณตั้งใจจะเรียกใช้โปรแกรมที่เป็นอันตรายปลูกในไดเรกทอรีโลกเขียน แต่ถ้าคุณมีโปรแกรมที่ปฏิบัติการได้ในบางไดเรกทอรีที่คุณเป็นเจ้าของและเขียนได้โดยตัวคุณเองเท่านั้นมันปลอดภัย (ค่อนข้างปลอดภัยหรือไม่?) ที่จะนำผู้กำกับ (IES) เหล่านั้นเข้ามาPATHด้วยการเพิ่มบรรทัดเช่น

PATH=$PATH:~/dev/myprog1:~/dev/myprog2

ไปยัง~/.bashrcไฟล์ของคุณ หลักสูตรนี้หมายความว่าคุณสามารถเรียกใช้โปรแกรมจากหนึ่งในไดเรกทอรีเหล่านั้นได้จากทุกที่ในระบบไฟล์ ตัวอย่างเช่นคุณสามารถcd /etcพิมพ์และมันจะทำงานfoo ~/dev/myprog1/fooนี่เป็นข้อเสียเปรียบเล็กน้อยที่คุณไม่สามารถมีโปรแกรมด้วยชื่อเดียวกันในไดเรกทอรีมากกว่าหนึ่งรายการ โดยเฉพาะถ้าคุณมีโปรแกรมที่เรียกfoo ทั้งคู่~/dev/myprog1และ~/dev/myprog2คุณจะไม่สามารถรันโปรแกรมที่สองยกเว้นโดยระบุพา ธ เช่นเดียวกันถ้าคุณมี~/dev/myprog1/cat- แต่ทำไมคุณถึงต้องการ?

อีกวิธีหนึ่งถ้าคุณมีเพียงไม่กี่โปรแกรมที่คุณทำเช่นนี้คือการกำหนดนามแฝงสำหรับพวกเขา:

alias gizmo='./gizmo'
alias gonzo='./gonzo'

หรือคุณสามารถโทรหาชื่อแทน.gizmoและ.gonzo หากคุณพบว่าใช้งานง่ายกว่า

จริงนี้มีขอบเขตความเสี่ยงด้านความปลอดภัยเช่นเดียวกับการใส่เข้าไปในของคุณ. PATHหากผู้ใช้ที่เป็นอันตรายสามารถอ่านของคุณ.bashrcและดูนามแฝงของคุณจากนั้นเขาอาจใส่มัลแวร์ที่เรียกว่าgizmoและgonzoในไดเรกทอรีสุ่มด้วยความหวังว่าคุณจะเรียกใช้ การใช้ชื่อพา ธ สัมบูรณ์เหล่านี้ดีกว่า:

alias gizmo='~/dev/myprog1/gizmo'
alias gonzo='~/dev/myprog2/gonzo'

โดยวิธีการที่คุณควรหลีกเลี่ยงการตั้งชื่อปฏิบัติการtestเพราะนั่นคือคำสั่ง shell builtin และคุณสามารถเรียกใช้โปรแกรมด้วยชื่อนั้นเท่านั้นโดยการระบุเส้นทางหรือเคล็ดลับอื่น ๆ

— G-Man กล่าวว่า 'Reinstate Monica'
แหล่งที่มา

หรือคุณสามารถทำให้สูตร (ถ้าคุณใช้ Makefiles ที่มี) และทำหรือmake gizmo make gonzo

— ihato

ฉันขอโทษ แต่ฉันไม่แน่ใจว่าฉันเข้าใจว่าเกี่ยวข้องกับคำถามหรือคำตอบของฉันอย่างไร คุณแนะนำให้ OP สร้าง a Makefileในแต่ละไดเรกทอรีเพื่อให้การดำเนินการmake gizmoสิ้นสุดโดยการรัน gizmoหรือไม่ (1) ดูเหมือนว่าจะเป็นวิธีที่น่าอึดอัดใจในการทำสิ่งเดียวกันกับpฟังก์ชั่นที่เสนอในคำถามโดยเริ่มจาก aitapและได้รับการปรับปรุงโดย Scott (2) คุณสามารถส่งผ่านข้อโต้แย้งด้วยวิธีนี้ได้หรือไม่? ISTM ที่เทียบเท่ากับmake gizmo arg1 arg2 make gizmo; make arg1; make arg2

— G-Man กล่าวว่า 'Reinstate Monica'

1

(1) บางทีสมมติฐานของฉันคือผิด แต่มันไม่ได้เป็นที่ชัดเจนกับผม OP ต้องการสละจากการใช้./ในทุกไดเรกทอรี ในใจของฉันเขากำลังพัฒนาบางสิ่งบางอย่างและเพียงต้องการเรียกใช้โปรแกรมที่ผลิต./fileบ่อยๆ ผมไม่สามารถคิดว่าสถานการณ์อื่น ๆ ที่หนึ่งบ่อยครั้งจะต้องมีการเรียกใช้แฟ้มท้องถิ่นและถ้าเขาไม่ได้ทำงานอยู่บ่อยๆเขาจะไม่รำคาญถามคำถาม (เขากล่าวว่ายากที่ไม่ได้เป็นไปไม่ได้ ) (2) ไม่ได้จริงๆแต่ คุณสามารถส่งผ่านข้อโต้แย้งในสูตร

— ihato

(1) ฉันเดาว่าเราสามารถยอมรับว่าแรงจูงใจของ OP และขอบเขตของคำถามของเขาไม่ชัดเจน (2) ขอบคุณสำหรับลิงค์

— G-Man กล่าวว่า 'Reinstate Monica'

3

หากต้องการขยายคำตอบของ Zanna เกี่ยวกับล่าม (ขออภัยไม่มีตัวแทนสำหรับความคิดเห็น): "ล่าม" สำหรับไฟล์สั่งการดั้งเดิม (ไฟล์ไบนารี ELF ไบนารี) เป็นตัวโหลดแบบไดนามิก ( ld.so) แต่โดยทั่วไปแล้วไม่เข้าใจไวยากรณ์ที่คุณต้องการ:

$ /usr/lib/ld-linux-x86-64.so.2 program
program: error while loading shared libraries: program: cannot open shared object file
$ /usr/lib/ld-linux-x86-64.so.2 ./program
<program is launched>

(เช่นถ้าคุณเชื่อมโยงld.soเส้นทางของคุณคุณยังต้องเขียน/)

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

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

— phk

2

@phk ไฟล์นี้ใช้เฉพาะกับ Linux แต่แนวคิดของตัวเชื่อมโยงแบบไดนามิก / ตัวโหลดไม่ใช่ ยกตัวอย่างเช่น FreeBSD /libexec/ld-elf.so.1มีของตัวเองมาก บน Linux มันไม่ง่ายอย่าง "ตัดสินใจเลือกไบนารี": binfmt_miscตรวจจับรูปแบบของไฟล์ด้วยหมายเลขเวทย์มนตร์ (ELF, shebang script, CIL) หลังจากนั้นbinfmt_elfจะเรียกตัวจัดการ มันแยกวิเคราะห์ส่วนหัวและส่วนต่างๆของ ELF; .interpส่วนมีเส้นทางของตัวโหลดแบบไดนามิก; รถตักดินนี้จะเริ่มต้นโดย kernel _startไม่ย้ายและกระโดดไป บน FreeBSD (ไม่แน่ใจเกี่ยวกับคนอื่น) ไม่มี binfmt แต่หลักการคือ +/- คล้ายกัน

— bacondropped

1

@phk เพื่ออธิบายว่าทำไมจึงใช้งานได้ - ld.soไม่มี.interpและเชื่อมโยงแบบสแตติกซึ่งหมายความว่ามันไม่จำเป็นสำหรับตัวเชื่อมโยง / ตัวโหลดเดอร์แบบไดนามิกตัวอื่นเพื่อแก้ไขสัญลักษณ์ภายนอกและทำการคำนวณการย้าย

— bacondropped

ISTR Solaris ยังมีบางสิ่งที่เทียบเท่ากับสิ่งนี้

— G-Man กล่าวว่า 'Reinstate Monica'

3

หากเราได้รับอนุญาตให้เริ่มกำหนดค่าสิ่งต่างๆ

mkdir -p ~/.local/bin
cat > ~/.local/bin/x << 'EOF'
#!/bin/sh
N="$1"
shift
exec "./$N" "$@"
EOF
chmod a+x ~/.local/bin/x

distros ที่ทันสมัยส่วนใหญ่มี ~ / .local / bin ใน $ PATH อยู่แล้ว (เพิ่มลงexport PATH="$HOME/.local/bin:$PATH"ในของคุณ~/.profileหากคุณไม่มี) แล้วคุณสามารถใช้เพื่อให้ทำงานได้x file./file

อย่าพยายามกำหนด.คำสั่ง คำสั่ง. scriptรันscriptในเชลล์ปัจจุบันแล้ว สิ่งนี้อนุญาตให้scriptกำหนดตัวแปรสภาพแวดล้อมสำหรับเชลล์ปัจจุบัน

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

3

ฉันคิดว่าอาจมีข้อเสนอแนะที่ดีในที่นี่ แต่ไม่มีคำอธิบายเกี่ยวกับสิ่งนี้ ฉันสามารถใช้งานได้ แต่ผู้ใช้ที่ไม่มีประสบการณ์จะไม่มีโอกาส

— IMSoP

ไม่จำเป็นต้องเปลี่ยนเป็น $ 1 exec "$@"เพียงแค่

— reinierpost

$ (ln -s /bin/ls my-ls && exec my-ls) # bash: exec: my-ls: not found

— sourcejedi

(1) ไม่จำเป็นต้องมีshift $1; exec ./"$@"เพียงแค่ (2) เมื่อคุณกำลังพูดคุยเกี่ยวกับเชลล์สคริปต์มันเป็นจุดหมายน้อย / ทำให้เข้าใจผิดกับคนที่ให้คำแนะนำที่จะไม่กำหนดคำสั่งเพราะมันเป็นไปไม่ได้ที่จะสร้างไฟล์ที่เรียกว่า. .(เป็นไปได้และไม่น่าจะเป็นไปได้มากในการกำหนด alias หรือฟังก์ชันของ shell ที่เรียกว่า.)

— Scott

1

หากเราได้รับอนุญาตให้สร้างสคริปต์ผู้ช่วยคุณสามารถสร้างผู้ช่วยที่เพิ่ม pwd ลงใน PATH แล้วเรียกใช้

. pathhelper    #adds pwd to path
file            #now it can be run without ./

วิธีนี้หลีกเลี่ยงการเพิ่ม "." ไปยังเส้นทางและสร้างมลภาวะให้กับโปรไฟล์ของคุณในทุก ๆ เส้นทางที่คุณอาจต้องการใช้งานบางสิ่ง

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

:outer shell prompt$; subshellpathhelper    # launches a subshell with modified PATH
: subshell prompt $ ; file                  # in the subshell it can be run without ./

แต่ฉันเดาว่าถ้าคุณต้องการที่จะทำงานกับมันคุณสามารถแฮ็คpushdและpopdเพื่อให้พวกเขาสามารถปรับเปลี่ยนเส้นทางเดียวกันโดยไม่ต้องทำ subshell ซึ่งจะสูญเสียการเปลี่ยนแปลงอื่น ๆ

pushd --path ~/some/path/    # normal pushd plus adds target to path
file                         # it can be run without ./ until you popd

(คุณไม่สามารถทำเช่นเดียวกันกับcdเพราะมันไม่มีแอนะล็อกไปpopd)

นอกจากนี้คุณยังสามารถสร้างผู้ช่วยคู่หนึ่งขึ้นมาเพื่อเพียงแค่กดและป๊อปอัพรายการ PATH สิ่งที่ดีที่สุดขึ้นอยู่กับรูปแบบการใช้งานของคุณ

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

ที่จริงแล้วคุณสามารถทำสิ่งที่ชอบได้cdแต่ทำเพิ่มเติมที่นั่นทำไฟล์.dircmdsและแฮ็คcdเพื่อให้คำสั่งที่กำหนดไว้./.dircmdsไม่พร้อมใช้งานก่อนที่จะเปลี่ยนและพร้อมใช้งานทันทีหลังจากเปลี่ยน

— ShadSterling

-1

คุณสามารถใช้. script.shไวยากรณ์ได้ตราบใดที่สคริปต์ที่คุณต้องการใช้งานนั้นอยู่ในไดเรกทอรีปัจจุบัน

คุณสามารถเติมคำนำหน้าด้วยล่ามเช่น sh หรือ bash ตัวอย่าง:bash script.sh

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

8

. script.shจะหยุดลงหากสคริปต์มีexitผลกระทบที่ไม่คาดคิดเช่นหากมีการกำหนดเส้นทางใหม่ "ชั่วคราว"; นอกจากนี้ยังใช้งานได้กับสคริปต์สำหรับเชลล์ปัจจุบันของคุณเท่านั้น

— sourcejedi

@sourcejedi เกี่ยวกับexitคุณสามารถใส่ไว้ในวงเล็บคือ subshell แต่จริงมันจะยังคงเป็นสคริปต์ในเชลล์เดียวกันเท่านั้น

— phk

คำถามที่ว่า "ไฟล์ปฏิบัติการ" สิ่งเหล่านี้ใช้ไม่ได้กับไบนารีที่สามารถเรียกใช้งานได้ สำหรับสคริปต์เท่านั้น และวรรคสองของคุณซ้ำคำตอบของ Zanna

— Scott

ดีที่ไม่ดีของฉันฉันส่วนใหญ่ดำเนินการและสิ่ง dev ทุบตีดังนั้นผมถือว่าเราได้พูดคุยเกี่ยวกับสคริปต์ทุบตี :)

— UltimateByte

ไม่เพียง แต่สำหรับสคริปต์เท่านั้น แต่สำหรับสคริปต์ Bash เท่านั้น

— Oskar Skog