Trang chủ » làm thế nào để » Làm thế nào để bạn chạy một lệnh trong nền mà không có đầu ra trừ khi có lỗi?

    Làm thế nào để bạn chạy một lệnh trong nền mà không có đầu ra trừ khi có lỗi?

    Nếu bạn là một người bận rộn, thì điều cuối cùng bạn cần là bị làm phiền với một lượng lớn thông báo 'vô dụng', vậy làm thế nào để bạn làm dịu mọi thứ? Bài đăng Hỏi & Đáp của SuperUser hôm nay có một số câu trả lời tuyệt vời để giúp người đọc giảm bớt lượng đầu ra.

    Phiên hỏi và trả lời hôm nay đến với chúng tôi nhờ sự hỗ trợ của SuperUser - một phân ngành của Stack Exchange, một nhóm các trang web Hỏi & Đáp do cộng đồng điều khiển.

    Câu hỏi

    Trình đọc SuperUser Xster muốn biết cách chạy lệnh trong nền mà không có đầu ra trừ khi có lỗi:

    Làm thế nào để bạn chặn đầu ra của lệnh, nhưng hiển thị nó nếu mã thoát của lệnh bị lỗi?

    Làm thế nào để bạn nhận được một lệnh để chạy trong nền mà không có đầu ra trừ khi có lỗi?

    Câu trả lời

    Những người đóng góp cho SuperUser Bob và Maximillian Laumeister có câu trả lời cho chúng tôi. Đầu tiên, Bob:

    Thật không may, giả định rằng stderr chỉ được sử dụng cho đầu ra lỗi không phải lúc nào cũng đúng. Hơn, stderr thường được sử dụng cho bất kỳ và tất cả các đầu ra và chẩn đoán tương tác (nghĩa là đầu ra dành cho người dùng đọc trong một dấu nhắc tương tác).(1) wgetđ là những ví dụ nổi tiếng.

    Một số lệnh sẽ cung cấp một cờ (tức là. -Yên tĩnh hoặc là -im lặng) để chặn đầu ra không lỗi. Đọc trang người đàn ông của họ để xem có tồn tại không.

    Một quy ước khác được tổ chức thường xuyên hơn là mã thoát, một chương trình trả về mã thoát khi thoát. Điển hình là(2), mã thoát của 0 biểu thị thành công và bất kỳ mã thoát nào khác chỉ ra lỗi.

    Với bash, bạn có thể lấy mã thoát của lệnh cuối cùng từ $? biến. Trong , sử dụng $ status biến. Bạn có thể ống stderr vào một tập tin tạm thời và chỉ in nó nếu xảy ra lỗi. Ví dụ ():

    Bạn cũng có thể sử dụng một số phím tắt nếu bạn không xâu chuỗi các lệnh:

    Hoặc là:

    Bạn cũng có thể ống xuất sắc vào cùng một bộ đệm bằng cách sử dụng 2> & 1> / tmp / đầu ra.

    (Chú thích: Tôi thực sự không biết , vì vậy tôi đang điều chỉnh khái niệm này với những gì tôi có thể tìm thấy trong tài liệu của nó. Cú pháp có thể hơi sai. Ngoài ra, bạn có thể sử dụng mktemp để tạo một tệp tạm thời duy nhất. Chạy nó và ghi lại tên tệp trong một biến.)

    Nếu bạn cần chạy toàn bộ nền trong lớp vỏ mà bạn cũng đang sử dụng tương tác cùng một lúc, thì tốt hơn hết bạn nên viết một tập lệnh để xử lý ẩn tập tin đầu ra và chạy tập lệnh đó trong nền bằng các kỹ thuật tiêu chuẩn (). Heck, bạn có thể đặt một cái gì đó như chức năng sau đây vào ~ / .config / fish / config.fish:

    Gọi với chạy im lặng ai đó & (nơi dấu & làm cho nó chạy trong nền)

    Lưu ý rằng điều này sẽ nuốt mã thoát gốc và sẽ kết xuất cả hai xuất sắcstderr trong trường hợp thất bại Bạn có thể tùy chỉnh nó khi cần thiết.

    (1) Không có gì đảm bảo rằng đầu ra lỗi sẽ không xuất hiện trên xuất sắc, một số chương trình sẽ kết xuất tất cả đầu ra ở đó!

    (2) Thật không may, điều này vẫn không phải luôn luôn như vậy. Mã thoát hoàn toàn được kiểm soát bởi chương trình và một số sẽ chỉ ra một số điều kiện thành công với các lối thoát khác không. Một lần nữa, kiểm tra hướng dẫn.

    Tiếp theo là câu trả lời từ Maximillian Laumeister:

    Các tiện ích Unix gửi tin nhắn chung tới xuất sắc, và thông báo lỗi đến stderr, Vì vậy, nếu chúng ta chỉ muốn xem các thông báo lỗi, thì nó sẽ đủ để ngăn chặn xuất sắc vậy thôi stderr được xuất ra giao diện điều khiển.

    Cách để làm điều này (trong cả hai bash) là để chắp thêm > / dev / null ra lệnh. Ống này xuất sắc vào hư vô, nhưng stderr (với thông báo lỗi của bạn) vẫn đến với bảng điều khiển.

    Ví dụ:

    Lệnh tiếng vang 1> / dev / null không in gì cả, vì bình thường xuất sắc đầu ra bị chặn, và không có gì được ghi vào stderr.

    Lệnh người đàn ông không chú ý> / dev / null in một thông báo lỗi, bởi vì Đàn ông viết thông báo lỗi của nó vào stderr.


    Có một cái gì đó để thêm vào lời giải thích? Tắt âm thanh trong các ý kiến. Bạn muốn đọc thêm câu trả lời từ những người dùng Stack Exchange am hiểu công nghệ khác? Kiểm tra chủ đề thảo luận đầy đủ ở đây.