2010-10-05 57 views
11

Tôi đang học cách tạo các kịch bản lệnh shell trong UNIX, nhưng tôi tiếp tục gặp lỗi ngu ngốc này. Giả sử tôi tạo một tập lệnh như sau:lệnh không tìm thấy thông báo lỗi sau khi tôi cố gắng chạy một kịch bản UNIX

#!/bin/sh 
echo HELLO 

Tôi lưu tệp dưới dạng kiểm tra và thực hiện lệnh có thể chạy được bằng thử nghiệm chmod 700. Tôi lưu các tập tin trong thư mục chính của tôi, và (cố gắng) để chạy các tập tin như vậy:

./test 

Chỉ dành cho UNIX để trả lời lại:

./test: Command not found. 

là gì đang xảy ra? Khi tôi nhập ls -l, có dấu hoa thị bên cạnh tên tệp. Điều đó không có ở đó trước khi tôi sử dụng lệnh chmod. Bất cứ ai có thể cho tôi biết những gì tôi đang làm sai?

+2

Liệu 'ls/bin/sh' hiển thị một tập tin với các bit thực thi kích hoạt? – Ether

+0

Khi bạn thêm dấu gạch chéo còn thiếu, bạn vẫn gặp sự cố? Là thư mục bạn đang ở trong gắn kết với bất kỳ (rất) tùy chọn đặc biệt? –

Trả lời

5

Có vẻ như bạn cần một dấu gạch chéo trước khi bin:

#!/bin/sh 
#^

Mọi thứ khác trông tốt ... Tôi giả định rằng /bin/sh là vị trí của vỏ Bournse thực thi của bạn - nếu nó không phải là , bạn sẽ cần phải điều chỉnh cho phù hợp. Nếu không có dấu gạch ngang hàng đầu, vỏ của bạn đang tìm kiếm bin/shliên quan đến thư mục hiện tại của bạn, thay vì vị trí thực sự nằm trong đó.

Bạn sẽ cần định vị trình thông dịch shell thực thi mà bạn muốn (hoặc cần) cho tập lệnh của mình. Một vài chi tiết

gợi ý - trên máy tính của tôi, tôi có được những kết quả này:

# tells you where sh resides, if it is on your path 
$ which sh 
/bin/sh 

# tells you which shell you are currently using 
$ echo $SHELL 
/bin/tcsh 

tôi có thể sử dụng một trong những cho 'shebang' dòng trong một kịch bản đơn giản. Bạn có thể thấy rằng vỏ Bourne của bạn nằm trong ví dụ /usr/bin thay vì /bin.

+0

Vâng, tôi vừa thay thế tiêu đề bằng nội dung bạn đã đăng và tôi nhận được lỗi tương tự. – Waffles

0

#! yêu cầu Unix thực thi tập lệnh của bạn bằng chương trình được chỉ định. Trong trường hợp của bạn, bạn đã chỉ định bin/sh, nhưng phải là /bin/sh. Thông báo lỗi mà Unix cung cấp không rõ ràng về chương trình mà nó không thể tìm thấy.

11

Làm cho nó thực thi:

chmod +x ./test 

và chắc chắn rằng bạn lưu tập tin của bạn ở định dạng tập tin Unix. Và: kiểm tra xem phân vùng của bạn có thực thi được không (mount).

0

Để thêm vào câu trả lời của Martin, bạn nói rằng bạn lưu tệp trong thư mục chính của mình và chạy tệp đó dưới dạng ./test. Điều này sẽ chỉ hoạt động nếu thư mục làm việc hiện tại của bạn giống với thư mục chính của bạn.

Dấu hoa thị bên cạnh tên tệp có nghĩa là tệp đó có thể thực thi được.

+0

Vâng, tôi hiện đang ở trong thư mục chính của tôi. – Waffles

+1

@Waffles: Nếu câu trả lời của Martin không giúp bạn và bạn đang ở trong cùng một thư mục chứa tập tin ... bạn có chắc là bạn có chương trình '/ bin/sh' không? Nó có thể là '/ bin/zsh' hoặc '/ bin/bash' tùy thuộc vào hệ thống giống như UNIX bạn đang chạy. –

+1

Mọi thứ có thể được gọi là unix hợp lý đều có vỏ Bourne hoặc POSIX là '/ bin/sh', ngay cả khi vỏ ưa thích là một cái gì đó khác như'/bin/bash' hoặc '/ bin/ksh'. – Gilles

2

Khi ./test là tập lệnh thực thi và chưa thực thi nó sẽ hiển thị thông báo lỗi ./test: Command not found, hãy kiểm tra xem thông dịch viên có tồn tại hay không. Bạn phải cung cấp đường dẫn tuyệt đối (biến môi trường PATH không được sử dụng).

Nếu tệp đã trải qua máy Windows, hãy đảm bảo không có trả về vận chuyển giả ở cuối dòng, vì CR sẽ là một phần của tên tệp thông dịch viên. Bạn có thể kiểm tra với <test head -n 1 | od -t x1: nếu điều này kết thúc bằng 0d 0a, có CR và bạn cần phải loại bỏ nó (bạn cũng có thể cần phải loại bỏ CR khỏi các dòng khác).

8

Điều này thực sự rất lạ. Các bước bạn mô tả nên đã làm việc, do đó, phải có một số lỗi nhỏ trong môi trường của bạn hoặc thực hiện các bước đó. Có một số điều bạn có thể làm để giúp chẩn đoán này:

KIỂM TRA CHO ký tự điều khiển

