Các quy tắc bất thành văn của chương trình Terminal

Tôi đã dành vô số giờ trong terminal, và có một điều kỳ lạ cứ lặp đi lặp lại. Mặc dù không có lệnh trung tâm nào hướng dẫn các nhà phát triển cách xây dựng công cụ CLI, nhưng tất cả chúng đều nói cùng một ngôn ngữ. q thoát. Ctrl-C hủy. Màu sắc biến mất khi bạn chuyển đầu ra sang nơi khác.

Đây không phải là ngẫu nhiên. Đây là sự tiến hóa.

Sự nhất quán này đến từ các tiêu chuẩn POSIX, các quy ước Unix cũ và quán tính thuần túy. Khi đủ công cụ đồng ý về một điều gì đó, sự bất đồng sẽ trở thành vấn đề trải nghiệm người dùng. Dưới đây là những mẫu mà tôi đã nhận thấy, những mẫu khiến dòng lệnh trở nên trực quan ngay cả khi bạn đang sử dụng một thứ hoàn toàn mới.

---

Các Quy Tắc Bất Thành Văn

Hướng Dẫn về Màu Sắc và Hiển Thị

Các Phím Tắt và Quy Ước Nhập Liệu

Quy Tắc 5: Hỗ Trợ Sơ Bộ Các Phím Tắt Readline

Người dùng mang theo những kỳ vọng từ bash. Những điều này nên hoạt động hầu hết:

• Ctrl-E nhảy đến cuối dòng
• Ctrl-A nhảy đến đầu dòng
• Ctrl-W xóa từ cuối cùng

Bạn có cần tương thích hoàn toàn với readline không? Có lẽ là không. Nhưng người dùng sẽ thử Ctrl-A trong công cụ của bạn và mong đợi nó hoạt động. Khi nó không hoạt động, họ sẽ nhận ra.

"Từ cuối cùng" là gì? Đối với hầu hết các chương trình, nó được phân tách bằng dấu cách. Ctrl-W trong bash xóa mọi thứ trở lại dấu cách cuối cùng. Hành vi đó đến từ chế độ cooked trong trình điều khiển terminal của hệ điều hành, vì vậy đó là điều người dùng mong đợi.

Quy Tắc 7: Dấu Gạch Ngang Có Nghĩa là Stdin hoặc Stdout

Điều này làm tôi ngạc nhiên khi lần đầu tiên tôi nhận thấy nó. Nhiều công cụ CLI chấp nhận một dấu gạch ngang duy nhất làm đối số đặc biệt có nghĩa là "đọc từ stdin" hoặc "ghi vào stdout."

Một số ví dụ: cat - đọc từ stdin tar cf - /path |-gzip > file.tar.gz truyền archive đến stdout diff file1 - so sánh file1 với stdin

Đó là một quy ước, không phải là một yêu cầu. Nhưng khi bạn thấy nó, bạn sẽ hiểu ý tác giả.

Tại Sao Điều Này Quan Trọng?

Đây là vấn đề. Những mẫu này không phải là quy tắc mà ai đó đã viết ra và thực thi. Chúng là những quy tắc tự phát. Khi đủ công cụ làm điều gì đó theo một cách, người dùng sẽ học theo cách đó. Các công cụ mới kế thừa cùng một hành vi vì việc chống lại nó sẽ tạo ra ma sát.

Tôi nhớ lần đầu tiên tôi sử dụng một công cụ không phản hồi q để thoát. Đó là một TUI tùy chỉnh để quản lý các container Docker. Tôi nhấn q. Không có gì. Tôi nhấn Ctrl-C. Không có gì. Tôi phải giết nó bằng Ctrl-Z và kill -9. Nó cảm thấy bị hỏng, mặc dù nó có thể hoạt động "đúng cách."

Đó là điểm mấu chốt. Trong terminal, quy ước CHÍNH LÀ sự đúng đắn. Nếu công cụ của bạn chống lại kỳ vọng của người dùng, nó sai, bất kể tài liệu của bạn nói gì.

Dự án CLI Guidelines cố gắng chính thức hóa một số điều này. Nó đáng để đọc. Nhưng thành thật mà nói, cách nhanh nhất để học các quy ước này không phải là đọc. Đó là sử dụng terminal hàng ngày. Các mẫu sẽ thấm vào qua bộ nhớ cơ bắp.

Một Mẫu Đáng Chú Ý

Lần tới khi bạn khám phá một công cụ CLI mới, hãy thử điều này. Quan sát cách nó xử lý các ngắt. Lưu ý xem đầu ra có màu có biến mất khi bạn chuyển nó đi đâu đó không. Quan sát điều gì xảy ra khi bạn nhấn Ctrl-A trong một trường nhập liệu.

Bạn sẽ bắt đầu thấy các mẫu ở khắp mọi nơi. Bởi vì chúng không phải là ngẫu nhiên. Chúng là những quyết định tích lũy qua nhiều thập kỷ, hội tụ về một sự hiểu biết chung về cách terminal nên hoạt động.

Và sự kỳ lạ mà tôi đã đề cập lúc đầu? "Sự hài hòa kỳ lạ" của các lệnh không liên quan hoạt động nhất quán? Nó không hề kỳ lạ chút nào khi bạn nhận ra nó đến từ cùng một nguồn gốc như ngôn ngữ. Quy ước. Lặp lại. Thời gian.

Các công cụ của bạn đang nói cùng một phương ngữ bởi vì tất cả chúng ta đều học nó từ nhau.

Bạn cũng có thể thích

• Tại sao pipe đôi khi bị "kẹt": buffering
• SSH và SCP: Hai công cụ mọi nhà phát triển thực sự nên hiểu rõ
• I/O Linux thông lượng cao trong Rust: io_uring, Tokio & Zero-Copy Networking
• Xây dựng Microservice hiệu suất cao với Rust và Axum: Hướng dẫn sản xuất hoàn chỉnh

Kiểm tra kiến thức