Tại sao tốt hơn là sử dụng tên # # / / Usr / bin / env NAME Thay vì Số #! / Path / to / NAME TÊN làm shebang của tôi?

Tôi nhận thấy rằng một số tập lệnh mà tôi có được từ những người khác có shebang #!/path/to/NAMEtrong khi những tập lệnh khác (sử dụng cùng một công cụ, NAME) có shebang #!/usr/bin/env NAME.

Cả hai dường như hoạt động đúng. Trong các hướng dẫn (ví dụ về Python), dường như có một gợi ý rằng shebang sau tốt hơn. Nhưng, tôi không hiểu tại sao lại như vậy.

Tôi nhận ra rằng, để sử dụng shebang sau, NAME phải ở trong PATH trong khi shebang đầu tiên không có hạn chế này.

Ngoài ra, nó xuất hiện (với tôi) rằng đầu tiên sẽ là shebang tốt hơn, vì nó chỉ định chính xác vị trí của NAME. Vì vậy, trong trường hợp này, nếu có nhiều phiên bản NAME (ví dụ: / usr / bin / NAME, / usr / local / bin / NAME), trường hợp đầu tiên chỉ định sử dụng.

Câu hỏi của tôi là tại sao shebang đầu tiên được ưa thích hơn thứ hai?

Nó không nhất thiết phải tốt hơn.

Ưu điểm của #!/usr/bin/env pythonnó là nó sẽ sử dụng bất cứ thứ gì có thể pythonthực hiện được xuất hiện đầu tiên trong người dùng $PATH.

Các nhược điểm của #!/usr/bin/env pythonlà nó sẽ sử dụng bất cứ pythonthực thi xuất hiện đầu tiên trong sử dụng của $PATH.

Điều đó có nghĩa là kịch bản có thể hành xử khác nhau tùy thuộc vào người điều hành nó. Đối với một người dùng, nó có thể sử dụng /usr/bin/pythoncái đã được cài đặt với HĐH. Mặt khác, nó có thể sử dụng một thử nghiệm /home/phred/bin/pythonkhông hoạt động chính xác.

Và nếu pythonchỉ được cài đặt trong /usr/local/bin, một người dùng không có /usr/local/bintrong $PATHthậm chí sẽ không có khả năng chạy các kịch bản. (Điều đó có thể không quá có khả năng trên các hệ thống hiện đại, nhưng nó có thể dễ dàng xảy ra đối với một trình thông dịch khó hiểu hơn.)

Bằng cách chỉ định #!/usr/bin/pythonbạn chỉ định chính xác trình thông dịch nào sẽ được sử dụng để chạy tập lệnh trên một hệ thống cụ thể .

Một vấn đề tiềm năng khác là #!/usr/bin/envmánh khóe không cho phép bạn truyền các đối số cho người thông báo (trừ tên của tập lệnh, được thông qua ngầm). Điều này thường không phải là một vấn đề, nhưng nó có thể. Nhiều tập lệnh Perl được viết cùng #!/usr/bin/perl -w, nhưng use warnings;là sự thay thế được đề xuất trong những ngày này. Tập lệnh Csh nên sử dụng #!/bin/csh -f- nhưng tập lệnh csh không được khuyến nghị ở vị trí đầu tiên. Nhưng có thể có những ví dụ khác.

Tôi có một số tập lệnh Perl trong hệ thống kiểm soát nguồn cá nhân mà tôi cài đặt khi tôi thiết lập tài khoản trên hệ thống mới. Tôi sử dụng một tập lệnh cài đặt để sửa đổi #!dòng của mỗi tập lệnh khi nó cài đặt nó trong tập lệnh của tôi $HOME/bin. (Tôi đã không phải sử dụng bất cứ thứ gì khác ngoài #!/usr/bin/perlthời gian gần đây; nó trở lại thời gian khi Perl thường không được cài đặt theo mặc định.)

Một điểm nhỏ: #!/usr/bin/envlừa được cho là lạm dụng envlệnh, vốn được dự định ban đầu (như tên ngụ ý) để gọi lệnh với môi trường bị thay đổi. Hơn nữa, một số hệ thống cũ hơn (bao gồm cả SunOS 4, nếu tôi nhớ lại chính xác) đã không có envlệnh trong /usr/bin. Cả hai điều này có khả năng là một mối quan tâm đáng kể. envthực hiện theo cách này, rất nhiều tập lệnh sử dụng #!/usr/bin/envmánh khóe và các nhà cung cấp hệ điều hành không có khả năng làm bất cứ điều gì để phá vỡ nó. Nó có thể là một vấn đề nếu bạn muốn tập lệnh của mình chạy trên một hệ thống thực sự cũ, nhưng sau đó bạn có thể cần phải sửa đổi nó.

