Lý do thực hiện trong tập lệnh bao bọc

Tôi đã thấy các ví dụ về trình bao bọc mà tóm lại là:

#!/bin/bash

myprog=sleep
echo "This is the wrapper script, it will exec "$myprog""

exec "$myprog" "$@"

Như đã thấy ở trên, họ sử dụng execđể thay thế vỏ mới được tạo gần như ngay lập tức bằng $myprog. Người ta có thể đạt được điều tương tự mà không cần exec:

#!/bin/bash

myprog=sleep
echo "This is the wrapper script, it will exec "$myprog""

"$myprog" "$@"

Trong ví dụ cuối cùng này, một cá thể bash mới được bắt đầu và sau đó $myprogđược bắt đầu như là một tiến trình con của cá thể bash.

Những lợi ích của phương pháp đầu tiên là gì?

Việc sử dụng execlàm cho trình bao bọc trở nên trong suốt hơn, nghĩa là nó ít có khả năng người dùng hoặc ứng dụng gọi tập lệnh cần phải biết rằng đó là một rơle lần lượt khởi chạy chương trình Real real.

Đặc biệt, nếu người gọi muốn giết chương trình, họ sẽ giết quá trình họ vừa khởi chạy. Nếu tập lệnh bao bọc chạy một tiến trình con, người gọi sẽ cần biết rằng họ nên tìm ra con của trình bao bọc và giết nó. Kịch bản trình bao bọc có thể đặt bẫy để chuyển tiếp một số tín hiệu, nhưng điều đó sẽ không hoạt động với SIGSTOP hoặc SIGKILL không thể bắt được.

Gọi execcũng tiết kiệm một chút bộ nhớ (và các tài nguyên khác như PID, v.v.) vì không cần phải giữ thêm một lớp vỏ xung quanh mà không còn gì để làm.

Nếu có nhiều trình bao bọc, các vấn đề sẽ tăng lên (khó khăn trong việc tìm đúng quy trình để tiêu diệt, chi phí bộ nhớ, v.v.).

Một số shell (ví dụ shell Korn) tự động phát hiện khi lệnh là lệnh cuối cùng và không có bẫy hoạt động và đặt ẩn exec, nhưng không phải tất cả đều làm (ví dụ: không bash).

Tìm kiếm không có bản sao ... tham khảo cẩm nang FreeBSD , đưa ra lý do đủ tốt:

Câu execlệnh thay thế tiến trình shell bằng chương trình đã chỉ định. Nếu execbị bỏ qua, tiến trình shell vẫn còn trong bộ nhớ trong khi chương trình đang thực thi và không cần tiêu tốn tài nguyên hệ thống.

về cơ bản đó là lý do giải thích cho tôi khá lâu (bởi một trong những người khuân vác), và khá nổi tiếng.