ls cư xử khác nhau dưới bước

Tôi không biết làm thế nào để gỡ lỗi tình huống này:

1) Tôi cố gắng thực hiện:

ls /home/user

2) ls khối và không in bất cứ điều gì. Tôi giả sử đó là vì / home / user chứa / home / user / sshfs_files, là một thư mục được gắn sshfs, nhưng mạng bị sập trên máy của tôi (mạng đã hoạt động trở lại nhưng tôi đoán kết nối SSH đã bị mất).

3) Vì tôi muốn chắc chắn rằng thư mục được gắn sshfs là nguyên nhân của việc gác máy này, tôi đã thử cùng một lệnh theo strace:

strace -o /tmp/log ls /home/user

4) Và ls thực sự làm việc! Vì vậy, bây giờ tình hình là ls hoạt động theo strace nhưng tự nó chặn.

Làm thế nào là nó thậm chí có thể? Làm thế nào để giải thích tình huống này? Làm thế nào tôi có thể thấy nơi ls chặn nếu nó không chặn dưới bước?

Cảm ơn!

networking sshfs strace

— người dùng368507
nguồn

Thế còn ls /home/user | cat? Điều này có thể chỉ đơn giản là lsphát hiện ra cách xử lý đầu ra của nó ...

— rozcietrzewiacz

Lưu ý rằng nó sẽ có ý nghĩa, vì đầu ra của ls(trên các thiết lập điển hình) được tô màu. Việc tô màu chỉ được mong muốn khi đầu ra không được chuyển hướng, bởi vì nếu không thì các chuỗi thoát sẽ làm rối loạn đầu ra. Và để làm cho đầu ra đầy màu sắc, lsphải xác định loại của từng mục. Tại thời điểm này, nó bị treo với sshs_filesthư mục của bạn .

— rozcietrzewiacz

@rozcietrzewiacz: Bạn nên đưa ra nhận xét của mình một câu trả lời, để người dùng5528 có thể chấp nhận nó. Câu hỏi không được chấp nhận cung cấp cho bạn một carma xấu.

— người dùng không xác định

Vì nhận xét của @ rozcietrzewiacz là chính xác, điều đó làm cho điều này gần như trùng lặp chính xác câu hỏi này . Ít nhất câu trả lời được chấp nhận ở đó áp dụng ở đây.

— jw013

@ jw013 Đúng. Gần, nhưng không chính xác: tiêu đề có thể tạo sự khác biệt cho những người khác gặp vấn đề tương tự. Vì vậy, ... Điều này cuối cùng có thể bị đóng cửa, nhưng kể từ khi được nhắc, tôi sẽ đăng câu trả lời.

— rozcietrzewiacz

Câu trả lời:

Như jw13 đã chỉ ra, đây gần như là một bản sao chính xác của " ls mất nhiều thời gian trong thư mục nhỏ " - ít nhất là theo như lời giải thích có liên quan. Hãy chắc chắn để đọc các ý kiến ở đó quá!

Tóm lại, một số chương trình dòng lệnh phổ biến như lscó thể hoạt động khác nhau khi đầu ra của chúng không đi trực tiếp đến một thiết bị đầu cuối. Trong trường hợp này, lscó lẽ là bí danh ls --color=auto, cố gắng phát hiện loại của từng mục nhập thư mục cho mục đích tô màu. Tại thời điểm của nó, nó bị treo, không thể thực hiện một stathoạt động trên thư mục gắn trên sshfs của bạn.

Thêm vào câu trả lời của MadSellectist cho câu hỏi được đề cập : Nếu bạn tò mò về cách stracehoặc gdbcó thể giúp gỡ lỗi ls', tôi khuyên bạn nên chạy một cái gì đó như

 strace -o /tmp/log ls --color=always /home/user

— rozcietrzewiacz
nguồn

Vâng, đó là hành vi phổ biến cho các chương trình đang gỡ lỗi, và không thực sự có thể tránh được. Việc khởi tạo các biến thay đổi, có nhiều thông tin hơn, luồng chương trình được thay đổi.

Hoặc bạn có được nguồn của ls và chạy nó thông qua một trình gỡ lỗi khác, hy vọng nó sẽ hiển thị lỗi hoặc bạn cố gắng tìm câu trả lời, cách giải quyết theo những cách khác.

— người dùng không biết
nguồn

Tôi đã thử với gdb và tôi cũng không chặn

— user368507

@ user5528: Vì vậy, có lẽ bạn cần thử nghiệm: Điều gì xảy ra nếu kết nối ssh không bị mất? Bạn có thể lọc sshfs-dir ls [^s]*chẳng hạn? Làm những gì find ~ maxdepth -1 -lsnăng suất?

— người dùng không xác định

vấn đề được giải quyết trong các ý kiến cho bài viết gốc. cảm ơn

— user368507

Trình gỡ lỗi không thay đổi việc khởi tạo các biến. Nó có thể thay đổi thời gian thực hiện một cách tinh tế khi nó làm chậm một số phần nhất định của chương trình và điều này có thể thay đổi hành vi của các điều kiện chủng tộc và các lỗi đặc biệt quỷ quyệt khác, nhưng không thay đổi khởi tạo.

— psusi

Trình gỡ lỗi chắc chắn có thể thay đổi khởi tạo khi các biến không được khởi tạo trong mã. Chúng được khởi tạo độc đáo thành 0 chạy trong trình gỡ lỗi và được khởi tạo cho bất cứ thứ gì có trong bộ nhớ ở chế độ phát hành.

— Étienne