Một vấn đề khác có thể xảy ra, (cảm ơn Sopalajo de Arrierez vì đã chỉ ra nó trong các bình luận) là các công việc định kỳ chạy với một môi trường hạn chế. Đặc biệt, $PATHthường là một cái gì đó như /usr/bin:/bin. Vì vậy, nếu thư mục chứa trình thông dịch không nằm trong một trong những thư mục đó, ngay cả khi nó nằm trong mặc định của bạn $PATHtrong vỏ người dùng, thì /usr/bin/envthủ thuật sẽ không hoạt động. Bạn có thể chỉ định đường dẫn chính xác hoặc bạn có thể thêm một dòng vào crontab của mình để đặt $PATH( man 5 crontabđể biết chi tiết).

Bởi vì / usr / bin / env có thể diễn giải của bạn $PATH, điều này làm cho các tập lệnh dễ mang theo hơn.

#!/usr/local/bin/python

Sẽ chỉ chạy tập lệnh của bạn nếu python được cài đặt trong / usr / local / bin.

#!/usr/bin/env python

Sẽ diễn giải của bạn $PATH, và tìm python trong bất kỳ thư mục trong của bạn $PATH.

Vì vậy, kịch bản của bạn là di động nhiều hơn, và sẽ làm việc mà không sửa đổi trên hệ thống mà python được cài đặt như là /usr/bin/python, hoặc /usr/local/bin/python, hoặc thậm chí thư mục tùy chỉnh (đã được thêm vào $PATH), giống như /opt/local/bin/python.

Tính di động là lý do duy nhất sử dụng envđược ưu tiên cho các đường dẫn được mã hóa cứng.

Chỉ định đường dẫn tuyệt đối chính xác hơn trên một hệ thống nhất định. Nhược điểm là nó quá chính xác. Giả sử bạn nhận ra rằng cài đặt hệ thống của Perl quá cũ so với tập lệnh của bạn và thay vào đó bạn muốn sử dụng tập lệnh của riêng mình: sau đó bạn phải chỉnh sửa tập lệnh và thay đổi #!/usr/bin/perlthành #!/home/myname/bin/perl. Tồi tệ hơn, nếu bạn có Perl in /usr/bintrên một số máy, /usr/local/bintrên các máy khác và /home/myname/bin/perltrên các máy khác, thì bạn phải duy trì ba bản sao riêng biệt của tập lệnh và thực thi bản sao phù hợp trên mỗi máy.

#!/usr/bin/envphá vỡ nếu PATHlà xấu, nhưng hầu như bất cứ điều gì. Cố gắng vận hành với một cái xấu PATHrất hiếm khi hữu ích và chỉ ra rằng bạn biết rất ít về hệ thống mà tập lệnh đang chạy, vì vậy dù sao bạn cũng không thể dựa vào bất kỳ đường dẫn tuyệt đối nào.

Có hai chương trình mà vị trí bạn có thể dựa vào hầu hết mọi biến thể unix: /bin/shvà /usr/bin/env. Một số biến thể Unix tối nghĩa và hầu hết đã nghỉ hưu /bin/envkhông có /usr/bin/env, nhưng bạn không thể gặp phải chúng. Các hệ thống hiện đại có /usr/bin/envchính xác là do sử dụng rộng rãi trong shebang. /usr/bin/envlà một cái gì đó bạn có thể tin cậy.

Ngoài ra /bin/sh, lần duy nhất bạn nên sử dụng một đường dẫn tuyệt đối trong shebang là khi tập lệnh của bạn không có nghĩa là có thể mang theo được, vì vậy bạn có thể tin tưởng vào một vị trí đã biết cho trình thông dịch. Ví dụ: tập lệnh bash chỉ hoạt động trên Linux có thể sử dụng một cách an toàn #!/bin/bash. Một tập lệnh chỉ được sử dụng trong nhà có thể dựa vào các quy ước vị trí thông dịch viên.

#!/usr/bin/envkhông có nhược điểm. Nó linh hoạt hơn việc chỉ định một đường dẫn tuyệt đối nhưng vẫn yêu cầu biết tên trình thông dịch. Đôi khi, bạn có thể muốn chạy một trình thông dịch không có trong $PATH, ví dụ như ở một vị trí liên quan đến tập lệnh. Trong những trường hợp như vậy, bạn thường có thể tạo một tập lệnh polyglot có thể được diễn giải bằng cả trình bao tiêu chuẩn và trình thông dịch mong muốn của bạn. Ví dụ: để tạo tập lệnh Python 2 di động cả cho các hệ thống có pythonPython 3 và python2Python 2 và các hệ thống có pythonPython 2 và python2không tồn tại:

