Thread CPAN -e shell auf shared Hosting einrichten (29 answers)
Opened by bianca at 2020-02-04 22:07

haj
 2020-02-10 01:48
#191355 #191355
User since
2015-01-07
272 articles
BenutzerIn

user image
Ja, das steht da. Meine Kritik bezieht sich nicht nur auf den Punkt "Aktivieren für die aktuelle Shell", sondern auf die gesamte Dokumentation zum vierten Punkt. Den braucht man nämlich nicht wirklich. Das ganze Thema gehört nicht mehr zum Bootstrapping, sondern ist ein eigenes Thema "wie mache ich die Änderungen persistent". Für Win32 (weiter unten) ist das auch so beschrieben. Denn wenn man einfach nur das Rezept runterkocht, weil man für ein bestimmtes Projekt local::lib haben will, dann fängt man sich eine Änderung für jede Shell ein, es wirkt aber nicht für beispielsweise cronjobs oder Webserver. Es steht auch da (aber auch an einer anderen Stelle), dass man es unter bestimmten Bedingungen doch besser ins .bash_profile reinschreibt. Auch die Auswahl der Shells ist etwas zufällig, zumindest die zsh ist bei Perlern recht beliebt.

So schön das mit den Einzeilern ist: So eine .bashrc lebt Jahre, ich ziehe die manchmal auf neue Systeme mit um. Und in der steht dann eine Zeile ohne Zeitstempel und ohne Kommentar. Jeder andere Eintrag in meiner .bashrc (Debian) kommt mit Erläuterungen, nur local::lib klatscht einfach eine Zeile unten dran, die dann so aussieht, als gehöre sie zum vorhergehenden Block.

Der Hinweis, einfach die .bashrc nochmal einzulesen, kommt auch ohne die Warnung vor Nebenwirkungen. Der setzt nämlich alle in der Datei definierten shell-Optionen wieder auf Start zurück und nicht nur die von local::lib. Und bei Tools, die ihre Pfade einfach vor PATH (oder PERL5LIB) hängen, werden die bei jedem Durchlauf wieder davorgehängt. Das macht local::lib übrigens selbst auch so. Viel besser wäre es, nur das zu local::lib gehörige eval-Kommando nochmal abzusetzen.

View full thread CPAN -e shell auf shared Hosting einrichten