Những năm 1960-1980, sử dụng máy tính không giống như bây giờ. Máy tính rất đắt và cồng kềnh. Một máy tính có khả năng phục vụ hàng chục người dùng tại cùng một thời điểm. Người dùng kết nối với máy tính bằng các thiết bị như máy đánh chữ và thiết bị đầu cuối có màn hình (dec vt100, 220) thông qua kết nối tuần tự (serial). Nó cũng giống như bạn sử dụng môi trường dòng lệnh (hay giả lập thiết bị đầu cuối, terminal emulator).

Làm việc như thế này rất bất tiện. Trong các chương trình dòng lệnh hiện nay, nếu bạn nhập sai, bạn có thể dùng các phím mũi tên để quay lại và sửa. Nhưng ngày xưa, việc sửa lại khó hơn nhiều.

Bài tập khởi động: Cài đặt và sử dụng chương trình dòng lệnh dash trong vòng 30 phút. Bài khó hơn: Thay dash làm chương trình dòng lệnh chính cho tài khoản của bạn và sử dụng trong một ngày.

Để giải quyết vấn đề này, người ta tạo ra các thư viện cung cấp chức năng sửa đổi dòng lệnh' (command-line editing) như readline. Sửa đổi dòng lệnh' tức là khả năng dịch chuyển con trỏ dòng lệnh sang trái sang phải bằng các phím như phím mũi tên, và ghi nhớ, điền câu lệnh đã nhập trước đó vào sau dấu nhắc lệnh để có thể sửa lệnh. readline được gắn vào các chương trình dòng lệnh.

Việc gắn vào chương trình dòng lệnh là có lý do. Tháo lắp phần cứng để thêm chức năng cho một thiết bị đầu cuối là điều khó khăn và tốn kém. Thêm mã mới vào phần mềm giúp cho tất cả mọi người nhận được thay đổi. Không chỉ vậy, người dùng từ mạng (rlogin) cũng có thể sử dụng các tính năng này. Tất nhiên, chương trình dòng lệnh sẽ nặng hơn và chạy chậm hơn. Các hệ điều hành như Debian và Ubuntu cài đặt dash dưới tên /bin/sh, còn chương trình dòng lệnh người dùng là bash.

Dù vậy, sửa đổi dòng lệnh vẫn không thoát khỏi những hạn chế. Con trỏ không thể dịch chuyển ngay đến một vị trí, hay tua tới một câu lệnh nào được. Thư viện sửa đổi dòng lệnh cố thêm nhiều phím hơn để hoàn thành những tác vụ thường gặp, như ctl-A đi về đầu dòng, ctl-E đi về cuối dòng. Nhưng vẫn không giải quyết được hết các vấn đề! Thư viện luôn thiếu một tác vụ! Bàn phím luôn thiếu một phím!! Con người làm sao nhớ hết được đống phím kỳ quái kia!!!

Nhưng rồi thời đại đồ họa đến. Con chuột xuất hiện. Tất cả chỉ để hỗ trợ tác vụ soạn thảo văn bản. Cơ hội ngàn vàng để chúng ta tạo ra cách giải quyết đẹp hơn. Cơ hội ngàn vàng để khắc phục sự phình to và chậm chạp của phần mềm dòng lệnh mà readline là thủ phạm. Để chúng ta bỏ đi hết những "thủ thuật" (hacks) chỉ thị phần cứng in ra một bảng biểu, hay một phần mềm mà nội dung phủ kín màn hình (như phần mềm top, vi, emacs, tôi gặp khó khăn trong khi miêu tả cái này), mà thay bằng những phần mềm đồ họa, cập nhật giao diện theo cách mà "nó nên làm" thay vì dùng thủ thuật đơn lẻ mà cần phần cứng hiểu.

Đáng lẽ mọi người có thể quay về dùng dash với tâm trạng thoải mái. Và sửa đổi dòng lệnh theo cách khoa học, đạt được hiệu quả công việc cao nhất. Nhưng thế giới vẫn kẹt trong thời kỳ sử dụng máy đánh chữ và những thiết bị đầu cuối văn bản, cho dù họ đã ở thời đại đồ họa.

