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ề:
- Bạn thực thi
cat /dev/urandom
hoặc tương đương (ví dụ,cat binary_file.dat
). - Rác được in.
Đ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 ++:
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 tr
hoặc xxd
bở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/urandom
mộ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ó?