Những gì bạn đã ghi nhận có vẻ tốt đẹp, miễn là không có lỗi chính tả hoặc ký tự điều khiển. Bạn nên kiểm tra bằng cách nhập:

cat -vt ./test 

Nếu bạn thấy bất kỳ văn bản bổ sung không mong muốn nào có thể giải thích được sự cố. Ví dụ: "^ M" ở cuối dòng sẽ cho biết rằng trình chỉnh sửa của bạn đã lưu tệp ở định dạng Windows.

hồi phục lại không đáng tin cậy FILE

Để tạo một tiếng-tốt ./test2, sao chép-dán các lệnh dưới đây:

`which bash` 
printf "#\!`which sh`\necho HELLO\n" > ./test2 
chmod +x ./test2 
./test2 
exit 

KIỂM TRA MÀ COMMAND KHÔNG THỂ TÌM THẤY

Nếu bạn gõ .. .

./ajio 

... bạn có nhận được chính xác ...

./ajio: Command not found. 

... như bạn đã mô tả với ./test? Tôi chỉ tạo nên tên ajio nên nó không tồn tại. Nếu chúng phù hợp thì nó không thực sự cho bạn biết điều gì mới mẻ. Nhưng nếu các thông báo khác nhau, điều đó xác nhận rằng ./test ít nhất đã được tìm thấy và có thể thực thi được.

Cũng có thể phiên bản sh của bạn đang cố gắng thông báo cho bạn rằng không thể tìm thấy test nhưng trong khi chạy test một số lệnh mà trình chạy thử không thể tìm thấy. Đó không phải là lệnh echo, như với hầu hết các triển khai shell sẽ là một lệnh nội bộ, được thực hiện bên trong trình bao. Tuy nhiên, shell có thể chạy một script khởi tạo có chứa một dòng xác định một lệnh mà nó không thể chạy. Nếu bạn chạy man sh, nó sẽ cho bạn biết về tất cả các tệp khởi động khác nhau mà trình bao của bạn có thể thử chạy. Đây có thể khác với những thứ được sử dụng khi bạn khởi động trình bao tương tác. Nhưng, như một người mới bắt đầu, nó có thể được khó khăn kiểm tra tính hợp lệ của những kịch bản. Có thể là bất kỳ tùy chỉnh không có thật nào sẽ là quá trình khởi động shell cá nhân của bạn, và không ảnh hưởng đến toàn bộ cài đặt Linux, do đó hãy chạy ls -ld ~/.* để liệt kê các tệp ẩn trong thư mục chính của bạn và kiểm tra bất kỳ tệp nào giống như tệp khởi động shell (ví dụ ~/.bashrc, ~/.profile, ~/.bash_login). Kiểm tra bất kỳ lệnh nào mà chúng chỉ định có thể được tìm thấy và lệnh được gọi sau khi biến đường dẫn được đặt để bao gồm vị trí của chúng.

so với KHÁC SHELL

Nếu có một vấn đề với các/bin/sh cài đặt/khởi động, sau đó bạn có thể có thể để vượt qua nó bằng cách gọi vỏ khác. Thử...

which zsh 
which tcsh 
which csh 

... và nếu một trong nhiều những tìm thấy một vỏ thay thế cho bạn, chỉnh sửa hoặc tạo tập tin xác định vỏ đó, ala ...

#!/bin/csh 
echo HELLO 

... sau đó chmod +x nó và ./-chạy nó. Nếu điều đó làm việc, thì bạn biết vấn đề của bạn là/bin/sh cụ thể.

+1

Tôi cam kết 'cat -vt' vào bộ nhớ vĩnh viễn, điều đó rất hữu ích! – ken

+0

Mẹo hay. Tôi đã kiểm tra trang người đàn ông, và tôi nghĩ nó có thể được rút gọn thành 'cat -t', giống như làm' cat -vT'. – Josh

+0

Sử dụng 'cat -vt' để phát hiện tệp tập lệnh của tôi có kết thúc dòng Windows không chính xác đã lưu trong ngày. Cảm ơn. –

1

Tôi đã gặp sự cố tương tự khi tôi sao chép tệp từ Windows sang Linux và đã cố thực thi nó. Tôi đã làm tất cả các đề xuất ở trên nhưng không có gì giúp cho đến khi tôi đã làm một dos2unix trên tập tin và cố định nó. Nó có thể không phải là trường hợp của bạn, nhưng chỉ cần đặt nó ra khỏi đó

+0

Điều này thực sự hoạt động! – Cheshar

1

Tôi đã có một vấn đề tương tự với một máy ảo SCO OpenServer 5.0.7 cũ. Lái xe cho tôi hạt mà tôi không thể chạy một số kịch bản mà bắt đầu với

"#!/Bin/bash"

(trừ các dấu ngoặc kép, tất nhiên) Trong khi đọc các bài ở đây, nó chợt nhận ra tôi để kiểm tra xem/bin/bash thậm chí còn tồn tại. Hóa ra nó đã mất tích. Tôi đã cài đặt từ một đĩa CD SKUNKWARE2000 và tất cả đều tốt.

3

Trước hết, hãy kiểm tra xem liệu bin/sh có tồn tại không, nếu không thì đó là vấn đề của bạn.

Nếu bạn đã cài đặt/bin/sh, thì tôi nghĩ điều này xảy ra nếu đường dẫn của bạn không được định cấu hình đúng cách. Trong trường hợp này bạn có thể thử: /bin/sh test.sh từ thư mục làm việc hiện tại nơi test.sh nằm.

Đồng thời thử dùng dos2unix test.sh nếu bạn đã sao chép tệp từ cửa sổ.

Các vấn đề liên quan