View previous topic :: View next topic |
Author |
Message |
Mr. Anderson l33t
Joined: 22 Apr 2004 Posts: 762
|
Posted: Mon Dec 24, 2007 1:57 am Post subject: Gehört ein Schrägstrich ans Ende eines Verzeichnisses? |
|
|
Diese Frage bereitet mir immer wieder Kopfzerbrechen. Aber heute ist es besonders schlimm. Hintergrund: ich will mich um Bug #168668 kümmern. Unterwegs hab ich mehr andere Bugs gefunden als mir lieb ist (wenn auch alle ganz harmlos) - und bei einem hab ich bisher nicht mal einen Bugreport erstellt, weil es zu sehr ausgeartet ist.
Meine Beobachtung ist, dass es i. Allg. in Skripten so läuft:
Man setzt einen Pfad zusammen aus mehreren Teilen, den Strich zwischen den beiden Teilen liefert der zweite Teil.
Zum Beispiel
Code: | A=/usr
B=/lib
C=$A$B |
Wenn man das konsequent durchzieht, sieht das auf den ersten Blick vielleicht nach einer sauberen Sache aus. Aber: was ist mit dem Wurzelknoten, also dem Wurzelverzeichnis /? Das verliert hierbei seinen Anspruch auf einen Schrägstrich und ist nur noch ein leeres Wort, was in der Theorie elegant sein kann, aber nicht praktikabel ist. Eine Lösung könnte sein, dass man am Ende grundsätzlich für jede Datei einen führenden / einfügt - und wenn man das Verzeichnis selbst will, entweder nur einen / oder ein /. <Meta-Punkt>
Zum Beispiel:
Code: | A=/usr
B=/lib
D=/test.txt
E=/
C1=$A$B$D
C2=$A$B$E |
Zum Programmieren ist das aber vllt. auch nicht gerade angenehm. Je länger ich nachdenke, desto mehr gefällt mir diese Lösung aber.
Man könnte auch immer das Wurzelverzeichnis als Spezialfall abfangen: Wenn am Anfang zwei Strich stehen, entfernt man einen... aber gibt es auch keinen Spezialfall, wo man zwei Slashes am Anfang haben will?
Ein anderer Weg wäre zu sagen, dass der Strich an den vorderen Teil gehört. Ein ähnliches Problem zeigt sich aber am jeweils anderen Ende:
Code: | A=usr/
B=lib/
C=/$A$B |
Was denkt ihr darüber? Was wäre richtig? Und gibt es (bei Gentoo) eine Code-Konvention dafür?
edit: noch mal überarbeitet, Beispiele eingefügt usw. |
|
Back to top |
|
|
blu3bird Retired Dev
Joined: 04 Oct 2003 Posts: 614 Location: Munich, Germany
|
Posted: Mon Dec 24, 2007 9:12 am Post subject: |
|
|
Es gibt echt Leute die nen Bugreport aufmachen wenn sie irgendwo LDPATH="//usr//lib/opengl/nvidia/lib" sehen? o_0
Aber ja, ein Slash gehört ans Ende vom Verzeichnisnamen, sonst wäre es ja eine Datei. Also Dein Beispiel müßte heißen:
Code: | A=/usr/
B=/lib/
C=${A}${B} |
Ja, dadurch wird C="/usr//lib/", aber das ist eindeutig kein Bug. _________________ Black Holes are created when God divides by zero! |
|
Back to top |
|
|
think4urs11 Bodhisattva
Joined: 25 Jun 2003 Posts: 6659 Location: above the cloud
|
Posted: Mon Dec 24, 2007 11:58 am Post subject: |
|
|
blu3bird wrote: | Ja, dadurch wird C="/usr//lib/", aber das ist eindeutig kein Bug. |
Es entsteht ein ungültiger Pfad - was ist es denn dann? ein semantic flaw? _________________ Nothing is secure / Security is always a trade-off with usability / Do not assume anything / Trust no-one, nothing / Paranoia is your friend / Think for yourself |
|
Back to top |
|
|
Anarcho Advocate
Joined: 06 Jun 2004 Posts: 2970 Location: Germany
|
Posted: Mon Dec 24, 2007 12:14 pm Post subject: |
|
|
Think4UrS11 wrote: | blu3bird wrote: | Ja, dadurch wird C="/usr//lib/", aber das ist eindeutig kein Bug. |
Es entsteht ein ungültiger Pfad - was ist es denn dann? ein semantic flaw? |
Seit wann ist denn "/usr//lib" ein ungültiger Pfad?
Code: | workstation ~ $ ls -l /usr//lib/
insgesamt 351M
drwxr-xr-x 3 root root 4,0K 1. Sep 20:37 alsa-lib
drwxr-xr-x 2 root root 4,0K 1. Sep 22:54 antlr
drwxr-xr-x 3 root root 4,0K 2. Sep 02:43 ao
drwxr-xr-x 3 root root 4,0K 3. Sep 01:48 aqbanking
drwxr-xr-x 2 root root 4,0K 2. Sep 01:44 aspell-0.60
drwxr-xr-x 5 root root 4,0K 2. Dez 14:00 autopsy
drwxr-xr-x 3 root root 4,0K 15. Dez 12:12 awn
drwxr-xr-x 4 root root 4,0K 25. Sep 11:35 bcc
drwxr-xr-x 4 root root 4,0K 19. Dez 18:57 beagle
[...] |
_________________ ...it's only Rock'n'Roll, but I like it! |
|
Back to top |
|
|
think4urs11 Bodhisattva
Joined: 25 Jun 2003 Posts: 6659 Location: above the cloud
|
Posted: Mon Dec 24, 2007 12:31 pm Post subject: |
|
|
öörgs ... das funktioniert ja sogar
*rausred* aaaber unter $anderes_OS tät das nich gehen... ich setz mich jetzt in den Kühlschrank ins Käsefach _________________ Nothing is secure / Security is always a trade-off with usability / Do not assume anything / Trust no-one, nothing / Paranoia is your friend / Think for yourself |
|
Back to top |
|
|
Wolle Apprentice
Joined: 07 May 2003 Posts: 256 Location: Hamburg (Germany)
|
Posted: Mon Dec 24, 2007 1:14 pm Post subject: |
|
|
Think4UrS11 wrote: | öörgs ... das funktioniert ja sogar
*rausred* aaaber unter $anderes_OS tät das nich gehen... |
Ähm,... bei mir geht das auch unter $anderes_OS
Code: | wolles-power-mac-g4:~ wolle$ ls -l /usr//lib/
total 66552
-rw-r--r-- 1 root wheel 2365 Mar 21 2005 TcldomConfig.sh
-rw-r--r-- 1 root wheel 2344 Mar 21 2005 TclxmlConfig.sh
lrwxr-xr-x 1 root wheel 16 May 19 2007 X11 -> ../X11R6/lib/X11
-rw-r--r-- 1 root wheel 189 Mar 20 2005 charset.alias
-r-xr-xr-x 1 root wheel 1797576 Jul 21 03:45 dyld
drwxr-xr-x 3 root wheel 102 Mar 28 2005 gimp-print
drwxr-xr-x 3 root wheel 102 Mar 21 2005 groff
-rw-r--r-- 1 root wheel 2999 Mar 21 2005 itclConfig.sh
drwxr-xr-x 11 root wheel 374 Dec 3 18:43 java
-rwxr--r-- 1 root wheel 2450 Mar 21 2005 jpegtclConfig.sh
-r-xr-xr-x 1 root wheel 63864 Dec 3 18:26 libBSDPClient.A.dylib
lrwxr-xr-x 1 root wheel 21 May 17 2007 libBSDPClient.dylib -> libBSDPClient.A.dylib
-r-xr-xr-x 1 root wheel 16232 Dec 3 18:26 libDHCPServer.A.dylib
lrwxr-xr-x 1 root wheel 21 May 17 2007 libDHCPServer.dylib -> libDHCPServer.A.dylib
lrwxr-xr-x 1 root wheel 59 May 17 2007 libIOKit.A.dylib -> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
lrwxr-xr-x 1 root wheel 16 May 17 2007 libIOKit.dylib -> libIOKit.A.dylib
... |
_________________ USE="gentoo" emerge linux |
|
Back to top |
|
|
Mr. Anderson l33t
Joined: 22 Apr 2004 Posts: 762
|
Posted: Mon Dec 24, 2007 2:09 pm Post subject: |
|
|
Es ist in meinen Augen allemal schlimmer als irgendein Typo. Es ist hässlich zu lesen, es ist unschön beim Debuggen, es braucht Speicherplatz, verbietet Annahmen über das Aussehen einer Pfadangabe, Endrekursion kann schwieriger werden, system calls dauern länger und in Grenzfällen kann es zu unerwarteten Fehlern führen:
Code: | # res=/; for i in `seq 1 12`; do res=$res$res; done; stat $res
stat: Aufruf von stat für „////[..]////“ nicht möglich: Der Dateiname ist zu lang
# ROOT=$res eselect opengl set xorg-x11
!!! Error: Unrecognized option: xorg-x11
Getötet
# res=/; for i in `seq 1 11`; do res=$res$res; done
# ROOT= eselect opengl set xorg-x11
# if prelink /usr/lib/opengl/xorg-x11/lib/libGL.so.1 2>/dev/null ; then echo success; fi
success
# ROOT=$res eselect opengl set xorg-x11
# if prelink /usr/lib/opengl/xorg-x11/lib/libGL.so.1 2>/dev/null ; then echo success; fi
Abgebrochen
# prelink /usr/lib/opengl/xorg-x11/lib/libGL.so.1 2>&1 | grep libpam
prelink: /lib/libpam.so.0.81.9 is not present in any config file directories, nor was specified on command line
# ROOT= eselect opengl set xorg-x11
Switching to xorg-x11 OpenGL interface... done
# prelink /usr/lib/opengl/xorg-x11/lib/libGL.so.1 2>&1 | grep libpam
#
|
absolute Pfadangaben sollten IMO immer in einer normalisierten minimalen Form vorliegen.
edit: Copy&Paste-Fehler im Code korrigiert. |
|
Back to top |
|
|
Genone Retired Dev
Joined: 14 Mar 2003 Posts: 9527 Location: beyond the rim
|
Posted: Wed Jan 02, 2008 5:48 pm Post subject: |
|
|
Hängt vom persönlichen Stil und dem Anwendungsfall ab, und es gibt da bei Gentoo keine allgemeinverbindliche Konvention von der ich wüsste. Ich persönlich bau lieber ein paar Slashes zuviel ein und normalisiere das Ergebnis bei Bedarf (was selten ist) anstatt mir permanent Gedanken drüber zu machen wo in der Originalzuweisung man einen Slash setzen darf/muss, da es immer irgendwelche Ausnahmen gibt (die */lib* Verzeichnisse sind ein nettes Beispiel). |
|
Back to top |
|
|
Mr. Anderson l33t
Joined: 22 Apr 2004 Posts: 762
|
Posted: Wed Jan 02, 2008 6:10 pm Post subject: |
|
|
Hm. Schade an sich.
Mittlerweile bin ich der Sache etwas gründlicher nachgegangen. In jedem Fall weiß ich nun, dass
nicht äquivalent ist zu
es lassen sich mit . und .. interessante Linux-spezifische Effekte erzeugen:
Code: | ~ $ mkdir -p bla1/bla2
~ $ cd bla1/bla2
~/bla1/bla2 $ rm -v -R ../ ../.
rm: Entfernen von Verzeichnis „../“ nicht möglich
rm: cannot remove „.“ directory „../.“
~/bla1/bla2 $ rmdir .
rmdir: .: Das Argument ist ungültig
~/bla1/bla2 $ rmdir ../bla2/.
rmdir: ../bla2/.: Das Argument ist ungültig
~/bla1/bla2 $ touch bla3
~/bla1/bla2 $ rmdir bla3 bla3/ bla3/.
rmdir: bla3: Ist kein Verzeichnis
rmdir: bla3/: Ist kein Verzeichnis
rmdir: bla3/.: Ist kein Verzeichnis
~/bla1/bla2 $ rm bla3/
rm: Entfernen von „bla3/“ nicht möglich: Ist kein Verzeichnis
~/bla1/bla2 $ rm bla3/.
rm: cannot remove „.“ directory „bla3/.“
~/bla1/bla2 $ rm bla3
~/bla1/bla2 $ rmdir -v ../bla2 ..
rmdir: Verzeichnis wird entfernt, ../bla2
rmdir: Verzeichnis wird entfernt, ..
rmdir: ..: Das Verzeichnis ist nicht leer |
Ich hatte auch schon krassere Widersprüche, die müsste ich aber wieder zusammensuchen. Heute aber nicht mehr. Bin verabredet. |
|
Back to top |
|
|
69719 l33t
Joined: 20 Sep 2004 Posts: 865
|
Posted: Thu Jan 03, 2008 3:26 am Post subject: |
|
|
"." und ".." sind fest eingebaute Links aus dem Filesystem. Diese Links können nicht entfernt werden.
Code: |
touch test.txt
ln -s test.txt test.txt.link
rm test.txt.link
|
Entfernt auch nur den Link und nicht die Datei.
Code: |
find / -inum $(stat . | grep Inode | awk {'print $4'}) -exec rm -rf {} \;
find / -inum $(stat .. | grep Inode | awk {'print $4'}) -exec rm -rf {} \;
find / -inum $(stat ../. | grep Inode | awk {'print $4'}) -exec rm -rf {} \;
|
Würde das Verzeichnis entfernen, da es die Inode-Nummer ermittelt und das Verzeichnis anhand der Inode-Nummer sucht. |
|
Back to top |
|
|
Mr. Anderson l33t
Joined: 22 Apr 2004 Posts: 762
|
Posted: Thu Jan 03, 2008 2:17 pm Post subject: |
|
|
escor wrote: | "." und ".." sind fest eingebaute Links aus dem Filesystem. Diese Links können nicht entfernt werden.
Code: |
touch test.txt
ln -s test.txt test.txt.link
rm test.txt.link
|
Entfernt auch nur den Link und nicht die Datei. |
Das sind aber Softlinks. "." und ".." kommen eher Hardlinks gleich, auch wenn es die für Verzeichnisse eigentlich nicht mehr gibt.
Code: | mkdir bla1
~ $ cd bla1
~/bla1 $ touch test.txt
~/bla1 $ ln -s test.txt test.txt.link
~/bla1 $ ln test.txt test.txt.hardlink
~/bla1 $ stat test.txt* -c"%n: %F, Inode %i"
test.txt: reguläre leere Datei, Inode 3626
test.txt.hardlink: reguläre leere Datei, Inode 3626
test.txt.link: symbolische Verknüpfung, Inode 5785
~/bla1 $ stat . ../bla1 -c"%n: %F, Inode %i"
.: Verzeichnis, Inode 1288
../bla1: Verzeichnis, Inode 1288 |
So betrachtet sind alles nur Links, auch der Verzeichnis-Eintrag bla1 selbst.
Quote: | Code: |
find / -inum $(stat . | grep Inode | awk {'print $4'}) -exec rm -rf {} \;
find / -inum $(stat .. | grep Inode | awk {'print $4'}) -exec rm -rf {} \;
find / -inum $(stat ../. | grep Inode | awk {'print $4'}) -exec rm -rf {} \;
|
Würde das Verzeichnis entfernen, da es die Inode-Nummer ermittelt und das Verzeichnis anhand der Inode-Nummer sucht. |
Hehe, ich habe mal getestet, was gelöscht werden würde, wenn ich das ausführen würde. Da ich eine separate home-Partition habe und den Ausdruck in der Runden Klammer im home-Verzeichnis ausgeführt habe, war / auch bei den Treffern dabei.
Wie dem auch sei: ich verstehe noch nicht ganz, was Du aussagen willst. |
|
Back to top |
|
|
r3tep Tux's lil' helper
Joined: 10 Sep 2005 Posts: 108
|
Posted: Thu Jan 03, 2008 5:02 pm Post subject: |
|
|
bei mir auf der arbeit geht das sogar mit solaris9. und auch die pfadangaben /xyz/abc bzw yxz/abc/ sind irgendwie dasselbe? hm.... |
|
Back to top |
|
|
pablo_supertux Advocate
Joined: 25 Jan 2004 Posts: 2931 Location: Somewhere between reality and Middle-Earth and in Freiburg (Germany)
|
Posted: Thu Jan 03, 2008 7:15 pm Post subject: |
|
|
r3tep wrote: | bei mir auf der arbeit geht das sogar mit solaris9. und auch die pfadangaben /xyz/abc bzw yxz/abc/ sind irgendwie dasselbe? hm.... |
das ist nicht wahr. Ich benutze Solaris 5.9 und 5.10 seit Jahren an der Uni und sowas habe ich noch nie gesehen. Vielleicht hast du ein symlink und hast nicht gemerkt oder du führst etwas aus und / ist im PATH. _________________ A! Elbereth Gilthoniel!
silivren penna míriel
o menel aglar elenath,
Gilthoniel, A! Elbereth! |
|
Back to top |
|
|
Mr. Anderson l33t
Joined: 22 Apr 2004 Posts: 762
|
Posted: Tue Jan 08, 2008 3:34 am Post subject: |
|
|
IEEE 1003.1 sagt:
Quote: | A pathname that contains at least one non-slash character and that ends with one or more trailing slashes shall be resolved as if a single dot character ( '.' ) were appended to the pathname. |
Das heißt, /some/path/ sollte äquivalent sein zu /some/path/.
außerdem:
Quote: | The special filename dot shall refer to the directory specified by its predecessor. The special filename dot-dot shall refer to the parent directory of its predecessor directory. As a special case, in the root directory, dot-dot may refer to the root directory itself. |
aber:
Quote: | The meaning of deleting pathname /dot is unclear, because the name of the file (directory) in the parent directory to be removed is not clear, particularly in the presence of multiple links to a directory. |
wenn also /some/path/ äquivalent ist zu /some/path/. - dann ist die Bedeutung beide Male unklar. Folglich wäre man nur auf der sicheren Seite, wenn man an dieser Stelle den Slash am Ende weglässt. Auch der restliche POSIX-Standard liest sich so, dass ans Ende eines Verzeichnisnamens kein Slash gehört. Ausnahme ist das Wurzelverzeichnis /
Oft taucht dieser Satz auf:
Quote: | If there are any trailing slash characters in string, they shall be removed. |
Wenn doch ein Slash am Ende dastehen sollte, soll das Verzeichnis so interpretiert werden, also stünde noch ein Punkt dahinter.
Normal steht immer nur ein einzelner Slash. Am Anfang kann // stehen, was aber je nach System unterschiedliche Bedeutung haben kann. |
|
Back to top |
|
|
|