Người ta nói rằng UNIX là một hệ điều hành chia-sẻ-thời-gian, nghĩa là nó cho phép nhiều người cùng sử dụng tại cùng một thời điểm, và nhiều chương trình cùng chạy. Nhưng đối với một người dùng, họ chỉ tương tác với một chương trình, cùng lắm một nhóm vài ba chương trình tại một thời điểm.

Đồ họa xuất hiện, khiến một phiên làm việc của người dùng đa nhiệm hơn thấy rõ. Vì một màn hình đồ họa là một hình chữ nhật chứa các điểm ảnh (pixel), việc vẽ lên màn hinh trở nên tự do hơn, tùy ý hơn. Trong khi việc vẽ trên một thiết bị đầu cuối có màn hình (sẽ gọi là vt102) và máy đánh chữ là khá hạn chế, cần sự hỗ trợ của phần cứng. Muốn vẽ một bảng thì chỉ thị phần cứng bật sáng các điểm ảnh. Một thanh trạng thái tiến lên bằng cách đổi màu một vài điểm ảnh. Trong khi ở vt102, tôi nhớ là phải "chuyển chế độ", phải in ra \r để quay về đầu dòng rồi viết lại nội dung. Đồ họa mạnh mẽ hơn vt102 rất nhiều. Và việc đầu tiên sau khi nguòi ta tạo ra trình quản lý cửa sổ đồ họa là tạo ra chương trình giả lập thiết bị đầu cuối vt102 (terminal emulator).

Bây giờ một vt102 không còn là phần cứng, mà là phần mềm. Ta có thể tùy biến, mở rộng nó. Không còn vấn đề chi phí nâng cấp phần cứng nữa. Phần mềm dòng lệnh có thể loại bỏ các lệnh gọi tới readline, và làm đúng công việc của mình là chạy lệnh. Việc xử lý các phím sang trái sang phải là việc của môi trường dòng lệnh. Việc điền vào câu lệnh trước đó là việc của môi trường dòng lệnh.

Nhưng hiện nay trên các hệ thống UNIX, các môi trường dòng lệnh hầu như chẳng làm gì cả, ngoài việc hỗ trợ những phím của các vt102 ngày xưa. Sửa đổi dòng lệnh vẫn là do chương trình dòng lệnh làm. Việc sử dụng phím mũi tên để di chuyển con trỏ rất chậm chạp. Chúng ta vẫn không dùng được dash.

