#!/usr/bin/env bash ← 🤔

正統派なら
#!/bin/bash
#!/usr/bin/python3
など決め打ちだろ
バージョン違いで挙動が異なるなら尚更決め打ち

bashやpython3の場所が異なる可能性を挙げていて
envは変わる確率が低いという無茶苦茶謎理論
https://news.mynavi.jp/techplus/article/techp3085/
インストール先に合わせて
#!/usr/local/bin/pytho3
とか書き換えろよ
それもできないようなのがスクリプト走らすとか恐怖だよ

変な絵文字入れるの流行ってんのか？

POSIX UNIX and Linux script best practice guideが参考になるぞ

その書き換えを不要にするのがenvであり、
/usr/bin/env bashとか/usr/bin/env python3といったshbangで
期待されている動作をするよう
OSは構築されていることが求められている

env はなぜ
/usr/bin/env で決め打ちできるわけ？
システムに複数のpython3がある場合にどの python3で動くか決定的ではなく
ユーザー設定によるので当てにならない

例えば
/usr/bin/python3
/usr/local/bin/python3
/home/userA/bin/python3
とある場合
env で呼ばれる python3 は$PATHによって異なる

ユーザーがactivateしたvenvと同じ環境で走らせたいスクリプトもあれば固定環境で走らせたいスクリプトもあるだろ
使い分けろ

>>4
/usr/bin/envは決め打ちしているものではなく、
利用者は/usr/bin/envがある環境を用意する責任がある、という指針の結果だよ

Pythonの件も、利用者にはenvの評価結果で適切なpython3が選ばれるような
環境を用意する責任がある

そういう責任共有モデル

#!/usr/bin/python3
を自分の好みにあわせて
#!/home/userA/bin/python3
などと書換える方が安全だと思う
こっちは全部自分の意志で行うから

#!/usr/bin/env python3
は不適切でも動いちゃう

>>8
利用者がPythonを好みで選べる環境を作ったのなら、
#!/usr/bin/env python3 なスクリプトが
好みのPythonで起動できる状態にするのは利用者の責任となるのではないかな

昨今のEPPやクラウドの監視が動いてる環境だと、shebangだけとはいえスクリプトを改変すると、
レポジトリに登録されているものから改変されている等と警告が上がるかと

そういう面倒な検知を防ぎつつ、本当のスクリプトの改変を検知できるようにするためにも、
shebangでは/usr/bin/envを使いましょうね、と

上で出ていた
POSIX UNIX and Linux script best practice guide
なり
このもとの理論ってどこにあるの？
誰が提唱しているの？

複数のpython3 っておまえ面倒くせえことしてるなw

venvやコンテナ使ってれば複数あるのは当たり前でしょ

この環境は/bin/shがdashなのでshebangはこう変える、
あのスクリプトはあのバージョンのPythonを使いたいのでこうする、というのって
過去の名残というよりも、それが腐ってできたバッドノウハウだと思うんよね

それ言ったら#!自体がなー
ファイルの拡張属性でやるのが正解とは思う。FAT系のことは忘れろ

全部同じ環境にするのは無理です終わり

なので、スクリプトはenvを使う、利用者はそれ前提で環境を作る、というのが落としどころなのだろう

これLinuxが普及してスクリプトを動かす人が
#! の意味も分からない書換えもできないまま動かしているからだよね
Windowsのマルウェアと同じで危険な兆候なんじゃないの？
最低限の知識も持たず使う人たちの存在

シバン書き換えたら改ざん検知されたでござる

まあもうそういう時代なのだから、envを利用する、に舵を切ってもよいのでは

Linuxに閉じた話とするにしてもbash、dash、zshが入り乱れているのだしさ

もう誰も興味無いんだわOSの仕組みなんか

やっぱりみんなユーザランドよりカーネルのほうが興味あるんだね

https://docs.python.org/ja/3.13/tutorial/appendix.html
Pythonチュートリアル 16.1.2. 実行可能な Python スクリプト
#!/usr/bin/env python3

https://docs.python.org/ja/3.13/using/unix.html
Python のセットアップと利用 2.4. その他
いくつかの Unix は env コマンドを持たないので、
インタープリターのパスを /usr/bin/python3 のように
ハードコードしなければならない

https://perldoc.perl.org/perlintro
put this as the first line of your script:
#!/usr/bin/env perl

You can also put directly the path to your perl executable, like in
#!/usr/bin/perl

https://www.gnu.org/software/bash/manual/bash.html
Bash Reference Manual

Bash scripts often begin with
#! /bin/bash

if it’s been installed in another directory:
#!/usr/bin/env bash

>>2
クソジジイって言われてそう

>>24
職場で仕事の邪魔してそう

ln -s で固定します

>>7
いいモデル、そして慣習とは思うが
（今普及しているの実装の）envはあまりに色々多機能過ぎて第三者の再実装がとても難しい…

man見てみたら宇宙猫になるよ！！

#! /usr/bin/env interpreter
でPATHから予測可能な順序で正しいinterpreter選んでくれる、それだけで十分なのに
環境変数からみ、複数引数対応の為の難解なエスケープ規則etc etc、肥大化しすぎ

どこか…posix？でもlsb？でもいいから、利害団体で必要最小限の機能を定めて公布してほしいよ…

「お前らもう何もするな」って言いたくなることがITには多すぎる

man envは闇だなあ
まさにお前らもう余計な事すんな

お陰でPOSIX等にも入りようがない仕様だし、envのある保証も規格の統一も望めない

env作者は死んで詫びろ

unix哲学に真っ向から敵対するのがenv
#! /usr/bin/env someprog
というシンプル使い方だけなら良いんだけどね
無駄な機能多すぎィ！

必要な機能ではなくあってはならない機能を定義すべき

シバンって日本語っぽくてダサい

機動刑事