- Đã dùng tmux trong thời gian dài, nhưng gần đây bắt đầu hoài nghi về độ phức tạp và các giới hạn của tmux (tương thích màu sắc, scrollback, sao chép bằng chuột, không hỗ trợ giao thức, v.v.)
- Các tính năng chính của tmux như duy trì phiên (detach/attach) hay chia/quản lý cửa sổ không nhất thiết chỉ có thể thực hiện bằng tmux
- Tận dụng các công cụ nhẹ theo triết lý Unix như dtach, abduco, shpool có thể giúp chỉ tập trung vào quản lý phiên mà vẫn có được scrollback gốc, sự đơn giản
- Đặc biệt, với tổ hợp
shpool+ ssh, có thể xây dựng môi trường quản lý trực tiếp nhiều phiên từ xa bằng window manager, đồng thời giữ nguyên các tính năng native (thông báo, cuộn, tiêu đề, v.v.) - Dù không hoàn hảo, theo tiêu chí của tác giả thì giải pháp này đã thay thế hoàn toàn tmux, mang lại sự hài lòng với một workflow đơn giản, dễ bảo trì
Ưu và nhược điểm của tmux
- Giữ phiên (detach/attach), quản lý cửa sổ (tab, split), v.v. từng là phần cốt lõi trong workflow mà tmux cung cấp
- Tuy nhiên, nếu không có cấu hình
TERMđúng, sẽ phát sinh vấn đề hiển thị màu và làm tăng độ phức tạp vì phải cân nhắc tương tác giữa terminal và tmux - Việc dùng bộ đệm cuộn cũng đòi hỏi phải làm quen với cơ chế riêng của tmux, và sao chép vùng bằng chuột trong môi trường splits cũng gây bất tiện
- Việc hỗ trợ các tính năng terminal mới như kitty graphics protocol còn hạn chế, và cũng có vấn đề không hỗ trợ các giao thức thử nghiệm
- Cũng có ý kiến phê bình rằng việc diễn giải lại escape code và bổ sung thêm khái niệm phiên/cửa sổ khiến multiplexer cản trở sự phát triển của hệ sinh thái terminal
Tìm cách thay thế tmux
- Duy trì phiên:
- Có thể dùng đơn giản
ctrl-z+fg,nohup,disown, v.v., nhưng khó thay thế hoàn toàn - Đã xuất hiện nhiều công cụ chỉ nhắm đến mục tiêu giữ phiên (
dtach, abduco, shpool)- Kết nối giữa daemon và client bằng tổ hợp fork() và UNIX socket
- Khác với tmux, chúng hỗ trợ scrollback gốc mà không cần split ảo, và một số còn cung cấp khả năng khôi phục buffer
- Theo trải nghiệm sử dụng, phần lớn công cụ thay thế vẫn còn nhiều lỗi và độ hoàn thiện chưa cao, chẳng hạn phím tắt detach không hoạt động trong
nvim - Chỉ shpool là có độ hoàn thiện cao nhất về mặt lệnh detach/attach và khả năng tùy biến keymap
- Có thể dùng đơn giản
- Quản lý cửa sổ:
- Trên máy local thì dùng window manager để chia và sắp xếp
- Ngay cả trong môi trường từ xa (SSH), cũng có thể kết hợp ssh_config và shpool để giữ nhiều phiên độc lập trong các cửa sổ riêng
- Kết hợp với autossh để duy trì phiên ngay cả khi mạng bị ngắt rồi kết nối lại
Workflow mới
- Cá nhân tác giả quản lý cửa sổ bằng ghostty (laptop), sway+foot (PC cá nhân). Máy chủ là VM headless chạy trên Proxmox, luôn duy trì môi trường phát triển qua SSH
- Tự động kết nối nhiều phiên shpool bằng các shortcut ssh, rồi điều khiển độc lập từ window manager local
- Trong
ssh_config, tự động hóa việc attach vào phiên shpool theo từng host - Mỗi terminal có thể truy cập riêng từng phiên như IRC, quản lý dotfiles, hay môi trường neovim riêng biệt
- Trong
- Các tính năng như cuộn native, thông báo, tiêu đề terminal vốn được tmux hỗ trợ kém ổn định thì giờ lại hoạt động tự nhiên hơn
- Cũng có nhược điểm: khi kết nối lại vim thì việc khôi phục trạng thái terminal bị chậm, và có vấn đề resize khi dùng
nvim- Không hỗ trợ nhiều người dùng cùng lúc (nếu autossh chạy đồng thời từ nhiều client thì phiên có thể xung đột)
- Tuy vậy, theo tiêu chí cá nhân thì đây là một sự thay thế hoàn toàn thành công cho tmux
Kết luận
- Dù không hoàn toàn giống hệt, vẫn có thể chuyển sang một workflow quản lý phiên đơn giản và linh hoạt hơn, thoát khỏi độ phức tạp và giới hạn của tmux
- Tùy theo workflow của mỗi người, các công cụ thay thế như shpool là lựa chọn đáng để cân nhắc
7 bình luận
Dạo này người ta dùng AI để tạo ra mấy thứ như tmux rồi đem dùng. Với Xterm.js + react + electron thì trong 3-4 giờ có thể làm ra đến 100 cái kiểu đó, cần thì chỉnh sửa theo thời gian thực để dùng, cảm giác như ăn shabu-shabu vậy? Cứ cho thứ mình muốn ăn vào thì source sẽ đầy ắp.
Tôi đang dùng rất thoải mái với wezterm.
Screen là đỉnh nhất!
cargo install shpool...thôi cứ dùngtmuxvậy...mỗi hệ điều hành đều phải có gói riêng!Có một tân binh xuất sắc tên là Zellij. Rất khuyến nghị.
Zellij - Terminal dành cho nhà phát triển & Ops
Cái này hình như tôi cũng đã đăng lên từ khá lâu trước đây rồi haha
Ý kiến Hacker News
Bài này dành cho người dùng Linux-on-the-Desktop, nhưng tôi muốn nhấn mạnh rằng tmux thực sự tỏa sáng khi dùng cùng iTerm2 trên MacBook
Nhờ tính năng tích hợp tmux của iTerm2, tmux hòa vào workflow của tôi một cách hoàn toàn tự nhiên
Nếu cấu hình như bên dưới trong
~/.ssh/config, thì dù khởi động lại MacBook hay đổi mạng, tôi vẫn luôn có thể dễ dàng truy cập máy chủ phát triển từ xa bằng ssh tmuxNhờ tích hợp giữa iTerm2 và tmux, các tab tmux từ xa và scroll buffer hoạt động như tab cục bộ, và thực ra bạn cũng không cần biết lệnh tmux vẫn dùng được
Tôi dùng Linux trên toàn bộ thiết bị cá nhân, còn khi làm việc thì chủ yếu dùng MacBook, và tmux thực sự hữu ích vì nó tái tạo cùng một môi trường theo cách độc lập nền tảng
Trên Linux tôi dùng Alacritty, nhưng trên macOS thì lúc nào cũng có thứ gì đó không hoạt động ngay do cấu hình phù hợp hoặc khác biệt về cửa sổ/cuộn
Tôi không muốn tốn thời gian cho những khác biệt hệ điều hành kiểu này, nên tổ hợp tmux và iTerm2 giúp tôi có trải nghiệm gần như giống hệt Linux
Việc scrollback trong từng session được tách biệt hoàn toàn cũng là một điểm cộng với tôi
Tôi nghĩ những lời chỉ trích nhắm vào tmux thực ra là vấn đề gần với phía nhà phát triển terminal hơn
Nếu hỗ trợ kém thì chỉ cần chuyển sang terminal hỗ trợ tốt hơn là được
Tôi đang dùng kết hợp mosh và screen
Ngay cả khi máy chủ khởi động lại, tôi vẫn có thể khôi phục session, và khi đổi mạng thì session cũng không bị ngắt
Tham khảo: Immortal SSH Sessions
Tôi đã thử tmux hàng chục lần nhưng không thấy hợp, nên lúc nào cũng quay lại screen
Nhưng sau khi xem mẹo này, tôi lại muốn thử thêm một lần nữa
Tôi thường gặp vấn đề về màu sắc và font với tổ hợp vim, tmux, iTerm2, nên cuối cùng đã bỏ dùng tmux ở máy local
Nó vẫn sống sót qua các lần cập nhật, và lợi ích từ việc giữ session cũng không lớn đến vậy
Nếu giải quyết được vấn đề font thì tôi sẵn sàng thử lại, nhưng hiện giờ không có thời gian
Tôi thắc mắc liệu có terminal nào trên Linux cung cấp tích hợp với tmux như iTerm2 không
Tôi vẫn đang dùng GNU Screen, nhưng cũng sẵn sàng thử lại tmux thêm một lần nữa
Khi đọc bài blog này, tôi lại một lần nữa nhận ra vì sao mình dùng tmux
Nhìn mọi người phải làm rất nhiều việc để tái tạo workflow tương tự tmux thì rõ ràng cứ dùng tmux vẫn tốt hơn nhiều
Thỉnh thoảng copy/paste hơi bất tiện một chút, nhưng tôi không quá bận tâm
Chỉ trích kiểu 'multiplexer tạo ra overhead vô ích' là thứ bạn không cần để tâm nếu không phải người duy trì codebase
Vấn đề copy/paste không phải chỉ riêng tmux mới có
Bất kỳ ứng dụng nào tự vẽ toàn bộ terminal như vim đều có thể gặp
Vấn đề này có thể được giải quyết dễ dàng bằng chuỗi escape terminal OSC52
Nếu dùng đoạn script Python đơn giản bên dưới, bạn cũng có thể gửi thẳng kết quả grep v.v. vào clipboard hệ thống
tmux và nvim đã hỗ trợ OSC52, và bạn cũng có thể dễ dàng tận dụng nó ở nơi khác
Nhân tiện, tôi từng gửi một PR cho tmux, và tôi rất thích việc maintainer Nick Marriott giao tiếp cực kỳ tốt
Mã nguồn cũng được tổ chức rất gọn gàng, và tmux đã trở nên tốt hơn
Tôi đã chán những cuộc thảo luận kiểu cố tạo ra vấn đề khi thật ra không có vấn đề gì
Những lý do tác giả đưa ra không thuyết phục với tôi, thậm chí còn khiến tôi nghi ngờ cả chuyện anh ấy có “hơn 7 năm kinh nghiệm dùng tmux”
Tôi mới biết đến Tmux vài tuần trước, và bị cuốn hút bởi khả năng script có thể gửi phím tới một pane cụ thể theo cách lập trình được
Lấy cảm hứng từ một diễn đàn Nhật Bản, tôi tự hỏi liệu Claude Code (sau đây gọi là CC) có thể tương tác trực tiếp với script CLI cần tương tác hay không, và xác nhận rằng có thể làm điều này bằng Tmux
Vì vậy tôi đã tạo một công cụ nhỏ tên là claude-code-tools, để các agent CLI như CC có thể tạo pane Tmux, chạy script bên trong đó, thậm chí tương tác thời gian thực
Nó giống như một phiên bản terminal của Playwright hay Puppeteer
Liên kết GitHub của claude-code-tools
Với cách này, CC có thể tự động kiểm thử các script CLI cần tương tác, hoặc hiển thị UI ở pane khác rồi kiểm thử bằng trình duyệt với Puppeteer MCP, bật debugger và đặt breakpoint, kết nối đa agent, cùng nhiều ứng dụng khác
Tôi tò mò không biết các công cụ thay thế tmux có thể hiện thực kiểu khả năng mở rộng như vậy hay không
Nhân tiện, screen cũng có thể gửi phím vào pane theo cách lập trình được bằng lệnh "stuff"
Với cách này, Claude Code có thể điều khiển nhiều instance CC khác nhau như Gemini CLI, OpenCode ở chế độ interactive
Nó cho phép một kiểu tích hợp khác với sub-agent truyền thống
Tôi tò mò liệu wrapper tmux-cli có thực sự giúp cải thiện kết quả hay không
Tôi chỉ cần bảo Claude dùng các lệnh tmux sẵn có là nó hoạt động tốt, nên tôi cho chạy mọi lệnh trong session tmux mà không cần Bash riêng
Nếu muốn làm những thứ này dễ hơn ở cấp terminal, tính năng remote control của Kitty cũng rất hay
Giới thiệu Kitty Remote Control
Terminal về bản chất chỉ là file descriptor, nên các công cụ tương tự như script(1), expect(1), chat(8) đã tồn tại từ thập niên 80
Không nhất thiết phải cần tmux
Vấn đề màu sắc v.v. không hiển thị đúng nếu cấu hình TERM không chuẩn trong tmux cũng là vấn đề xảy ra tương tự ở mọi terminal emulator/chương trình
Trên các hệ Unix, Linux, bản thân khái niệm TERM và terminfo/termcap là cốt lõi, nên bắt buộc phải cấu hình đúng
Đây không phải vấn đề riêng của tmux
Nhưng thật đáng tiếc là tác giả lại đổ lỗi cho tmux
Tôi cũng nghi ngờ việc vấn đề cuộn có thực sự là lỗi của tmux hay không, vì tmux dùng alternate screen buffer, vốn được đưa vào để làm rõ đường cơ sở của viewport và giúp thao tác con trỏ dễ hơn
Hầu hết terminal hiện đại đều cho phép cuộn cục bộ ngay cả khi đang ở trạng thái alternate screen, nên đặc tính này không còn được giữ đúng nữa
Hầu hết chương trình nếu không cấu hình mặc định đúng thì cũng sẽ không hoạt động như mong đợi
Với tmux thì việc 'vì sao' không lộ ra ngay nên gây khó chịu, nhưng giải pháp nên là gì thì lại không rõ ràng (ví dụ: có nên để mặc định là 256colors không?)
Điều đó đúng, nhưng khi dùng tmux thì sẽ có thêm một layer cần để tâm
Bên trong tmux phải dùng TERM dành riêng cho tmux, còn bên ngoài thì phải dùng TERM phù hợp với terminal của chính bạn
Chỉ cần nhìn tmux FAQ cũng thấy phần lớn vấn đề hiển thị đều bắt nguồn từ việc TERM chưa được thiết lập đúng
Nhận xét kiểu "multiplexer tạo ra overhead vô ích" thực ra lại là lý do khiến tôi thích tmux
Trong bối cảnh ngày càng nhiều ứng dụng từ bỏ hỗ trợ termcap, tmux giúp tôi vẫn chạy được ứng dụng ngay cả trên terminal cũ như VT520
Tôi không mấy bận tâm việc nhà phát triển terminal nào đó ghét tmux ra sao
Xét cho cùng, từ góc nhìn người dùng thì việc hoạt động tốt quan trọng hơn sự thanh lịch về kiến trúc
Nhân tiện, cá nhân tôi thấy alacritty tốt hơn (dù chủ yếu tôi đang dùng Konsole)
Tôi chỉ muốn nói là thật ghen tị vì bạn có VT520
Tôi đã tìm VT525 từ lâu rồi, nhưng giá quá cao và phần lớn người bán lại ở nước ngoài
Tôi luôn tò mò không biết nosh realizer có chạy tốt trên VT525 chính hãng không
Ngay cả khi tmux biến mất, các ứng dụng có chút không tương thích TERM vẫn có thể được transliteration bằng cách khác
VT420 của tôi không hỗ trợ hardware flow control nên phải dùng software flow control, mà cách này lại không tương thích lắm với ứng dụng terminal ngày nay
GNU Screen là một giải pháp rất tuyệt vời, ngoài ra còn có nhiều tính năng khác
Tôi đã dùng tmux khá nhiều trên các emulator hiện đại, nhưng trên terminal đời cũ thì có vẻ nó thiếu tính năng flow control quan trọng này
Tôi đồng ý rằng tmux hữu ích để xử lý các ứng dụng không hỗ trợ termcap/terminfo
Tôi tò mò vì sao bạn nghĩ alacritty tốt hơn
Trên phần cứng cũ nó khởi động chậm hơn, cũng thiếu các tính năng thực dụng như tab, thậm chí benchmark còn thua kitty/ghostty/konsole/foot
Dù vậy, việc vẫn có người dùng alacritty hẳn là có lý do nào đó, và điều đó khá thú vị
Tôi vẫn sẽ tiếp tục dùng tmux
Tôi thích nó vì quản lý session giữa nhiều dự án và khôi phục session sau khi reboot rất dễ
mouse copy/paste với tmux-yank chưa từng là vấn đề với tôi
Tôi đã dùng cùng một môi trường suốt nhiều năm
Bằng tính năng send-keys của tmux, khi refactor dotfile tôi đã tự động hóa việc dễ dàng cập nhật alias hay file cấu hình trên nhiều pane/session cùng lúc và khởi động lại nvim
Tôi đã tổng hợp trải nghiệm này trong blog và video
Tôi xem cuộc tranh luận "you might not need tmux" cũng giống như "you might not need browser tabs"
Nếu chỉ có một hai terminal session hay trang web thì có thể không cần, nhưng khi phải xử lý nhiều hơn thế thì quản lý cửa sổ trở nên quá bất tiện, và cuối cùng bạn lại tự tái tạo cùng loại tính năng đó
Dạo này tôi chỉ cố tận dụng tối đa khả năng quản lý cửa sổ của window manager mà tôi đang dùng
Thay vì browser tab, terminal tab hay tmux, tôi giao cho window manager việc bố trí cửa sổ, quản lý tab, bookmark v.v., và thấy không có gì bất tiện
Tôi ngày càng tin rằng quản lý tab nên là việc của window manager chứ không phải ứng dụng
Window manager của tôi có thể xếp cửa sổ dạng tile hoặc nhóm các cửa sổ chồng lên nhau thành tab
Những tab này dùng được bất kể là cùng ứng dụng hay khác ứng dụng
Tab trình duyệt có thể dễ dàng tách thành cửa sổ riêng hoặc gộp lại, nhưng tab tmux lại kém linh hoạt hơn ở điểm này
Nếu có một window manager tốt thì bạn có thể tự do tái tổ hợp tab và cửa sổ
Trong cấu hình tmux của tôi có các tab có thể nhấp được
Khả năng quản lý nhiều cửa sổ của MS Windows (Alt Tab, Win Tab, v.v.) thật sự rất tốt
Tôi đặt icon/màu nền khác nhau cho từng terminal để dễ nhận diện, và bản thân hệ điều hành đã gánh giúp khá nhiều phần quản lý cửa sổ
Tôi cũng đã dùng Mac, nhưng ở điểm này thì không hài lòng bằng Windows
Những điều người ta phàn nàn về tmux như buffer scrollback lại chính là động lực khiến tôi dùng tmux
Laptop thứ hai của tôi là một máy Debian cũ chỉ dùng terminal, không có chuột, nên tôi chỉ có thể copy/paste bằng tmux
Với tôi, tmux là không thể thay thế
tmux capture-pane - | vim -đôi khi tiện hơn cả cuộn bằng bánh xe chuộtPhía suckless chọn một hướng tiếp cận hoàn toàn ngược lại: khi thiết kế terminal, họ cố ý không triển khai những tính năng kiểu tmux
Tham khảo: st.suckless.org/goals
Tôi hy vọng Kitty sẽ thành công vì có vẻ nó có thể dẫn dắt tương lai của terminal emulator
Nhưng tôi không thể dùng Kitty cho công việc, và nếu không có tmux thì session, bố cục cửa sổ, trạng thái, copy buffer, scrollback đều sẽ biến mất, nên tôi tuyệt đối không thể từ bỏ nó
Chừng nào chưa có một lựa chọn thay thế phù hợp trên Windows, thì dù có dùng Kitty bên cạnh, tôi vẫn sẽ tiếp tục dùng tmux cho công việc
Tuy nhiên cuối cùng tôi vẫn quay về với tổ hợp tmux và terminal mặc định
Vì nó hoạt động tốt ở mọi nơi, và cách kết hợp công cụ như vậy sẽ sống lâu hơn, nên tmux vẫn là lựa chọn tốt nhất