thực thi trong đường dẫn, có thể tìm thấy bằng cách nào, nhưng không thể thực thi mà không có đường dẫn đủ điều kiện?


12

Tôi đã gặp một vấn đề có vẻ kỳ quái về vỏ, với một lệnh trong $ PATH rằng shell (ksh, chạy trên Linux) dường như hèn nhát từ chối. Nếu không đủ điều kiện ra lệnh, tôi nhận được:

#  mycommand
/bin/ksh: mycommand: not found [No such file or directory]

nhưng tập tin có thể được tìm thấy bằng cách:

#  which mycommand
/home/me/mydir/admbin/mycommand

Tôi cũng thấy rõ thư mục đó trong $ PATH:

#  echo $PATH | tr : '\n' | grep adm
/home/me/mydir/admbin

Các exe tại vị trí đó có vẻ bình thường:

#  file /home/me/mydir/admbin/mycommand
/home/me/mydir/admbin/mycommand: setuid setgid ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), not stripped

# ls -l mycommand  
-r-sr-s--- 1 me mygroup 97892 2012-04-11 18:01 mycommand

và nếu tôi chạy nó một cách rõ ràng bằng cách sử dụng một đường dẫn đủ điều kiện:

#  /home/me/mydir/admbin/mycommand

Tôi thấy đầu ra dự kiến. Một cái gì đó chắc chắn là nhầm lẫn cái vỏ ở đây, nhưng tôi không biết nó có thể là gì?

EDIT: tìm thấy những gì trông giống như một câu hỏi tương tự: Nhị phân sẽ không thực thi khi chạy với một đường dẫn. Ví dụ> chương trình không hoạt động nhưng chương trình hoạt động tốt

Tôi cũng đã thử nghiệm nhiều hơn một lệnh như vậy trong $ PATH của mình, nhưng chỉ tìm thấy một lệnh:

# for i in `echo $PATH | tr : '\n'` ; do test -e $i/mycommand && echo $i/mycommand ; done
/home/me/mydir/admbin/mycommand

EDIT2:

Đến sáng nay, vấn đề đã biến mất và giờ tôi có thể thực thi được.

Điều đó có thể được coi là xác nhận đề xuất đăng xuất và đăng nhập, nhưng tôi đã thực hiện điều đó tối qua mà không thành công. Việc đăng xuất / đăng nhập đó cũng đã thực hiện tương đương với việc chạy lệnh 'hash -r' đã được đề xuất (mà fwiw cũng có vẻ là một nội dung ksh, và không chỉ là một bash dựng sẵn).

Đáp lại một số câu trả lời:

  • Đây là một tập tin thực thi không phải là một tập lệnh (xem tham chiếu ELF trong đầu ra lệnh tập tin).

  • Tôi không nghĩ rằng một bước tiến sẽ có ích. Điều đó kết thúc buộc lệnh phải thực thi đầy đủ. Tôi cho rằng tôi có thể đã thực hiện một bước đi kèm trên vỏ hiện tại, nhưng vì tôi không còn có thể trách móc nữa nên không có ý định thử điều đó.

  • không có dấu chấm phẩy trong $ PATH. Vì tôi không thể repro nữa, tôi sẽ không làm hỏng câu hỏi này với $ PATH đầy đủ.

  • thử một cái vỏ khác (tức là bash) sẽ là thứ tôi cũng đã thử, như đã đề xuất. Khi vấn đề không còn nữa, bây giờ tôi sẽ không biết liệu điều đó có giúp được gì không.

Nó cũng được đề nghị với tôi là kiểm tra các quyền của thư mục. Làm như vậy, đối với mỗi thư mục cho đến cái này tôi thấy:

# ls -ld $HOME $HOME/mydir $HOME/mydir/admbin
drwxr-xr-x 10 me root    4096 2012-04-12 12:20 /home/me
drwxrwsr-t 22 me mygroup 4096 2012-04-12 12:04 /home/me/mydir
drwxr-sr-x  2 me mygroup 4096 2012-04-12 12:04 /home/me/mydir/admbin

Quyền sở hữu thư mục $ HOME bị rối tung (không nên là nhóm gốc). Điều đó có thể gây ra các vấn đề khác, nhưng tôi không thấy nó đã gây ra vấn đề này như thế nào.


2
Kung-fu kịch bản của bạn là tuyệt vời.
Jeff Ferland

2
Tôi biết điều này nghe có vẻ đơn giản quá mức nhưng tôi đã từng gặp vấn đề tương tự và hóa ra đó là một dấu chấm phẩy được sử dụng như một dấu phân cách đường dẫn thay vì dấu hai chấm.
John Gardeniers

Bạn có thể cung cấp toàn bộ cài đặt PATH của bạn?
Jason Huntley

