Làm cách nào để có được danh sách mã thoát (và / hoặc mã trả về) và ý nghĩa của lệnh / tiện ích?


17

Có cách nào tôi có thể làm những gì được nêu trong tiêu đề từ các lệnh đầu cuối, hoặc tôi sẽ phải xem xét các mã?

Câu trả lời:


15

Không có "công thức" để có được ý nghĩa của trạng thái thoát của lệnh đầu cuối đã cho.

Nỗ lực đầu tiên của tôi sẽ là trang chủ:

user@host:~# man ls 
   Exit status:
       0      if OK,

       1      if minor problems (e.g., cannot access subdirectory),

       2      if serious trouble (e.g., cannot access command-line argument).

Thứ hai : Google . Xem wget là một ví dụ.

Thứ ba : Các trạng thái thoát của shell, ví dụ bash. Bash và nó được xây dựng có thể sử dụng các giá trị trên 125 đặc biệt. 127 cho lệnh không tìm thấy, 126 cho lệnh không thực thi. Để biết thêm thông tin, xem mã thoát bash .


vâng, một số người, thông tin, ... các trang có bao gồm họ .. và tôi quan tâm đến những người không. .. và tôi biết một nghiên cứu web luôn là một lựa chọn. .. như bây giờ có vẻ như đó chỉ là mã thoát bash mà tôi phải tìm ..
chính xác là

12

Mã thoát cho biết tình trạng lỗi khi kết thúc chương trình và chúng nằm trong khoảng từ 0 đến 255. Shell và các phần tử của nó có thể sử dụng đặc biệt là các giá trị trên 125 để chỉ ra các chế độ lỗi cụ thể, vì vậy danh sách mã có thể khác nhau giữa các shell và hệ điều hành (ví dụ Bash sử dụng giá trị 128 + N làm trạng thái thoát). Xem: Bash - 3.7.5 Trạng thái thoát hoặc man bash.

Nói chung, trạng thái thoát không cho biết lệnh đã thành công , trạng thái thoát khác không cho biết lỗi .

Để kiểm tra mã lỗi nào được trả về bởi lệnh, bạn có thể in $?mã thoát cuối cùng hoặc ${PIPESTATUS[@]}đưa ra danh sách các giá trị trạng thái thoát khỏi đường ống (trong Bash) sau khi thoát khỏi tập lệnh shell.

Không có danh sách đầy đủ tất cả các mã thoát có thể được tìm thấy, tuy nhiên đã có một nỗ lực hệ thống hóa các số trạng thái thoát trong nguồn kernel, nhưng đây là mục đích chính cho các lập trình viên C / C ++ và tiêu chuẩn tương tự cho kịch bản có thể phù hợp.

Một số danh sách sysexits trên cả Linux và BSD / OS X với mã thoát thích hợp hơn cho các chương trình (64-78) có thể được tìm thấy trong /usr/include/sysexits.h(hoặc: man sysexitstrên BSD):

0   /* successful termination */
64  /* base value for error messages */
64  /* command line usage error */
65  /* data format error */
66  /* cannot open input */
67  /* addressee unknown */
68  /* host name unknown */
69  /* service unavailable */
70  /* internal software error */
71  /* system error (e.g., can't fork) */
72  /* critical OS file missing */
73  /* can't create (user) output file */
74  /* input/output error */
75  /* temp failure; user is invited to retry */
76  /* remote error in protocol */
77  /* permission denied */
78  /* configuration error */
/* maximum listed value */

Danh sách trên phân bổ các mã thoát chưa sử dụng trước đó từ 64-78. Phạm vi của các mã thoát chưa được phát hiện sẽ bị hạn chế hơn nữa trong tương lai.

Tuy nhiên, các giá trị trên chủ yếu được sử dụng trong sendmail và được sử dụng bởi khá nhiều người khác, vì vậy chúng không phải là bất cứ thứ gì từ xa gần với một tiêu chuẩn (như được chỉ ra bởi @Gilles ).