#!/bin/sh
''':'
if type python2 >/dev/null 2>/dev/null; then
  exec python2 "$0" "$@"
else
  exec python "$0" "$@"
fi
'''
# real Python script starts here
def …

Cụ thể cho perl, sử dụng #!/usr/bin/envlà một ý tưởng tồi vì hai lý do.

Đầu tiên, nó không phải là di động. Trên một số nền tảng tối nghĩa env không có trong / usr / bin. Thứ hai, như Keith Thompson đã lưu ý, nó có thể gây rắc rối với việc chuyển các đối số trên dòng shebang. Giải pháp di động tối đa là thế này:

#!/bin/sh
exec perl -x "$0" "$@"
#!perl

Để biết chi tiết về cách thức hoạt động của nó, hãy xem 'perldoc perlrun' và nội dung của nó nói về đối số -x.

Lý do có một sự khác biệt giữa hai là vì cách các kịch bản được thực thi.

Sử dụng /usr/bin/env(mà, như đã đề cập trong các câu trả lời khác, không có trong /usr/binmột số HĐH) là bắt buộc vì bạn không thể đặt tên thực thi sau #!- nó phải là một đường dẫn tuyệt đối. Điều này là do #!cơ chế hoạt động ở mức thấp hơn vỏ. Đây là một phần của trình tải nhị phân của kernel. Điều này có thể được kiểm tra. Đặt cái này trong một tập tin và đánh dấu nó có thể thực thi được:

#!bash

echo 'foo'

Bạn sẽ thấy nó in một lỗi như thế này khi bạn cố chạy nó:

Failed to execute process './test.sh'. Reason:
The file './test.sh' does not exist or could not be executed.

Nếu một tệp được đánh dấu thực thi và bắt đầu bằng a #!, hạt nhân (không biết về $PATHhoặc thư mục hiện tại: đây là các khái niệm đất người dùng) sẽ tìm tệp bằng đường dẫn tuyệt đối. Bởi vì sử dụng một đường dẫn tuyệt đối là có vấn đề (như đã đề cập trong các câu trả lời khác), một người nào đó đã nghĩ ra một mẹo: Bạn có thể chạy /usr/bin/env(gần như luôn luôn ở vị trí đó) để chạy một cái gì đó bằng cách sử dụng $PATH.

Có hai vấn đề nữa khi sử dụng #!/usr/bin/env

1. Nó không giải quyết vấn đề chỉ định đường dẫn đầy đủ đến trình thông dịch, nó chỉ chuyển nó tới env.

   envkhông được đảm bảo /usr/bin/envnhiều hơn bashlà được đảm bảo ở trong /bin/bashhoặc trăn /usr/bin/python.

2. env ghi đè ARGV [0] bằng tên của trình thông dịch (e..g bash hoặc python).

   Điều này ngăn tên tập lệnh của bạn xuất hiện, ví dụ: psđầu ra (hoặc thay đổi cách thức / nơi nó xuất hiện) và khiến nó không thể tìm thấy nó với, ví dụ:ps -C scriptname.sh

[cập nhật 2016-06-04]

Và một vấn đề thứ ba:

3. Thay đổi PATH của bạn là nhiều công việc hơn là chỉ chỉnh sửa dòng đầu tiên của một kịch bản, đặc biệt là khi kịch bản chỉnh sửa như vậy là tầm thường. ví dụ:

   printf "%s\n" 1 i '#!'$(type -P python2) . w | ed foo.py

   Việc thêm hoặc chờ xử lý trước một thư mục vào $ PATH khá dễ dàng (mặc dù bạn vẫn phải chỉnh sửa một tệp để làm cho nó vĩnh viễn - của bạn ~/.profilehoặc bất cứ điều gì - và rất dễ để kịch bản THAT chỉnh sửa vì PATH có thể được đặt ở bất kỳ đâu trong tập lệnh , không phải trong dòng đầu tiên).

   Thay đổi thứ tự của các thư mục PATH khó khăn hơn đáng kể .... và khó hơn nhiều so với việc chỉ chỉnh sửa #!dòng.

   Và bạn vẫn còn tất cả các vấn đề khác mà việc sử dụng #!/usr/bin/envmang lại cho bạn.

   @jlliagre đề xuất trong một nhận xét #!/usr/bin/envhữu ích cho việc kiểm tra tập lệnh của bạn với nhiều phiên bản trình thông dịch, "bằng cách chỉ thay đổi thứ tự PATH / PATH của chúng"

   Nếu bạn cần làm điều đó, sẽ dễ dàng hơn nhiều khi chỉ có một vài #!dòng ở đầu tập lệnh của bạn (chúng chỉ là nhận xét ở bất cứ đâu trừ dòng đầu tiên) và cắt / sao chép và dán đoạn bạn muốn sử dụng ngay bây giờ dòng đầu tiên.

   Trong viđó, điều đó sẽ đơn giản như di chuyển con trỏ đến #!dòng bạn muốn, sau đó gõ dd1GPhoặc Y1GP. Ngay cả với một trình soạn thảo tầm thường như vậy nano, sẽ mất vài giây để sử dụng chuột để sao chép và dán.