Trong khi đó, hệ điều hành Plan 9 có cách làm việc trong môi trường dòng lệnh mới. Chương trình dòng lệnh rc chỉ có nhiệm vụ chạy lệnh. Môi trường dòng lệnh được cung cấp bởi trình quản lý cửa sổ rio (gọi là một cửa sổ chạy rc). Một cửa sổ dòng lệnh giống như một trình soạn thảo văn bản, người dùng có thể tự do chỉnh sửa tùy ý bằng chuột. Nếu bạn nhập sai lệnh, bấm chuột vào chỗ bạn muốn sửa và thực hiện thay đổi. Muốn chạy một lệnh cũ, kéo lên và bôi đen vào toàn bộ câu lệnh, bấm chuột giữa và chọn `send'. Toàn bộ nội dung trong cửa sổ chạy rc mà bạn thấy đều nằm trong tập tin /dev/text. Nếu bạn muốn tìm một lệnh mà bạn đã chạy trước đó rất lâu, dùng grep để tìm trong /dev/text.

Chương trình dòng lệnh rc chỉ có mỗi chức năng chạy lệnh. Nhờ sự phát triển của công nghệ, triết lý UNIX - mỗi chương trình chỉ có một nhiệm vụ và phải làm tốt - được bảo toàn. Công việc sửa đổi dòng lệnh được dồn hết vào trình quản lý cửa sổ - nhưng nhờ có chuột, và nguyên tắc của Plan 9 là chỉ dùng chuột để thao tác với văn bản, trình quản lý cửa sổ cũng không phải làm quá nhiều công việc.

plan9port đưa các phần mềm Plan 9 sang UNIX. Nhờ có một môi trường dòng lệnh tốt (9term), nên việc sử dụng chương trình dòng lệnh dash trở nên vô cùng dễ dàng. Gần một tháng nay tôi đã đặt dash làm chương trình dòng lệnh cho tài khoản của tôi (tại /etc/passwd), vừa mới đổi sang rc. Cả hai đều không có readline.

Thực ra dash là lựa chọn duy nhất của tôi cho chương trình dòng lệnh POSIX. Các chương trình dòng lệnh khác đều sử dụng readline, và đều không hoạt động. Thật không phải là dư âm của thời kỳ máy đánh chữ, mà chúng ta đang sống ở thời kỳ máy đánh chữ, thời kỳ của vt102 vậy!

Cuối cùng, chúng ta sẽ đi thăm quan một số hình ảnh các chương trình dòng lệnh hiển thị những thứ kỳ lạ.

Dấu nhắc lệnh mặc định của ash: ~ $ [6n Xóa một ký tự của ash trong 9term, ash thêm [J vào sau https://imgur.com/a/ExpTuvn

zsh in ra những thứ bẩn thỉu: https://imgur.com/a/iPW5Pdc ! ! bash, mksh, oksh in ra chuông mỗi khi bấm nút backspace mà chưa nhập gì: https://imgur.com/a/e1ULRKV

Bản chất của vi và mg (openbsd emacs): https://imgur.com/a/5hQu8re

apk del zsh tcsh bash mksh oksh

(1/12) Purging apk-tools-zsh-completion (2.14.9-r1) (2/12) Purging bash-doc (5.2.37-r0) (3/12) Purging bash (5.2.37-r0) Executing bash-5.2.37-r0.pre-deinstall (4/12) Purging gcc-zsh-completion (5.9-r5) (5/12) Purging git-zsh-completion (5.9-r5) (6/12) Purging mksh-doc (59c-r4) (7/12) Purging mksh (59c-r4) Executing mksh-59c-r4.pre-deinstall (8/12) Purging oksh-doc (7.6-r1) (9/12) Purging oksh (7.6-r1) Executing oksh-7.6-r1.pre-deinstall (10/12) Purging tmux-zsh-completion (5.9-r5) (11/12) Purging zsh-doc (5.9-r5) (12/12) Purging zsh (5.9-r5) Executing zsh-5.9-r5.pre-deinstall Executing busybox-1.37.0-r14.trigger OK: 1722 MiB in 576 packages

Author: not me

mouse vs keyboard

Điều khó chịu nhất một người dùng Unix cảm thấy khi sử dụng Plan 9 có lẽ là việc họ phải dùng đến con chuột nhiều hơn.

Họ thường phàn nàn rằng dùng con chuột là chậm hơn so với việc dịch con trỏ bằng các phím mũi tên hay phím hjkl (của vi). Điều này không đúng. Dùng con chuột có vẻ chậm nhưng thực ra lại nhanh hơn dùng các phím:

Link

Link

Link

(tóm tắt: người dùng bàn phím cứ tưởng mình nhanh nhưng bấm giờ lại cho thấy là chậm hoặc không nhanh hơn, điều hướng con trỏ bằng bàn phím sẽ rơi vào trạng thái "mất trí nhớ" hay thôi miên, mất luôn nhận thức về thời gian ^_^)

Nói ngắn gọn, dịch chuyển con trỏ cần sự tập trung cao độ để dịch chuyển con trỏ đúng theo ý muốn; điều đó khiến cho ta bị mất nhận thức về sự trôi qua của thời gian -- hãy nghĩ đến việc bạn đang say mê làm việc và ngạc nhiên khi nhìn đồng hồ -- trong khi việc sử dụng con chuột diễn ra theo bản năng, để đầu óc có chỗ suy nghĩ về những việc cao siêu hơn, như là phàn nàn về con chuột chẳng hạn.

Một suy nghĩ phổ biến là việc đưa tay từ bàn phím tới con chuột và rồi đưa về sẽ mất thời gian và làm gián đoạn việc đánh máy. Đúng, nhưng nó không mất thời gian như bạn nghĩ đâu. Và nếu bạn dùng bàn phím không có hàng phím số, con chuột sẽ ở gần hơn. Kể cả có hay không có hàng phím số, bạn sẽ nhanh làm quen và không cần phải tìm con chuột. Tay bạn sẽ tự đặt con chuột ở một vị trí và tự động sang đúng vị trí đó, thường là để chuẩn bị cho một thao tác chuột trong khi tay kia đang đánh máy.

Đúng là dùng chuột sẽ chậm hơn cho một số việc kiểu như xóa ký tự tab ở đầu mỗi dòng so với việc sử dụng bàn phím và gõ "^xjxjxjxjxjxjxjxjxjxjxjxjxj" nếu bạn dùng vi. Nhưng trường hợp này bạn đang lập trình trong trình soạn thảo văn bản (bằng một vòng lặp for được thực hiện thủ công) hơn là việc soạn thảo văn bản.

Khi con chuột được tối ưu, chúng tôi thấy rằng việc chọn một dòng và nhập Edit s/^<tab>//g trong acme hay s/^<tab>//g trong sam sau đó chạy sẽ nhanh hơn. Thao tác này phổ biến nên acme cung cấp hai mã kịch bản dòng lệnh để bạn có thể nhập |unind và |ind trong thanh trên của cửa sổ và bấm vào mỗi khi bạn cần.</tab></tab>

Hãy so sánh việc thực hiện các lệnh chỉnh sửa như tìm kiếm và thay thế khi sử dụng acme hoặc sam và vi. Trong acme bạn có thể chọn đoạn mà bạn muốn, nhập lệnh là xong. Trong vi, bạn phải dịch con trỏ về một đầu, đánh dấu vị trí, dịch con trỏ sang đầu kia, lại đánh dấu, rồi mới nhập lệnh. Việc dịch chuyển con trỏ mất nhiều thời gian hơn dùng con chuột. Bạn có thể tự bấm giờ.

Với nhiều người dùng Plan 9, sau khi sử dụng con chuột trong Plan 9 trong một thời gian dài, rồi sử dụng vi trên Unix khiến họ nhận ra mình đã tốn bao nhiêu thời gian để nhìn vào màn hình trong lúc đang dịch con trỏ bằng hjkl. Sau khi thoát khỏi trạng thái thôi miên mà Tog miêu tả, tôi cảm thấy vô cùn bực bội. Đúng là tôi đang tập trung nhìn con trỏ dịch chuyển, nên tất cả những gì tôi có thể nghĩ là "cáu thật, nếu mình có thể bấm chuột vào chỗ mình muốn đến thì giờ mình đã đến được rồi".

Một điểm tốt của con chuột là nó trực quan hơn. Hãy xem cách mà thanh cuộn hoạt động trong Plan 9: bấm chuột trái hay chuột phải để cuộn sẽ di chuyển lên xuống dựa trên vị trí của bạn trong thanh cuộn. Trong một hệ thống dựa trên con trỏ sẽ khó làm hơn. Cắt và dán bằng hai ba thao tác chuột liên tiếp trong acme và rio nhanh hơn khi làm điều đó trong những hệ thống dùng con trỏ, đặc biệt khi bạn đang di chuyển một đoạn văn bản không được căn dòng. Bạn có thể tự bấm giờ.

Tất nhiên là bạn cần có một con chuột tốt. Nó cần có ba nút bấm, không phải hai nút với một con lăn ở giữa. Plan 9 sử dụng chuột giữa nhiều lắm. Bạn sẽ bị đau ở bất kỳ ngón tay nào bạn dùng để bấm con lăn.

Điều quan trọng là bạn cần sử dụng con chuột trong vòng một đến hai tuần trước khi phàn nàn về nó. Rồi bạn sẽ đồng ý với chúng tôi.

Bạn cảm thấy mình làm việc hiệu quả hơn trong emacs và những trình soạn thảo văn bản tương tự vì bạn luôn phải động não trong việc chỉnh sửa, còn trong acme và sam bạn cảm thấy chậm hơn vì bạn làm theo bản năng, nhưng thực tế bạn lại đang làm nhanh hơn.

Khi bạn gõ sai chuỗi cần tìm kiếm, trong emacs bạn dùng ctl-S và ctl-R, việc sửa lỗi rất vất vả; trong acme, lệnh "Look" cho phép bạn chỉ việc sửa đổi thanh trên và thực hiện lại việc tìm kiếm.

Dear author of this article: unknown