Trong shell, trạng thái thoát như sau (dựa trên Bash):

  • 1- 125- Lệnh không hoàn thành thành công. Kiểm tra trang man của lệnh để biết ý nghĩa của trạng thái, một vài ví dụ dưới đây:

  • 1 - Catchall cho các lỗi chung

    Các lỗi khác, chẳng hạn như "chia cho số 0" và các hoạt động không thể chấp nhận khác.

    Thí dụ:

    $ let "var1 = 1/0"; echo $?
    -bash: let: var1 = 1/0: division by 0 (error token is "0")
    1
    
  • 2 - Sử dụng sai các nội dung shell (theo tài liệu của Bash)

    Thiếu từ khóa hoặc lệnh hoặc vấn đề cấp phép (và mã trả về diff khi so sánh tệp nhị phân không thành công).

    Thí dụ:

     empty_function() {}
    
  • 6 - Không có thiết bị hoặc địa chỉ như vậy

    Thí dụ:

    $ curl foo; echo $?
    curl: (6) Could not resolve host: foo
    6
    
  • 124 - hết thời gian

  • 125- nếu một lệnh tự thất bại, xem: coreutils
  • 126 - nếu lệnh được tìm thấy nhưng không thể được gọi (ví dụ: không thể thực thi)

    Vấn đề quyền hoặc lệnh không phải là một thực thi.

    Thí dụ:

    $ /dev/null
    $ /etc/hosts; echo $?
    -bash: /etc/hosts: Permission denied
    126
    
  • 127 - nếu một lệnh không thể được tìm thấy, tiến trình con được tạo để thực thi nó sẽ trả về trạng thái đó

    Vấn đề có thể xảy ra với $PATHhoặc một lỗi đánh máy.

    Thí dụ:

    $ foo; echo $?
    -bash: foo: command not found
    127
    
  • 128 - Đối số không hợp lệ để exit

    exit chỉ lấy số nguyên arg trong phạm vi 0 - 255.

    Thí dụ:

    $ exit 3.14159
    -bash: exit: 3.14159: numeric argument required
    
  • 128- 254- tín hiệu lỗi nghiêm trọng "n" - lệnh bị chết do nhận tín hiệu. Mã tín hiệu được thêm vào 128 (128 + TÍN HIỆU) để có trạng thái (Linux : man 7 signal, BSD man signal:), một vài ví dụ dưới đây:

  • 130 - lệnh bị chấm dứt do nhấn Ctrl-C, 130-128 = 2 (SIGINT)

    Thí dụ:

    $ cat
    ^C
    $ echo $?
    130
    
  • 137- nếu lệnh được gửi KILL(9)tín hiệu (128 + 9), trạng thái thoát lệnh khác

    kill -9 $PPID của kịch bản.

  • 141- SIGPIPE- viết trên một đường ống không có người đọc

    Thí dụ:

    $ hexdump -n100000 /dev/urandom | tee &>/dev/null >(cat > file1.txt) >(cat > file2.txt) >(cat > file3.txt) >(cat > file4.txt) >(cat > file5.txt)
    $ find . -name '*.txt' -print0 | xargs -r0 cat | tee &>/dev/null >(head /dev/stdin > head.out) >(tail /dev/stdin > tail.out)
    xargs: cat: terminated by signal 13
    $ echo ${PIPESTATUS[@]}
    0 125 141
    
  • 143 - lệnh kết thúc bằng mã tín hiệu 15 (128 + 15 = 143)

    Thí dụ:

    $ sleep 5 && killall sleep &
    [1] 19891
    $ sleep 100; echo $?
    Terminated: 15
    143
    
  • 255* - trạng thái thoát khỏi phạm vi.

    exit chỉ lấy số nguyên arg trong phạm vi 0 - 255.

    Thí dụ:

    $ sh -c 'exit 3.14159'; echo $?
    sh: line 0: exit: 3.14159: numeric argument required
    255
    

Theo bảng trên, mã thoát 1 - 2, 126 - 165 và 255 có ý nghĩa đặc biệt và do đó nên tránh các tham số thoát do người dùng chỉ định.

Xin lưu ý rằng giá trị thoát khỏi phạm vi có thể dẫn đến mã thoát không mong muốn (ví dụ: lối ra 3809 cung cấp mã thoát là 225, 3809% 256 = 225).

Xem:


errnocác giá trị được sử dụng bởi các API hệ thống, chúng không được sử dụng làm trạng thái thoát (thậm chí chúng không nằm trong phạm vi phù hợp) và chúng không liên quan đến kịch bản shell. Giá trị Sysexits là từ sendmail và được sử dụng bởi khá nhiều người khác, chúng không phải là bất cứ thứ gì từ xa gần với một tiêu chuẩn.
Gilles 'SO- ngừng trở nên xấu xa'

7

Bạn sẽ phải xem xét mã / tài liệu. Tuy nhiên, điều gần nhất với "tiêu chuẩn hóa" là errno.h


cảm ơn vì đã chỉ vào tệp tiêu đề .. đã thử xem tài liệu của một vài tiện ích .. thời gian khó tìm mã thoát, có vẻ như hầu hết sẽ là các thiết bị ...
chính xác là

3
errno.hkhông liên quan khi nói đến mã thoát, chỉ có thông báo lỗi.
Gilles 'SO- ngừng trở nên xấu xa'

Hầu hết các chương trình trả về mã thoát theo quy ước BSD, như được nêu trong sysexits.h. Tuy nhiên, một số chương trình trả về errnos và tôi thực sự nghĩ rằng trả về errnos có ý nghĩa nhất. Không được xử lý errnotruyền lên trên, như các trường hợp ngoại lệ, ( errnoở lại, các hàm trả về, ví dụ, -1hoặc 0|NULL). Vì các chương trình chỉ là các hàm, mặc dù các hàm được chạy trong một không gian địa chỉ riêng biệt, nên có nghĩa là một chương trình có thể muốn tiếp tục errnotruyền bá qua ranh giới quá trình.
PSkocik

@PSkocik, bạn có ví dụ về lệnh như vậy không? errnos không khả chuyển (các giá trị không nhất quán trên các hệ thống) và không có cách di động nào để nhận tên hoặc thông báo lỗi từ giá trị (zsh có nội dung cho điều đó). Chưa kể rằng một số hệ thống có lỗi trên 123 sẽ đụng độ với các mã lỗi có ý nghĩa đặc biệt phổ biến . Thông thường, các lệnh in các thông báo từ errno và trả về trạng thái thoát thành công / thất bại. lệnh được dành cho người dùng. chức năng / cuộc gọi hệ thống được dành cho lập trình viên.
Stéphane Chazelas

@ StéphaneChazelas Tôi đã thấy điều đó một vài lần, nhưng không phải trong bất kỳ chương trình nào được thiết lập tốt, tôi phải thừa nhận. Gần đây, tôi đã trở lại errno + 1 trong hệ thống đồ chơi của mình (vì vậy 1 tiếp tục có nghĩa là "bất kỳ lỗi nào") bởi vì tôi nghĩ rằng việc xê-ri hóa sai sót qua ranh giới quy trình có ý nghĩa tốt hơn so với dịch theo quy ước BSD, vì việc thực thi chương trình là về cơ bản các chức năng gọi, và các chức năng sử dụng errno. Tôi sử dụng bộ giải mã trạng thái thoát cuối cùng của riêng mình trong PROMPT_COMMAND (bash) để tôi nhận được một cái gì đó như thế "($numeric_code|$bsd_decoded|$errno_plus_one_decoded)".
PSkocik

1

Theo như tôi biết, chỉ có hai, nhiều hơn hoặc ít hơn, các giá trị tiêu chuẩn - cả hai đều được xác định stdlib.hđể sử dụng với exit ():

  • EXIT_SUCCESS (= 0)
  • EXIT_FAILURE (= 1)

Và giá trị tiêu chuẩn thực tế duy nhất, nghĩa là có cùng ý nghĩa đối với tất cả các chương trình trên thế giới, là 0 (không) là viết tắt của THÀNH CÔNG.

Các chương trình khác nhau giới thiệu các danh sách khác nhau về các mã "thất bại" được trả về để phân biệt hoặc nhấn mạnh các lỗi khác nhau (các loại hoặc mức độ nghiêm trọng khác nhau). Một số chương trình thậm chí sử dụng giá trị được trả về để báo cáo số nguyên lỗi thời gian chạy được phát hiện (ví dụ: số lần kiểm tra đơn vị không thành công trong vụ kiện).

Tôi không khuyên bạn nên giới thiệu bất kỳ loại "tiêu chuẩn mới" nào mở rộng stdlib.h

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.