Nhìn chung, những lợi thế của việc sử dụng #!/usr/bin/envlà tối thiểu, và chắc chắn thậm chí không tiến gần đến những nhược điểm. Ngay cả lợi thế "tiện lợi" phần lớn là ảo tưởng.

IMO, đó là một ý tưởng ngớ ngẩn được thúc đẩy bởi một loại lập trình viên cụ thể, người nghĩ rằng hệ điều hành không phải là thứ cần phải làm việc, chúng là một vấn đề cần giải quyết (hoặc bỏ qua tốt nhất).

PS: đây là một tập lệnh đơn giản để thay đổi trình thông dịch của nhiều tệp cùng một lúc.

change-shebang.sh:

#!/bin/bash

interpreter="$1"
shift

if [ -z "$(type -P $interpreter)" ] ; then
  echo "Error: '$interpreter' is not executable." >&2
  exit 1
fi

if [ ! -d "$interpreter" ] && [ -x "$interpreter" ] ; then
  shebang='#!'"$(realpath -e $interpreter)" || exit 1
else
  shebang='#!'"$(type -P $interpreter)"
fi

for f in "$@" ; do
  printf "%s\n" 1 i "$shebang" . w | ed "$f"
done

Chạy nó như, ví dụ, change-shebang.sh python2.7 *.pyhoặcchange-shebang.sh $HOME/bin/my-experimental-ruby *.rb

Thêm một ví dụ khác ở đây:

Sử dụng envcũng hữu ích khi bạn muốn chia sẻ tập lệnh giữa nhiều rvmmôi trường chẳng hạn.

Chạy phần này trên dòng cmd, hiển thị phiên bản ruby ​​nào sẽ được sử dụng khi #!/usr/bin/env rubyđược sử dụng bên trong tập lệnh:

env ruby --version

Do đó, khi bạn sử dụng env, bạn có thể sử dụng các phiên bản ruby ​​khác nhau thông qua rvm, mà không thay đổi tập lệnh của bạn.

Nếu bạn viết hoàn toàn cho bản thân hoặc cho công việc của bạn và vị trí của thông dịch viên bạn gọi luôn ở cùng một nơi, thì bằng mọi cách, hãy sử dụng đường dẫn trực tiếp. Trong tất cả các trường hợp khác sử dụng #!/usr/bin/env.

Đây là lý do: trong tình huống của bạn, trình pythonthông dịch đã ở cùng một vị trí bất kể bạn đã sử dụng cú pháp nào nhưng đối với nhiều người, nó có thể đã được cài đặt ở một nơi khác. Mặc dù hầu hết các trình thông dịch lập trình chính được đặt trong /usr/bin/rất nhiều phần mềm mới hơn được mặc định /usr/local/bin/.

Tôi thậm chí sẽ tranh luận để luôn luôn sử dụng #!/usr/bin/envbởi vì nếu bạn đã cài đặt nhiều phiên bản của cùng một trình thông dịch và bạn không biết trình bao của bạn sẽ mặc định là gì, thì có lẽ bạn nên sửa nó.

Vì lý do tính di động và tương thích, tốt hơn là sử dụng

#!/usr/bin/env bash

thay vì

#!/usr/bin/bash

Có nhiều khả năng, trong đó nhị phân có thể nằm trên hệ thống Linux / Unix. Kiểm tra trang chủ của hier (7) để biết mô tả chi tiết về phân cấp hệ thống tệp.

Ví dụ FreeBSD cài đặt tất cả phần mềm, không phải là một phần của hệ thống cơ sở, trong / usr / local / . Vì bash không phải là một phần của hệ thống cơ sở, nhị phân bash được cài đặt tại / usr / local / bin / bash .

Khi bạn muốn một tập lệnh bash / csh / perl / bất kỳ tập lệnh di động nào chạy trong hầu hết các bản phân phối Linux và FreeBSD, bạn nên sử dụng #! / Usr / bin / env .

Cũng lưu ý rằng hầu hết các bản cài đặt Linux cũng đã (cứng) liên kết nhị phân env với / bin / env hoặc softlinked / usr / bin vào / bin không nên được sử dụng trong shebang. Vì vậy, không sử dụng #! / Bin / env .