Đây là một câu hỏi nổi bật bằng văn bản.
gWaldo

có thể là bộ nhớ đệm của shell?
Michael Slade

Câu trả lời:


1

Bạn có thể cần phải cập nhật bộ nhớ cache của các mục trong trình $PATHsử dụng hash -r.


$ apropos hash | grep ksh-- không có gì. Bạn đã trả lời với một tích bashhợp, nhưng đó không phải là vấn đề.
Jeff Ferland

1

Ngoài ra, trong các trường hợp như vậy, hãy kiểm tra xem điều gì xảy ra khi chương trình được gọi bằng cách chuyển tệp thực thi của nó làm đối số cho trình liên kết động (có thể từ chối làm như vậy trong khi setuid / setgid trên một số hệ thống).

đầu ra ldd (1) của cả hai trường hợp cũng có thể được tiết lộ. "không có tệp hoặc thư mục như vậy" trên tệp thực thi thực sự có nghĩa là có thể tìm thấy trình liên kết động được chỉ định trong tệp thực thi (hãy tưởng tượng tệp thực thi có dạng ELFin là #! / lib / ld-linux.what.so.ever bên trong)

Hành vi này đã khiến mọi người chết lặng khi chứng kiến ​​sự kết thúc của kỷ nguyên libc5, và đôi khi làm mọi người chết lặng trong kỷ nguyên hỗn hợp i386 / amd64 với các phương tiện khác nhau để hỗ trợ hai bộ thư viện trong tự nhiên.

RPATH tương đối trong thực thi so với $ PWD?

PS câu hỏi khác có liên quan đến MacOSX, có lẽ sử dụng dyld chứ không phải trình liên kết libc cung cấp. Rất khác loại động vật.


0

Được rồi, tôi không có câu trả lời. Tôi đã chứng minh một vài điều và nghĩ rằng tôi có thể thêm vào điều này sau:

  • Đã tạo một testfile - các quyền của bạn cho thấy nó là setuid và có thể thực thi được.
  • Đã thử đặt nó trên một điểm gắn kết với nosuid: vẫn chạy
  • Đã thử đặt nó trên một điểm gắn kết với noexec: đưa ra một lỗi khác

Vì vậy, bởi tất cả các tài khoản, tôi vẫn còn bối rối. Chỉ vì nụ cười và rất có thể đây là một lỗi liên quan đến vỏ, bạn có thể thử nó với một vỏ khác không?


0

Tôi đoán rằng tập lệnh của bạn không có vỏ hợp lệ sau #!. Chẳng hạn, trên một số hệ thống SCO cũ hơn, các tập lệnh có #! / Bin / bash không hoạt động vì bash THỰC SỰ sống trong / usr / bin / bash. Ngốc, nhưng hey SCO gần như đã chết vì một lý do, phải không?

Kiểm tra shell của bạn và đảm bảo rằng nó trỏ đến một tập lệnh / nhị phân thực.

Chỉnh sửa: Nó không cho biết đó là tập lệnh hay nhị phân, nhưng giả sử đầu ra 'ls -l' của bạn là chính xác, thì có lẽ bạn không có tập lệnh 93kbyte ... vì vậy đây có lẽ là câu nhị phân có nghĩa là câu trả lời của tôi là hoàn toàn không chính xác

Bạn đã thử đăng xuất và đăng nhập lại chưa? Tôi biết nếu tôi sử dụng nhị phân trong / usr / bin sau đó cài đặt phiên bản / usr / local / bin từ nguồn, hệ thống vẫn cố thực hiện phiên bản gốc cho đến khi tôi đăng xuất và đăng nhập lại.


Đó là một tập tin thực thi và không phải là tập lệnh (xem thông tin ELF từ tệp trong câu hỏi). Có, tôi đã đăng xuất và đăng nhập.
Peeter Joot

0

Tôi đoán:

  • Bạn đã có một bí danh được đặt tên mycommand. Ví dụ:

    alias mycommand=something
    
  • Bạn đã có một chức năng được đặt tên mycommand. Ví dụ:

    mycommand() { something; }
    

Lần tới khi bạn gặp vấn đề này, hãy thử chạy command -V mycommandđể xem shell tin vào loại lệnh nào mycommand.


không ai trong số đó là trường hợp của lệnh này.
Peeter Joot

0

Không có câu trả lời, chỉ là một loạt các suy nghĩ:

  1. Kiểm tra xem tên tệp có chứa khoảng trắng không; điều này bị âm thầm bỏ qua khi sử dụng hoàn thành tab và sử dụng làm tham số.
  2. Hãy thử một kịch bản / chương trình khác trong thư mục.
  3. Hãy thử strace-ing shell cố gắng thực thi tập lệnh và xem nó phá vỡ ở đâu.

0

Tôi đã có chính xác cùng một vấn đề và không tìm được câu trả lời vì vấn đề của người gửi ban đầu đã tự giải quyết. Nhưng điều này không làm việc cho tôi và cuối cùng tôi đã tìm ra được vấn đề. Vì vậy, tôi đang thêm những điều sau đây như một câu trả lời cho bài viết gốc.

Các triệu chứng tôi phải đối mặt là như sau. Có một tập lệnh (myscript.pl) trong thư mục / my / home. Bây giờ đang cố chạy nó:

> /my/home/myscript.pl
myscript.pl:  permission denied.

Xác nhận quyền của tệp (cờ thực thi được đặt). Đã xác minh $ PATH (mặc dù không có vấn đề gì).

Vì vậy, sau đó tôi thử (sau khi xác minh cờ thực thi được đặt trên tập lệnh):

> cd /my/home/
> ./myscript.pl:  permission denied.

Hmmm ... Vì vậy, có lẽ kịch bản không gọi đúng ngôn ngữ kịch bản (perl, trong trường hợp này). Phần đầu của kịch bản có phép thuật chính xác:

#!/usr/bin/perl

và thực sự / usr / bin / perl tồn tại và hoạt động. Vì vậy, cuộc gọi sau hoạt động chính xác.

/usr/bin/perl myscript.pl

tab tự động hoàn thành sẽ không hiển thị tệp (không có trong tcshhoặc không bash).

Điều này thực sự đã ném tôi đi. Sau đó nhớ rằng vài tháng trước, đĩa cứng của tôi đã bị hỏng và quản trị viên hệ thống trẻ trong phòng thí nghiệm của tôi đã cài đặt lại hệ thống. Nghĩ rằng anh ta có thể đã làm hỏng các quyền trên các phân vùng. Và thực sự, trong /etc/fstab, sự cho phép điều hành đã bị mất!

/dev/sda1    /my     /ext4      rw,user

Thay vì

/dev/sda1    /my     /ext4      rw,user,exec

Đã sửa lỗi này bằng cách thay đổi /etc/fstabvà kể lại:

mount -v -o remount /my

Điều này đã giải quyết vấn đề hoàn toàn. Tôi đoán là một điều tương tự có thể đã xảy ra với vấn đề của người đăng ban đầu, ngoại trừ vấn đề cấp phép không liên tục (ví dụ: có một thay đổi tạm thời có thể được giải quyết khi khởi động lại, nếu xảy ra).


-1

Không phải là một câu trả lời đầy đủ, nhưng muốn báo cáo kinh nghiệm của tôi vì tôi có cùng một vấn đề như người hỏi và nghĩ rằng nó có thể giúp người dùng trong tương lai gặp phải vấn đề điên rồ tương tự. Tôi có thể tập tin và xem nó trong đường dẫn của mình và thậm chí thực thi nó bằng cách đưa ra đường dẫn đầy đủ, nhưng không thể thực thi nó theo cách khác. Tuy nhiên, trong trường hợp của tôi, nó chỉ xảy ra trong một vỏ con (nghĩa là khi nó được thực thi từ một tập lệnh, trong trường hợp này có một vài vỏ con lồng nhau). Tôi có thể chạy nó từ dòng lệnh tốt.

Ngay trước lệnh trong tập lệnh lồng nhau, tôi đã in ra lệnh, ví dụ echo $ (mà mycommand)

mycommand: / home / me / bin / mycommand

Sau đó, tôi sẽ cố gắng thực hiện nó từ tập lệnh gốc:

/ home / me / bin / some_parent_script [72]: mycommand: không tìm thấy [Không có tệp hoặc thư mục như vậy]

Giống như người hỏi, tôi không thể chẩn đoán nguồn gốc của vấn đề. PATH của tôi nhìn đúng, nó có khả năng và hàm băm không tiết lộ bất kỳ mục trước nào của mycommand. Ngày hôm sau khi tôi đăng nhập, mọi thứ kỳ diệu hoạt động trở lại. Bây giờ, tôi sẽ lưu ý ở đây rằng có một sự cố hệ thống đã biết xảy ra ngay trước khi tôi thấy vấn đề này khi gắn kết được gắn kết. Có lẽ đó là một đầu mối?

Nếu tôi không có tệp nhật ký sau khi tệp nhật ký chứng minh rằng điều này đã xảy ra, tôi sẽ không tin nó là có thể! Nhờ người hỏi, tôi không còn cảm thấy điên nữa!

Tái bút: Tôi không nghĩ user226160 có vấn đề CHÍNH XÁC như phóng viên, nhưng nghe có vẻ liên quan và cho vay sự tin cậy vào lý thuyết gắn kết.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.