![](https://seccdn.libravatar.org/avatar/8576ac1b72af7a8d7391dbaa48c37e65.jpg?s=120&d=mm&r=g)
David Haller wrote:
Hallo,
On Sam, 03 Feb 2001, Jan Trippler wrote:
On Sam, Feb 03, 2001 at 10:07:18 +0100, Ralf Corsepius wrote:
David Haller wrote: [bash only scripts] Argl, ich hasse nicht portable Bash-Scripte am Samstagmorgen, die mit Bourneshell-Skripten nur noch am Rande zu tun haben. :)
Besser als verkorkste DOS-Batches/WSH-Scripts an einem verregneten Montagmorgen, oder?
Jep.
Ich schreib ja auch immer schoen brav '#!/bin/bash' in die erste Zeile. In einem heterogenen Netzwerk kann man sich nicht darauf verlassen, dass die Bash überhaupt vorhanden ist, und wenn ja, wo sie liegt. Auf Nicht GNU-basierten Systemen wird sie in der Regel dort nicht zu finden sein, wenn überhaupt, dann unter /usr/bin, /usr/local/bin, /opt/bin oder ganz wo anders :)
David, immer wieder begeistert vom der bash :) Man merkt's :)
*g*
Im Gegensatz zum ersten, sehr sauberen Lösungsvorschlag, sind deine Vorschläge hochgradig unportabel, da sie auf bash-proprietären Features basieren.
Ist denn die Bash selbst nicht portabel? (scnr)
Weitgehend, aber * Es gibt tatsächlich Systeme, da lässt sie sich nicht übersetzen. * Sie ist schlichtweg zu gross/langsam (Beispiel: Unter Cygwin kommt deshalb die ash als /bin/sh zum Einsatz) * Sie war in der Vergangenheit als nicht übermässig stabil und sicher bekannt (und wird deshalb von vielen Sysadmins nicht systemweit installiert).
s/proprietären/spezifischen/ Die csh und zsh und was weiss ich fuer welche Shells habe sicher aehnliche Features. Ja, klar. Es spricht auch nichts dagegen, diese Features local, für den persönlichen Gebrauch oder für ein bestimmtes System auszunutzen. Nur sollte man sich im klaren sein, das die bash unter fast allen Linux-Systemen als /bin/sh verwendet wird, es sich bei /bin/sh im Allgemeinen aber nicht um die bash handelt.
Das ist immer wieder der Grund, warum ich statt $() die `` benutze. Aber wenn man nicht auf Portabilität angewiesen ist, dann ist Davids Lösung natürlich genauso anwendbar (und schneller, da keine externen Kommandos, sondern nur bash-Interna genutzt werden). Man darf sich nur nicht wundern, wenn's auf einem anderen System nicht mehr klappt.
Ack! Ich versuche grad das portablen, aber nervig langsamen 'mktexpk' (und darin verwendete) sh-Scripte in (wohl unportable aber deutlich schnellere) bash-Scripte umzuscheiben... Der Aufwand rentiert sich meiner Meinung nach nicht, da der Zeitaufwand für die unterlagerten Tools den Zeitaufwand der Shell um mehrere Großenordnungen übersteigt.
Anstatt auf die Bash zu setzen würde ich dann gleich eine richtige Scriptsprache verwenden (z.B. perl, python o.ä.). Die sind auf keinen Fall überall installiert, und wenn doch, dann deutlich portabler und ähnlich schnell wie Bash-Skripte.
Gar nicht so einfach, das [1].
Tja, schau dir mal die autoconf Quellen und die autoconf Doku im Detail an. Sie stecken voller Tricks und Hinweise auf portable Shellprogrammierung :)
Es zeigt sich also wieder mal: 1. Es gibt immer mehrere Lösungswege 2. Persönlicher Geschmack spielt eine große Rolle 3. Die vorzuziehende Lösung richtet sich immer nach den Schwerpunkten, die man setzt (Portabilität vs. Performance z. B.) 4. Ich finde es immer wieder schick, wenn für ein Problem mehrere Lösungswege eintrudeln, das hält den Blick offen ;-) Weitgehendes ACK.
Der aus meiner Sicht entscheidende Punkt steckt in 3. versteckt: Es kommt darauf an, welche Anwendung man zum Ziel hat. Es gibt Anwendungen da sind bash Scripte OK (z.B. Linux-Bootscripte, oder zum persönlichen Gebrauch unter Linux), in anderen Fällen nicht (configure, generel anwendbare Skripte). Wenn es um Portablität geht, gibt es bessere Mittel als die Bash, IMHO. Ralf