Sinn und Unsinn von env

darktrym

Fahnenträger
Ich las gerade einen Artikel und konnte nur den Kopf schütteln, wie wenig Substanz und Wissen da mal wieder ins Netz gepustet wurde und das ausgerechnet von einem ehemaligen NetBSD Entwickler und nun FreeBSD Committer. Kurzum, env ein Unixprogramm, welches die Aufgabe hat den passenden Interpreterpfad zurückzugeben, statt absolute Pfade zu verwenden, sollte hier kritisch beleuchtet werden.

Es geht traurigerweise schon damit los, das ein Shebang nie ein Leerzeichen zwischen Ausrufezeichen und Pfad haben sollte/muss. Das wird konsequent wiederholt wobei eine Quelle extra darauf noch hinweist, dass das Quatsch ist.
Dann wird argumentiert, es werde im Path gesucht und schließlich wird irgendeine Version genommen. Genaugenommen ist die Wahl deterministisch, also vorhersehbar. Und genau das ist doch der Sinn des Ganzen. Mehrere Installationen auf der Platte zu haben, wovon der Skriptentwickler nichts wissen sollte und der Endandwender entscheidet stets selbst, was richtig ist.
Fälschlicherweise wird dann mit der Pkgsrc Praxis begründet, das ohne nix gefunden wird weil Python 2.7 eben im Pfad ist aber kein Python. Dazu muss man wissen, dass in Python zwar einige Sprachfeature zurückportiert werden aber einige Bibliotheken eben nicht, selbst innerhalb der Major-Version kommt es da zu Inkompatibilitäten. Daher die Nummerierung hinter dem Interpreter. Von VirtualEnv hat der Schreiber offensichtlich auch nix gehört, wenn er Libs und Installationen vermengt?
Wie schaut nun die Lösung aus?
Genau dafür hat Gott uns alias geschenkt und eine Shell geschaffen um die richtige Versionen selbst anzugeben.
Das vorgeschobene Problem 2 und 3 sind inkompatibel löst man denn mit einem Starter oder baut sein Code komplett als Hybrid auf.
Will der Programmierer es dann doch deutlich machen nur eine Version unterstützen zu wollen, gibts entweder die Möglichkeit eines Abbruch mit Meldung oder der Shebang bekommt ein Suffix. Ein Symlink oder Alias und schon ist die Welt wieder heile.
Wieder einer dieser Artikel zum aufregen, gut dass der Herr nun für Google arbeitet.Google ist ja auch dafür bekannt, wie man schlechten Python Code und krude Skripte schreibt(Android Make).
 
Nur dass env nichts damit zu tun hat, irgendwelche Pfade zurückzugeben. Wie der Name schon sagt, ist es dazu da, das Environment zu beeinflussen. Dass man damit cleverweise pfadunabhängige #! kriegt, ist ein netter Nebeneffekt.

Code:
NAME
  env - set and print environment
 
Das Enviroment(env) beinhaltet ja den Path, das gleiche Konzept gibts auch für Windows. Gerade wir müssten das ja lieben, kein ständiges Gepatche ob nun /usr/local/bin, /usr/bin, oder /usr/pkg/bin.
 
Das Argument scheint ja zu sein, dass #!/usr/bin/env nicht alle Probleme löst. Das stimmt natürlich es löst genau ein Problem (wo ist das Binary mit Namen x).

Finde ich gut, ein Problem weniger.

Die Person in dem verlinkten Artikel findet es anscheinend nicht gut ein Problem zu lösen, wenn man damit nicht *alle* Probleme löst. Jedenfalls habe ich keine Argumente gefunden die aufdecken wie die Situation ohne #!/usr/bin/env besser wäre.
 
Die Person in dem verlinkten Artikel findet es anscheinend nicht gut ein Problem zu lösen, wenn man damit nicht *alle* Probleme löst. Jedenfalls habe ich keine Argumente gefunden die aufdecken wie die Situation ohne #!/usr/bin/env besser wäre.

Das schreibt er doch: Man soll ein configure Skript dazu packen, was m.M.n. aber wieder vollkommener Overkill ist.
Allerdings ist das Ganze auch eine große Grütze.
Ich habe mit FreeBSD, Linux und Solaris zu tun und da ist alles anders.
  • FreeBSD: Mehr oder weniger POSIX-konforme /bin/sh, Bash, Perl und Python wenn überhaupt in /usr/local/bin, da dann möglicherweise als python[23][0-9]
  • Linux: Ebenfalls oft POSIX-konforme /bin/sh, zusätzlich in fast alles Fällen /bin/bash, alles andere meistens in /usr/bin, kann aber auch in /usr/local/bin sein
  • Solaris: Eine total verhunzte /bin/sh, die sich an keine Standards hält, in /usr/xpg4/bin eine POSIX shell, /bin/bash sollte da sein, dann noch GNU Programme in /usr/sfw/bin, nachinstallierte Software kann in /opt/csw (opencsw.org), /usr/local (unixpackages.com), /usr/pkg (pkgsrc) liegen.

Also eigentlich wäre das Configure Skript doch gar nicht so unsinnig fällt mir gerade auf. ;-)
 

Also eigentlich wäre das Configure Skript doch gar nicht so unsinnig fällt mir gerade auf. ;-)
Das sollte IMHO kein Configure Script machen sondern das Install Script. Und zwar mit expliziten Flags, damit das alles genau so passiert wie der Paket-Maintainer sich das gedacht hat.
 
Und unter Android noch mal überall /system davorhängen und bei Fedora, vermutlich, beten, dass es irgendwie passt. :D
 
Zurück
Oben