Điểm:1

Chạy lệnh trên một thiết bị đầu cuối tồn tại khác

lá cờ ru

Giả sử có hai đầu 0 và 1. Tôi nên gõ lệnh gì cho đầu 0

để thực hiện lệnh thực thi thiết bị đầu cuối 1.

Đã biết: {command} > /dev/pts/1 không hoạt động. lệnh được thực thi trên thiết bị đầu cuối 0

và chuyển hướng kết quả đến thiết bị đầu cuối đến thiết bị đầu cuối 1.

Cas avatar
lá cờ in
Cas
Tại sao bạn sẽ muốn điều đó? Việc bạn thực hiện một lệnh trong thiết bị đầu cuối nào không quan trọng. Bạn sẽ nhận được kết quả tương tự, vậy tại sao bạn lại muốn nó ở hai thiết bị đầu cuối? Và tại sao lại chạy lệnh từ terminal 0 và thực thi nó ở terminal 1, trong khi bạn cũng có thể thực hiện lệnh ở terminal 0.
王柏翔 avatar
lá cờ ru
Vì mình muốn lấy thông tin về terminal 1 như pwd, history,...
Nate T avatar
lá cờ it
Chỉ có một lịch sử cho tất cả các phiên bản bash, nằm ở `~/.bash-history`, và thậm chí lịch sử đó cũng rất nhạy cảm. Nó thích chọn và chọn lệnh nào nó lưu
Nate T avatar
lá cờ it
Vâng, bạn cần tmux. Vấn đề của bạn là lý do tmux được tạo. Các phiên đến trước, trước khi chia tách, v.v. chỉ để giải quyết vấn đề nhiều người dùng cần truy cập vào cùng một môi trường trình bao cùng một lúc nhưng từ các vị trí khác nhau.
Điểm:0
lá cờ it

Bạn có thể làm điều này với tmux. Khi bạn bắt đầu một phiên trong terminalA, sẽ có một số nguyên được đặt trong dấu ngoặc nhọn ở góc dưới cùng bên trái của cửa sổ. Đây là id phiên.

Nếu sau đó bạn khởi chạy terminalB, bạn có thể ra lệnh

tmux đính kèm [id]

ở đâu Tôi là số từ terminalA, bạn sẽ có thể điều khiển vỏ terminal đó từ một trong hai terminal.

Tuy nhiên, nếu bạn chỉ thực hiện các bước trước, bạn sẽ mất terminalA. Có một vài cách giải quyết thuận tiện ở đây. Đối với một, nếu bạn bọc gắn lệnh, theo sau là && mục tiêu-lệnh trong ngoặc đơn, bạn có thể chạy chúng trong một lớp con. Về mặt lý thuyết, kết quả của các lệnh đó sẽ không ảnh hưởng đến môi trường của shellB. Điều đó nói rằng, khi kết quả của lệnh đó thường là phá hủy shellB, tôi có thể thấy nó bị trúng hoặc trượt.

Một tùy chọn khác là chạy lệnh trong một quy trình riêng biệt với & nhà điều hành như vậy:

some-terminalB-command & tmux attachment [id] && terminalA-command

Phương pháp này tôi có một chút tự tin hơn. Tuy nhiên, chúng ta có thể làm tốt hơn:

một số-terminalB-lệnh & (tmux đính kèm [id] && terminalA-lệnh)

Điều này sử dụng cả hai phương pháp, do đó gắn bị xóa hai lần khỏi shellB.

王柏翔 avatar
lá cờ ru
Cảm ơn lời đề nghị của bạn. Tôi cố gắng tìm hiểu về tmux, tôi nghĩ rằng tmux có thể lấy thông tin giữa phiên tmux. Tuy nhiên, tôi muốn nhận thông tin về thiết bị đầu cuối bất cứ khi nào nó khởi động, không chỉ các thiết bị đầu cuối này bằng cách sử dụng lệnh tmux.
Nate T avatar
lá cờ it
Xin lỗi, đó là lý do tại sao chúng tôi luôn cố gắng cung cấp thêm ngữ cảnh cho câu hỏi. Bạn càng thêm nhiều ngữ cảnh (ví dụ: tại sao bạn đang cố gắng thực hiện x, mọi chi tiết liên quan) thì càng ít khả năng bạn thấy các câu trả lời không hữu ích và càng có nhiều khả năng bạn sẽ nhận được các câu trả lời hữu ích 'ngoài luồng' nhìn toàn bộ tình huống từ một góc độ khác và giải quyết vấn đề mà không cần trả lời trực tiếp câu hỏi. Đôi khi không có câu trả lời trực tiếp, nhưng luôn có một giải pháp. :) Tôi sẽ xem liệu tôi có thể nghĩ ra thứ gì khác cho bạn không.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.