Làm thế nào để ngăn chặn đầu ra giao diện điều khiển ngẫu nhiên phá vỡ thiết bị đầu cuối?


23

Có nhiều câu hỏi về SE chỉ ra cách phục hồi từ thiết bị đầu cuối bị hỏng cat /dev/urandom. Đối với những người không quen thuộc với vấn đề này - đây là những gì về:

  1. Bạn thực thi cat /dev/urandomhoặc tương đương (ví dụ, cat binary_file.dat).
  2. Rác được in.
  3. Điều đó sẽ ổn thôi ... ngoại trừ thiết bị đầu cuối của bạn tiếp tục in rác ngay cả khi lệnh đã kết thúc! Đây là một ảnh chụp màn hình của một văn bản bị đầu hàng sai trong thực tế là đầu ra g ++:

    Ảnh chụp màn hình ví dụ

    Tôi đoán mọi người đã đúng về lỗi C ++ đôi khi quá khó hiểu!

Giải pháp thông thường là chạy stty sane && reset, mặc dù thật khó chịu khi chạy nó mỗi khi điều này xảy ra.

Do đó, điều tôi muốn tập trung vào câu hỏi này là lý do ban đầu tại sao điều này xảy ra và làm thế nào để ngăn chặn thiết bị đầu cuối bị phá vỡ sau khi lệnh đó được ban hành. Tôi không tìm kiếm các giải pháp như chuyển các lệnh vi phạm đến trhoặc xxdbởi vì điều này đòi hỏi bạn phải biết rằng chương trình / tệp xuất ra nhị phân trước khi bạn thực sự chạy / in nó và cần được ghi nhớ mỗi khi bạn xuất ra dữ liệu đó .

Tôi nhận thấy hành vi tương tự trong bộ đệm khung URxvt, PuTTY và Linux vì vậy tôi không nghĩ đây là vấn đề cụ thể của thiết bị đầu cuối. Nghi can chính của tôi là kết quả ngẫu nhiên có chứa một số mã thoát ANSI rằng flips mã hóa ký tự (trên thực tế, nếu bạn chạy cat /dev/urandommột lần nữa, rất có thể nó sẽ Unbreak nhà ga, mà dường như để xác nhận giả thuyết này). Nếu điều này là đúng, mã thoát này là gì? Có bất kỳ cách tiêu chuẩn để vô hiệu hóa nó?

Câu trả lời:


22

Không:

  • không có cách tiêu chuẩn để "vô hiệu hóa" và
  • các chi tiết của sự cố thực sự là thiết bị đầu cuối cụ thể, nhưng
  • có một số tính năng thường được triển khai mà bạn có thể nhận được hành vi sai trái.

Đối với các tính năng thường được triển khai, hãy tìm đến bộ ký tự thay thế kiểu VT100, được kích hoạt bởi ^N^O(bật / tắt). Điều đó có thể bị đè nén trong một số thiết bị đầu cuối khi sử dụng chế độ UTF-8, nhưng các thiết bị đầu cuối cùng có cơ hội dư dật để làm dơ bẩn màn hình của bạn (nói về màn hình GNU, Linux console, PuTTY đây) với chuỗi thoát họ làm công nhận.

Ví dụ, một số chuỗi thoát khác dựa trên các phản hồi từ thiết bị đầu cuối đến truy vấn (chuỗi thoát) của máy chủ. Nếu chủ nhà không mong đợi nó, kết quả là rác trên màn hình.

Trong các trường hợp khác (ví dụ như được thấy trong các thiết bị mạng có trình tự thoát mã hóa cứng cho bảng điều khiển Linux), các thiết bị đầu cuối khác sẽ thấy điều đó như bị sảy thai và dường như bị đóng băng.

Vì vậy, ... bạn có thể tập trung vào chỉ một thiết bị đầu cuối, loại bỏ bất cứ thứ gì trông có vẻ phiền toái (ví dụ, một số gợi ý loại bỏ khả năng sử dụng chuột để định vị trong trình chỉnh sửa) và bạn có thể nhận được thứ gì đó không có lỗ hổng rõ ràng. Nhưng đó chỉ là một thiết bị đầu cuối.


0

Nếu bạn kiểm soát và biết một lệnh sẽ làm bạn khó chịu, tôi thường sẽ xem đầu ra trong một cái gì đó giống như ít hơn.

head -n4 /dev/urandom | less

Điều này thông thường dường như để thu gom rác và in nó với một đại diện lành mạnh, không bao giờ có bất kỳ rắc rối nào tôi nhớ sau khi thoát khỏi q , điều mà tôi in đậm khiến bạn không quen với việc bỏ ít hơn.


2
Câu hỏi đặc biệt nói rằng anh ấy không tìm kiếm giải pháp đòi hỏi bạn phải biết trước rằng chương trình tạo ra đầu ra nhị phân.
Barmar

-1

Đưa đầu ra của lệnh của bạn, v.v. vào tee -


2
Điều đó sẽ giúp như thế nào? Nó vẫn sẽ in đầu ra, nhưng cũng lưu nó trong một tập tin.
Barmar

Có lẽ bạn có ý morehay less?
Barmar

mỗi OP với sự nhấn mạnh của tôi: "... sau . lệnh đó được ban hành Tôi không tìm kiếm các giải pháp như đường ống các lệnh xúc phạm"
Jeff Schaller
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.