Thực thi dưới dạng .test chứ không phải ./test

Giả sử tôi đang ở trong cùng thư mục với một tệp thực thi, tôi sẽ cần phải nhập tệp này để thực thi nó:

./file

Tôi thà không phải gõ /, vì /tôi khó gõ.

Có cách nào dễ dàng hơn để thực hiện một tập tin? Lý tưởng nhất chỉ là một số cú pháp đơn giản như:

.file

hoặc một cái gì đó khác nhưng dễ dàng hơn là phải chèn /nhân vật ở đó.

Có lẽ có một số cách để đặt một cái gì đó vào /binthư mục hoặc tạo bí danh cho trình thông dịch, để tôi có thể sử dụng:

p file

Nó có thể là "rủi ro" nhưng bạn có thể có. trong ĐƯỜNG của bạn.

Như đã nói ở những người khác, điều này có thể nguy hiểm vì vậy luôn luôn đảm bảo. là ở phần cuối của ĐƯỜNG chứ không phải là bắt đầu.

.sẽ tự động hoàn thành./ (gõ .và nhấn Tab) ít nhất trong các vỏ Bash hiện đại, vì vậy bạn không cần phải sử dụng PATHgiải pháp phức tạp hoặc không an toàn (như sửa đổi).

Nếu nó không tự động hoàn tất, bạn có thể cần phải cài đặt gói "bash-hoàn thành".

hoặc .. có lẽ cung cấp cho trình thông dịch một bí danh trong tệp bashrc và sau đó chỉ đơn giản là

   p  file

Có thể viết một hàm như vậy:

p() {
 ./"$@"
}

trong của bạn ~/.bashrc. Sau đó, bạn sẽ có thể chạy p app argumentsthay vì ./app arguments. Giải pháp này hoạt động cho các tệp thực thi thuộc bất kỳ loại nào, bao gồm các tập lệnh và tệp nhị phân.

"$@"mở rộng để liệt kê một cách thích hợp danh sách các đối số được truyền cho hàm (bảo toàn tất cả các ký tự đặc biệt khỏi mở rộng toàn cầu hoặc biến), và, như @Scott chỉ ra, bashđủ thông minh để trả trước ./cho một trong số chúng, bảo toàn phần còn lại.

Bạn có thể đặt .vào của bạn $PATHbằng cách thêm ví dụ PATH=$PATH:.vào /etc/profile, theo cách này bạn có thể thực hiện filechỉ bằng cách viết file, trừ khi nó nằm trong một thư mục khác trong đường dẫn của bạn (ví dụ /usr/bin/). Lưu ý rằng điều này thường không phải là một ý tưởng tốt.

Tại sao nó xấu: Giả sử bạn đang ở trong một tình huống mà bạn không hoàn toàn tin tưởng vào nội dung của một thư mục - bạn đã tải nó từ một nơi nào đó tinh ranh và bạn muốn điều tra nó trước khi chạy nó, hoặc bạn là một sysadmin giúp đỡ một số người dùng bằng cách tìm trong thư mục chính của họ, v.v. Bạn muốn liệt kê thư mục, vì vậy bạn cố gắng gõ ls, nhưng rất tiếc, bạn tạo một lỗi đánh máy và cuối cùng thay vào đó là gõ sl. Tác giả của thư mục độc hại này đã lường trước điều này và đặt một tập lệnh shell vào nó có tên là "sl" chạy 'rm -rf --no-reserved-root /' (hoặc một cái gì đó độc hại hơn như cài đặt rootkit).

(Cảm ơn @Muzer đã giải thích)

Bạn có thể gọi thông dịch viên, ví dụ

bash test

