siehe Subjekt, FreeBSD kennt realpath, OpenBSD nicht, dafür kennen beide
readlink, welches mir aber nur das Ziel ohne Pfad zurück gibt, "stat -L" tut
nicht, wie in der Hilfe ver[sprochen|standen].
Wie finde ich Dialekt-übergreifend ("mit der /bin/sh") das Ziel eines Links
mitsamt Pfad? Ich möchte "find" damit füttern:
for _LIB in `ldd -f "%p\n" ${_BIN} 2>/dev/null`; do
if [ -h ${_LIB} ]; then
_LIB=`$gesuchtes_tool ${_LIB}
fi
find ${_LIB} | cpio -dp ${OPT_DEST}
done
Danke und Gruß, Helmut
--
No Swen today, my love has gone away
My mailbox stands for lorn, a symbol of the dawn
> Hi,
>
> siehe Subjekt, FreeBSD kennt realpath, OpenBSD nicht, dafür kennen beide
> readlink, welches mir aber nur das Ziel ohne Pfad zurück gibt, "stat -L"
> tut nicht, wie in der Hilfe ver[sprochen|standen].
>
> Wie finde ich Dialekt-übergreifend ("mit der /bin/sh") das Ziel eines
> Links mitsamt Pfad? Ich möchte "find" damit füttern:
>
> for _LIB in `ldd -f "%p\n" ${_BIN} 2>/dev/null`; do
> if [ -h ${_LIB} ]; then
> _LIB=`$gesuchtes_tool ${_LIB}
> fi
> find ${_LIB} | cpio -dp ${OPT_DEST}
> done
>
> Danke und Gruß, Helmut
>
Ich habe dafür mal eine Funktion geschrieben, die unter bash und ksh
läuft; vielleicht kannst Du sie für sh anpassen:
http://www.sudrala.de/de_d/shell-getlink.html
Gruß,
Bernd
--
Bernd Eggink
http://sudrala.e
> siehe Subjekt, FreeBSD kennt realpath, OpenBSD nicht, dafür kennen beide
> readlink, welches mir aber nur das Ziel ohne Pfad zurück gibt, "stat -L" tut
> nicht, wie in der Hilfe ver[sprochen|standen].
readlink -f (zumindest unter Ubuntu)
# resolve symlink of this script and get
# ZT home directory (basename, dirname)
zt_path=$(readlink -f $0)
zt_dir=$(dirname $zt_path)
zt_scr=$(basename $zt_path)
Hier habe ich ein Startscript unter /home/bernd was einen Symlink auf
sich selber nach /etc/init.d/ erstellt. Beim Booten lese ich damit
heraus dass das Script in /home/bernd steht.
Bernd
--
Well, there's egg and bacon; egg sausage and bacon; egg and
nos...@spamonly.de ; egg bacon and spam; egg bacon sausage
and kuc...@spamonly.net ; spam bacon sausage and spam;spam
egg spam spam bacon and nos...@nixwill.de ; spam sausage
Ich bin erstaunt, ich dachte, ich "blamiere" mich, das Thema ist zu gähnen,
aber offensichtlich... :)
Ich hab jetzt mal ne OS-Weiche programmiert.
> Ich habe dafür mal eine Funktion geschrieben, die unter bash und ksh
> läuft; vielleicht kannst Du sie für sh anpassen:
>
> http://www.sudrala.de/de_d/shell-getlink.html
Es wird "shopt -s dotglob" gesetzt, obwohl keine
pathname expansion verwendet wird?
Es wird [[ ]] verwendet, aber die Variablen dennoch mit "" geschützt.
Wenn "" zum Schutz ausreicht: ohne [[ läuft es in allen POSIX Shells.
Für den BUGS Abschnitt [1]:
- Symlinknamen, die selbst " -> " enthalten, werden nicht korrekt
ausgewertet. (Es wäre möglich, da das Format von ls robust und
das von POSIX ls sogar standardisiert ist.)
- Symlinks, die auf Directories zeigen, werden nicht zuverlässig
ausgewertet. Es zählt dabei auch, ob der Symlinkname mit /
abgeschlossen wurde.
[1] und zwar im traditionellen Sinne einer Manpage:
Ein Mängel, der mglw. nach Abwägung nicht gefixt wird,
aber dann zumindest bekannt sein sollte.
> (Es wäre möglich, da das Format von ls robust und
> das von POSIX ls sogar standardisiert ist.)
Aber das wird doch nicht mal benötigt.
Es reicht ja völlig aus, daß ls alle
gültigen Zeichen buchstäblich ausgibt.
> Bernd Eggink wrote:
>
>> Ich habe dafür mal eine Funktion geschrieben, die unter bash und ksh
>> läuft; vielleicht kannst Du sie für sh anpassen:
>>
>> http://www.sudrala.de/de_d/shell-getlink.html
>
> Es wird "shopt -s dotglob" gesetzt, obwohl keine
> pathname expansion verwendet wird?
Ups - ein historisches Relikt, das hier nicht hingehört, zumal
die Option bei ksh gar nicht existiert.
> Es wird [[ ]] verwendet, aber die Variablen dennoch mit "" geschützt.
Ja, ist nicht konsequent, aber schadet auch nicht. Hab's
den Puristen zuliebe geändert.
> Wenn "" zum Schutz ausreicht: ohne [[ läuft es in allen POSIX Shells.
>
> Für den BUGS Abschnitt [1]:
>
> - Symlinknamen, die selbst " -> " enthalten, werden nicht korrekt
> ausgewertet. (Es wäre möglich, da das Format von ls robust und
> das von POSIX ls sogar standardisiert ist.)
Stimmt. Scheint mir aber nicht der Mühe wert zu sein, da solche Namen
in der freien Wildbahn wohl kaum vorkommen.
> - Symlinks, die auf Directories zeigen, werden nicht zuverlässig
> ausgewertet. Es zählt dabei auch, ob der Symlinkname mit /
> abgeschlossen wurde.
Stimmt. Ist repariert. Danke für die Hinweise!