Trong trường hợp này, tập lệnh sẽ chạy ngay cả khi nó không có dòng shebang (ví dụ #!/bin/bash) cũng như bit thực thi. Bạn sẽ phải biết trình thông dịch chính xác để chạy nó. Bạn có thể đọc dòng shebang của tệp trước để đảm bảo bạn gọi đúng trình thông dịch, ví dụ nếu dòng shebang nói

#!/usr/bin/env python3

bạn sẽ gọi

python3 test

Theo tôi biết, không có cách nào để đạt được nó trừ khi bạn bao gồm tệp trong đường dẫn env, vì vậy bạn có thể chạy nó chỉ bằng cách gõ: file

.filesẽ không hoạt động vì đó là một tên tập tin khác. Nó là một tập tin được gọi .filevà không ./file.

Tôi cảm thấy rằng dấu gạch chéo có thể khó gõ cho bạn vì bố cục không phải tiếng Anh, có thể? Trong trường hợp đó, điều đó cũng xảy ra với tôi, vì vậy tôi thường xuyên trao đổi bố cục bàn phím của mình sang tiếng Anh bằng cách nhấn Alt + Shift trong Windows (Tôi sử dụng Linux từ ssh)

Mọi người đã đề nghị thêm .vào PATH, điều này rất nguy hiểm vì nó tạo ra rủi ro rằng bạn sẽ vô tình chạy một chương trình độc hại được trồng trong một thư mục có thể ghi trên thế giới. Nhưng, nếu bạn có các chương trình thực thi trong một vài thư mục mà bạn sở hữu và chỉ có thể ghi được bởi bạn, thì có an toàn (khá an toàn không?) Để đưa các giám đốc đó vào PATH, bằng cách thêm một dòng như

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

vào ~/.bashrctập tin của bạn . Tất nhiên điều này có nghĩa là bạn có thể chạy một chương trình từ một trong những thư mục đó từ bất kỳ đâu trong hệ thống tập tin. Ví dụ, bạn có thể cd /etcvà gõ foo, và nó sẽ chạy ~/dev/myprog1/foo. Điều này có một nhược điểm nhỏ là bạn không thể có các chương trình cùng tên trong nhiều hơn một trong các thư mục. Cụ thể, nếu bạn có các chương trình được gọi foo trong cả hai ~/dev/myprog1và ~/dev/myprog2, bạn sẽ không thể chạy chương trình thứ hai trừ khi chỉ định đường dẫn. Tương tự như vậy nếu bạn có một ~/dev/myprog1/cat- nhưng tại sao bạn muốn?

Một cách tiếp cận khác, nếu bạn chỉ có một vài chương trình mà bạn thực hiện điều này, là xác định bí danh cho chúng:

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

Hoặc bạn có thể gọi các bí danh .gizmovà .gonzo nếu bạn thấy điều đó trực quan hơn.

Trên thực tế, điều này, ở một mức độ nào đó, rủi ro bảo mật tương tự như đưa .vào của bạn PATH. Nếu một người dùng độc hại có thể đọc .bashrcvà xem bí danh của bạn, thì anh ta có thể đặt phần mềm độc hại được gọi gizmovà gonzotrong các thư mục ngẫu nhiên với hy vọng rằng bạn sẽ chạy nó. Tốt hơn là làm cho chúng sử dụng tên đường dẫn tuyệt đối:

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

Nhân tiện, bạn nên tránh đặt tên một tệp thực thi test, bởi vì đó là lệnh dựng sẵn shell và bạn chỉ có thể chạy một chương trình theo tên đó bằng cách chỉ định một đường dẫn hoặc một số mẹo khác.

Để mở rộng câu trả lời của Zanna về trình thông dịch (xin lỗi, không có đại diện cho nhận xét): "trình thông dịch" cho các tệp thực thi gốc (còn gọi là tệp ELF nhị phân) là trình tải động ( ld.so), nhưng nó thường không hiểu cú pháp bạn muốn:

$ /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>

(ngoài ra, trừ khi bạn symlink ld.sovào đường dẫn của mình, bạn vẫn cần phải viết /s)

Nếu chúng ta được phép bắt đầu cấu hình mọi thứ

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

Hầu hết các phân phối hiện đại bao gồm ~ / .local / bin trong $ PATH đã có (thêm export PATH="$HOME/.local/bin:$PATH"vào ~/.profilenếu bạn không có). Sau đó, bạn có thể sử dụng x fileđể chạy ./file.

Đừng cố gắng xác định một .lệnh. Lệnh . scriptđã chạy scripttrong shell hiện tại. Điều này cho phép scriptxác định các biến môi trường cho shell hiện tại.

Nếu chúng tôi được phép tạo tập lệnh của trình trợ giúp, bạn có thể tạo một trình trợ giúp thêm pwd vào PATH, sau đó chạy

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

Điều này tránh thêm "." đến đường dẫn và gây ô nhiễm .profile của bạn với mọi đường dẫn mà bạn có thể muốn chạy một cái gì đó vào một lúc nào đó.

Chúng ta có thể thực hiện phương pháp này một bước xa hơn bằng cách tạo ra một người trợ giúp khởi chạy một lớp vỏ mới với một PATH được sửa đổi. Nếu nó lấy một thư mục làm tham số (sử dụng pwd làm mặc định), nó sẽ hoạt động như một pushdchỉnh sửa đường dẫn. Bạn có thể phải lưu ý rằng mọi thay đổi đối với các biến môi trường khác sẽ bị mất khi thoát khỏi lớp con, nhưng trong một lớp vỏ dài, biến PATH của bạn sẽ không bị lộn xộn. Tùy thuộc vào quy trình công việc của bạn, điều này có thể là lợi thế.

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

Nhưng tôi đoán nếu bạn muốn chạy với nó, bạn có thể hack pushdvà popdvì vậy họ có thể thực hiện các sửa đổi tương tự cho đường dẫn mà không cần thực hiện một subshell sẽ làm mất các thay đổi khác.

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

(Bạn không thể làm tương tự với cdvì nó không có tương tự popd.)

Bạn cũng có thể tạo một cặp trợ giúp chuyên dụng để chỉ cần đẩy và bật các mục PATH. Những gì hoạt động tốt nhất thực sự phụ thuộc vào mô hình sử dụng của bạn.

Bạn có thể sử dụng . script.shcú pháp miễn là tập lệnh bạn muốn thực thi nằm trong thư mục hiện tại.

Bạn cũng có thể thêm tiền tố với trình thông dịch, như sh hoặc bash. thí dụ:bash script.sh