'test' mit keiner, einer oder mehreren Dateien
Mahlzeit *, ich hoffe, ich habe mit dem Betreff bei niemandem den Filter klingeln lassen... Zuerst ganz knapp die Frage: Kann ich mit test (oder von mir aus auch mit [[ ]]) prüfen, ob in einem Verzeichnis irgendeine Datei liegt? Bei test -e * gibt's (verständlicherweise) nen Fehler, wenn mehr als eine Datei da ist. :( ----------------------------------------- Und jetzt nochmal ausführlich: Ich habe zwei Windows-Rechner, auf denen ein Virenscanner installiert ist, der leider nicht von Haus aus automatisch aktualisierbar ist. Freundlicherweise schickt der Hersteller aber immer eine Mail, wenn es updates gibt. Diese Mails gehen an einen Linux-Rechner, werden per procmail bearbeitet, das update-File per wget vom Server geholt und in einem Verzeichnis auf der Linuxkiste abgelegt. Funktioniert. Teil Zwei: Die updates müssen auf die Windows-Rechner. Also möchte ich täglich ein Skript laufen lassen, dass die Dateien per smbclient an die richtigen Stellen kopiert und dann löscht. Und an der Stelle, an der ich überprüfen will, ob überhaupt updates vorliegen (test) setzt es aus, wenn mehr als zwei Dateien im Verzeichnis liegen. Ich hab es auch schon mit find probiert, aber mit if-thens im exec stehe ich wohl komplett auf Kriegsfuß :( Ich hoffe, mir kann geholfen werden. Martin Borchert -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
Hallo, On Mon, 01 Apr 2002 at 19:19 (+0100), Martin Borchert wrote:
Zuerst ganz knapp die Frage: Kann ich mit test (oder von mir aus auch mit [[ ]])
Wenn, dann mit [ ] und nicht mit [[ ]].
prüfen, ob in einem Verzeichnis irgendeine Datei liegt? Bei test -e * gibt's (verständlicherweise) nen Fehler, wenn mehr als eine Datei da ist. :(
Warum nicht folgendes (ungetestet): ===================================== #!/bin/sh if [ `ls | wc -l` -gt 0 ] ; then # wenn nicht leer else # wenn leer fi ===================================== Gruß, Bernhard -- "Unix is the most user friendly system I know, the point is the it is really selective about who is indeed its friend." -- Luigi Genoni
* Bernhard Walle wrote @ 01. Apr 2002 20:36:
On Mon, 01 Apr 2002 at 19:19 (+0100), Martin Borchert wrote:
prüfen, ob in einem Verzeichnis irgendeine Datei liegt? Bei test -e * gibt's (verständlicherweise) nen Fehler, wenn mehr als eine Datei da ist. :(
Warum nicht folgendes (ungetestet):
===================================== #!/bin/sh
if [ `ls | wc -l` -gt 0 ] ; then # wenn nicht leer else # wenn leer fi =====================================
Oder auch ---8<--- DIRNAME=/testdir ( rmdir $DIRNAME 2>&1 > /dev/null ) > /dev/null if test $? -eq 0 ; then # Leer else # Nicht Leer fi --->8--- man rmdir Thomas
Hallo, On Mon, 01 Apr 2002, Thomas Hart wrote:
( rmdir $DIRNAME 2>&1 > /dev/null ) > /dev/null if test $? -eq 0 ; then # Leer else # Nicht Leer fi
if rmdir $DIRNAME >/dev/null 2>&1 then [..]
man rmdir
man bash! -dnh -- 158: Geisterfahrer Gegenrichtungsfahrbahnbenutzer (Burkhardt Schröder)
Am Montag, 1. April 2002 20:36:20 schrieb Bernhard Walle:
On Mon, 01 Apr 2002 at 19:19 (+0100), Martin Borchert wrote:
Zuerst ganz knapp die Frage: Kann ich mit test (oder von mir aus auch mit [[ ]]) Wenn, dann mit [ ] und nicht mit [[ ]].
Ähm... Worin besteht der Unterschied? Mein man bash schlug mir als erstes [[ expression ]] vor.
prüfen, ob in einem Verzeichnis irgendeine Datei liegt? Bei test -e * gibt's (verständlicherweise) nen Fehler, wenn mehr als eine Datei da ist. :( Warum nicht folgendes (ungetestet): ===================================== #!/bin/sh
if [ `ls | wc -l` -gt 0 ] ; then # wenn nicht leer else # wenn leer fi =====================================
Ich habs auch noch nicht getestet, aber scheint Sinn zu machen. Danke. Martin Borchert -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
* Martin Borchert schrieb am 01.Apr.2002:
Zuerst ganz knapp die Frage: Kann ich mit test (oder von mir aus auch mit [[ ]]) prüfen, ob in einem Verzeichnis irgendeine Datei liegt? Bei test -e * gibt's (verständlicherweise) nen Fehler, wenn mehr als eine Datei da ist. :(
test `ls -a | wc -l` -gt 2 Die Verzeichnisse . und .. liegen in jedem Verzeichniß, daher gegen 2 prüfen. Wenn ls in einer pipe schreibt, dann gibt es immer pro Datei eine Zeile aus. (Wenn nicht außdrücklich -C angegeben wird) Bernd -- Hast Du bei Problemen schon in der SuSE-Support-Datenbank (SDB) nachgesehen? Auf Deinem Rechner: http://localhost/doc/sdb/de/html/index.html | mit Apache: http://localhost/doc/sdb/de/html/key_form.html | Zufalls- Tagesaktuell bei SuSE: http://sdb.suse.de/sdb/de/html/index.html | signatur 2
On Mon, 01 Apr 2002 at 22:22 (+0200), Bernd Brodesser wrote:
* Martin Borchert schrieb am 01.Apr.2002:
Zuerst ganz knapp die Frage: Kann ich mit test (oder von mir aus auch mit [[ ]]) prüfen, ob in einem Verzeichnis irgendeine Datei liegt? Bei test -e * gibt's (verständlicherweise) nen Fehler, wenn mehr als eine Datei da ist. :(
test `ls -a | wc -l` -gt 2
Die Verzeichnisse . und .. liegen in jedem Verzeichnis, daher gegen 2 prüfen. Wenn ls in einer pipe schreibt, dann gibt es immer pro Datei eine Zeile aus. (Wenn nicht außdrücklich -C angegeben wird)
Anscheinend ist die Voreinstellung aber so, dass diese zwei "Dateien" nicht mit angezeigt werden. Ich habe es jetzt extra nochmal geprüft: berwal@hugo:~ > mkdir test berwal@hugo:~ > cd test berwal@hugo:~/test > ls berwal@hugo:~/test > type ls ls is aliased to `ls $LS_OPTIONS' berwal@hugo:~/test > echo $LS_OPTIONS -N --color=tty -T 0 ============== aus ls(1) ============================== -a, --all do not hide entries starting with . -A, --almost-all do not list implied . and .. ======================================================== Deine Variante ist schon richtig, aber wozu so kompliziert? Wenn man ganz auf Nummer sicher gehen will, dann empfinde _ich_ [ `ls -A | wc -l` -gt 0 ] als schöner. Und ja, die Test-Schreibweise gefällt _mir_ nicht, das ist aber dann wirklich reine Geschmackssache ;-) Gruß, Bernhard -- Homepage: http://www.bwalle.de
* Bernhard Walle schrieb am 02.Apr.2002:
On Mon, 01 Apr 2002 at 22:22 (+0200), Bernd Brodesser wrote:
* Martin Borchert schrieb am 01.Apr.2002:
Zuerst ganz knapp die Frage: Kann ich mit test (oder von mir aus auch mit [[ ]]) prüfen, ob in einem Verzeichnis irgendeine Datei liegt? Bei test -e * gibt's (verständlicherweise) nen Fehler, wenn mehr als eine Datei da ist. :(
test `ls -a | wc -l` -gt 2
Die Verzeichnisse . und .. liegen in jedem Verzeichnis, daher gegen 2 prüfen. Wenn ls in einer pipe schreibt, dann gibt es immer pro Datei eine Zeile aus. (Wenn nicht außdrücklich -C angegeben wird)
Anscheinend ist die Voreinstellung aber so, dass diese zwei "Dateien" nicht mit angezeigt werden. Ich habe es jetzt extra nochmal geprüft:
berwal@hugo:~ > mkdir test berwal@hugo:~ > cd test berwal@hugo:~/test > ls
Da steht auch ls -a Einfach nur ls gibt keine Dateien aus, die mit . anfangen. Es könnte sehr wohl eine Datei .datei im Verzeichniß sein, die würde mit einem einfachen ls auch nicht mitangezeigt, und das Vezeichniß als vermeindlich leer angesehen, obwohl es das nicht ist.
berwal@hugo:~/test > type ls ls is aliased to `ls $LS_OPTIONS' berwal@hugo:~/test > echo $LS_OPTIONS -N --color=tty -T 0
Das wird aber in einem Skript nicht verwendet. Der alias wird im /etc/profile gesetzt, und das wird nur von interaktive shells gelesen. Ein Skript bekommt von dem alias nichts mit.
============== aus ls(1) ============================== -a, --all do not hide entries starting with .
-A, --almost-all do not list implied . and .. ========================================================
Deine Variante ist schon richtig, aber wozu so kompliziert? Wenn man ganz auf Nummer sicher gehen will, dann empfinde _ich_
[ `ls -A | wc -l` -gt 0 ]
als schöner. Und ja, die Test-Schreibweise gefällt _mir_ nicht, das ist aber dann wirklich reine Geschmackssache ;-)
Ich habe -a gewählt, weil es das immer gibt. -A ist hingegen eine Besonderheit des GNU ls. [ ... ] sieht so aus, als gehörte es zur Syntax der bash, und verwirrt mehr, als das es hilft. In Wirklichkeit ist es ein Synonym zu test und daher ein eigener Befehl. Es wird grundsätzlich auf dem Rückgabewert geprüft. So ist es z.B auch Sinnvoll if grep irgendwas Datei then #falls irgendwas irgendwo in Datei steht else #falls nicht fi zu schreiben. Da braucht man kein test und auch kein [ ... ] Bernd -- LILO funktioniert nicht? Hast Du /etc/lilo.conf verändert und vergessen, lilo aufzurufen? Ist Deine /boot-Partition unter der 1024 Zylindergrenze? Bei anderen LILO Problemen mal in der SDB nachschauen: http://localhost/doc/sdb/de/html/rb_bootdisk.html |Zufallssignatur 6
Hallo, On Tue, 02 Apr 2002 at 11:56 (+0200), Bernd Brodesser wrote:
* Bernhard Walle schrieb am 02.Apr.2002:
On Mon, 01 Apr 2002 at 22:22 (+0200), Bernd Brodesser wrote:
* Martin Borchert schrieb am 01.Apr.2002:
Zuerst ganz knapp die Frage: Kann ich mit test (oder von mir aus auch mit [[ ]]) prüfen, ob in einem Verzeichnis irgendeine Datei liegt? Bei test -e * gibt's (verständlicherweise) nen Fehler, wenn mehr als eine Datei da ist. :(
test `ls -a | wc -l` -gt 2
Die Verzeichnisse . und .. liegen in jedem Verzeichnis, daher gegen 2 prüfen. Wenn ls in einer pipe schreibt, dann gibt es immer pro Datei eine Zeile aus. (Wenn nicht außdrücklich -C angegeben wird)
Anscheinend ist die Voreinstellung aber so, dass diese zwei "Dateien" nicht mit angezeigt werden. Ich habe es jetzt extra nochmal geprüft:
berwal@hugo:~ > mkdir test berwal@hugo:~ > cd test berwal@hugo:~/test > ls
Da steht auch ls -a Einfach nur ls gibt keine Dateien aus, die mit . anfangen. Es könnte sehr wohl eine Datei .datei im Verzeichnis sein, die würde mit einem einfachen ls auch nicht mitangezeigt, und das Vezeichnis als vermeindlich leer angesehen, obwohl es das nicht ist.
Stimmt.
berwal@hugo:~/test > type ls ls is aliased to `ls $LS_OPTIONS' berwal@hugo:~/test > echo $LS_OPTIONS -N --color=tty -T 0
Das wird aber in einem Skript nicht verwendet. Der alias wird im /etc/profile gesetzt, und das wird nur von interaktive shells gelesen. Ein Skript bekommt von dem alias nichts mit.
Ist in dem Fall sowieso egal. Eine Ausnahme wäre es, wenn man das Skript nicht ausführt sondern sourced.
============== aus ls(1) ============================== -a, --all do not hide entries starting with .
-A, --almost-all do not list implied . and .. ========================================================
Deine Variante ist schon richtig, aber wozu so kompliziert? Wenn man ganz auf Nummer sicher gehen will, dann empfinde _ich_
[ `ls -A | wc -l` -gt 0 ]
als schöner. Und ja, die Test-Schreibweise gefällt _mir_ nicht, das ist aber dann wirklich reine Geschmackssache ;-)
Ich habe -a gewählt, weil es das immer gibt. -A ist hingegen eine Besonderheit des GNU ls.
Das wusste ich nicht. *grummel* Warum können die GNU-Leute ihre Erweiterungen nicht irgendwo hinschreiben.
[ ... ] sieht so aus, als gehörte es zur Syntax der bash, und verwirrt mehr, als das es hilft. In Wirklichkeit ist es ein Synonym zu test und daher ein eigener Befehl.
Befehl ja, aber beide sind bash-builtin und somit ist test auch kein eigenes Programm wie etwa grep.
Es wird grundsätzlich auf dem Rückgabewert geprüft. So ist es z.B auch Sinnvoll
if grep irgendwas Datei then #falls irgendwas irgendwo in Datei steht else #falls nicht fi
zu schreiben. Da braucht man kein test und auch kein [ ... ]
Stimmt. Trotzdem gefällt mir [ ... ] besser. Ich sagte ja, reine Geschmackssache. Gruß, Bernhard -- "Der wahrscheinlich ärgerlichste Aspekt eines Com- puterprogrammes ist die Art und Weise, in der es auf Ihre Fehler reagiert" -- L. Lamport, LaTeX-Handbuch
* Bernhard Walle schrieb am 02.Apr.2002:
On Tue, 02 Apr 2002 at 11:56 (+0200), Bernd Brodesser wrote:
* Bernhard Walle schrieb am 02.Apr.2002:
Deine Variante ist schon richtig, aber wozu so kompliziert? Wenn man ganz auf Nummer sicher gehen will, dann empfinde _ich_
[ `ls -A | wc -l` -gt 0 ]
als schöner. Und ja, die Test-Schreibweise gefällt _mir_ nicht, das ist aber dann wirklich reine Geschmackssache ;-)
Ich habe -a gewählt, weil es das immer gibt. -A ist hingegen eine Besonderheit des GNU ls.
Das wusste ich nicht. *grummel* Warum können die GNU-Leute ihre Erweiterungen nicht irgendwo hinschreiben.
Hmm, letztendlich bin ich mir auch nicht Sicher, ob es das nicht auch bei irgend einem UNIX gibt. Sicherlich nicht bei allen. UNIX ist leider nicht einheitlich, baut nur auf einer einheitlichen Basis auf, die ist allerdings recht dünn. Wenn es sich aber so einfach realisieren läßt, dann würde ich schon diese einheitliche Basis nehmen. Bernd -- Probleme mit dem Drucker? Schon die Druckercheckliste beachtet? http://localhost/doc/sdb/de/html/drucker-howto.html | Auch lesenswert: Oder schon das Drucker-HOWTO gelesen? | man lpr file://usr/shar/doc/howto/de/DE-Drucker-HOWTO.txt.gz | Zufallssignatur 3
Hallo, On Tue, 02 Apr 2002 at 17:21 (+0200), Bernd Brodesser wrote:
[ls -A und ls -a bei verschiedenen Unix-Systemen]
Sicherlich nicht bei allen. UNIX ist leider nicht einheitlich, baut nur auf einer einheitlichen Basis auf, die ist allerdings recht dünn. Wenn es sich aber so einfach realisieren läßt, dann würde ich schon diese einheitliche Basis nehmen.
Hm, jetzt interessiert es mich dann doch mal genauer, nehmen wir uns einige Unices vor, zum Glück finden sich Manpages & Co. meist auf den Internetseiten der Hersteller. Ich habe die in den Bookmarks: * Solaris 8: http://docs.sun.com/ab2/coll.40.6/REFMAN1/@Ab2PageView/181269?Ab2Lang=de&Ab2Enc=utf-8 Hm, auf der einen Seite steht oben SYNOPSIS /usr/bin/ls [-aAbcCdfFgilLmnopqrRstux1] [file]... auf der anderen Seite wird aber das -A nicht erklärt. Ich behaupte jetzt einfach mal, dass es -A gibt und es so funktioniert wie unter Linux ... * HP-UX 11i: http://docs.hp.com/cgi-bin/onlinedocs.py?mpn=B2355-90689&service=hpux&path=../B2355-90689/00/01/186&title=HP-UX%20Reference%20%28Volume%201%20of%209%29 Oben steht SYNOPSIS ls [-abcdefgilmnopqrstuxACFLR1] [names] Also scheint es kein -A zu geben. * NetBSD current: http://www.tac.eu.org/cgi-bin/man-cgi?ls+1+NetBSD-current SYNOPSIS ls [-ACFLRSTWacdfgiklmnoqrstux1] [file ...] [...] -A List all entries except for `.' and `..'. Always set for the super-user. Zumindest hier herrscht Klarheit: Wie unter Linux. * FreeBSD 5.0: Identisch zu NetBSD. Das soll erstmal reichen. In beiden Punkten hast Du recht: Es gibt einige Unices, die -A kennen; alle kennen sie -a. 100 Punkte! Gruß, Bernhard -- The feature you'd like to have is probably already installed on your Linux system.
Hallo, * Am 02.04.2002 zauberte Bernhard Walle: [...]
Oben steht
SYNOPSIS ls [-abcdefgilmnopqrstuxACFLR1] [names] ^
Also scheint es kein -A zu geben.
Doch, ich habs Dir markiert.
Das soll erstmal reichen. In beiden Punkten hast Du recht: Es gibt einige Unices, die -A kennen; alle kennen sie -a. 100 Punkte!
Na ja. Eines hast Du ja nur übersehen. Mußt wohl noch ein bißchen suchen, bis Du zu einem Beweis kommst ;) -- Gruß Alex -- Du nix leben! Du tot! Du stinkendes Zombie! Gehen In Fruiedhof! Machen grosse Loch und legen rein. dann kippen benzin auf zu verbrennen dich. Dann grosse Loch zugeschüttet werden muss. [WoKo zu /_U_S_E_N_E_T_-_R_U_L_E_Z_/) in daf, an, dag° und sd]
Hi, On Die, 02 Apr 2002, Bernhard Walle sent incredible lines: [...]
* Solaris 8: [...] * HP-UX 11i: [...] * NetBSD current: [...] * FreeBSD 5.0: [...]
... und das geilste Unix vergisst du wieder *grins*: * AIX ls Command Purpose Displays the contents of a directory. Syntax To Display Contents of Directory or Name of File ls [ -1 ] [ -A ] [ -C ] [ -F ] [ -L ] [ -N ] [ -R ] [ -a ] [ -b ] [ -c ] [ -d ] [ -e ] [ -f ] [ -g ] [ -i ] [ -l ] [-m ] [ -n ] [ -o ] [ -p ] [ -q ] [ -r ] [ -s ] [ -t ] [ -u ] [ -x ] [ File ... ] To Display Contents of Directory ls -f [ -C ] [ -d ] [ -i ] [ -m ] [ -s ] [ -x ] [ -1 ] [ Directory ... ] Description da ist -A dabei. ... may the Tux be with you! =Thomas= -- Thomas Bendler \\:// ml@bendler-net.de Billwiese 22 (o -) http://www.bendler-net.de/ 21033 Hamburg ---ooO-(_)-Ooo--- tel.: 0 177 - 277 37 61 Germany Linux, enjoy the ride ...!
Thomas Bendler schrieb am 03.04.2002 um 09:24:23 +0200: Hallo Thomas,
On Die, 02 Apr 2002, Bernhard Walle sent incredible lines: [...]
* Solaris 8: [...] * HP-UX 11i: [...] * NetBSD current: [...] * FreeBSD 5.0: [...]
... und das geilste Unix vergisst du wieder *grins*:
häh? :-)
* AIX [...]
IRIX NAME ls - list contents of directory SYNOPSIS ls [-RadLCxmlnogrtucpFbqisf1AMSDP] [names] Bis denne, Michael -- ---------------------------------------------------------- Michael Schulz, Institut f. Geophysik, Universität Münster Corrensstr. 24, 48149 Münster Tel.: 0251-8333938, e-mail: michael@earth.uni-muenster.de
Hallo, On Tue, 02 Apr 2002, Bernhard Walle wrote: [ls und test]
Befehl ja, aber beide sind bash-builtin und somit ist test auch kein eigenes Programm wie etwa grep.
Jein. test ist _AUCH_ ein builtin, ls (zumindest hier) nicht. $ type -a [ test ls [ is a shell builtin test is a shell builtin test is /usr/bin/test ls is aliased to `ls $LS_OPTIONS' ls is /bin/ls $ bash --version GNU bash, version 2.03.0(1)-release (i386-suse-linux) Es kann uebrigens sein, dass SuSE irgendwo im Pfad einen symlink '[' auf /usr/bin/test angelegt hat... -dnh --
Ich kann doch nichts dafür wenn alle meine Postings siggen wollen. Ich Poste den Blödsinn doch nur. [Woko° in dafb]
Hallo, On Fri, 05 Apr 2002 at 00:00 (+0200), David Haller wrote:
On Tue, 02 Apr 2002, Bernhard Walle wrote: [ls und test]
Befehl ja, aber beide sind bash-builtin und somit ist test auch kein eigenes Programm wie etwa grep.
Jein. test ist _AUCH_ ein builtin, ls (zumindest hier) nicht. [...]
Es kann uebrigens sein, dass SuSE irgendwo im Pfad einen symlink '[' auf /usr/bin/test angelegt hat...
Richtig. Und damit ist sowohl test als auch [ _auch_ ein Builtin. Wo ist also der Unterschied? Dass [ nur ein symbolischer Link ist und test eine Binärdatei? Gruß, Bernhard -- Allradantrieb Allradantrieb bedeutet, dass man dort stecken bleibt, wo der Abschleppwagen nicht hinkommt.
Hallo, On Fri, 05 Apr 2002, Bernhard Walle wrote:
On Fri, 05 Apr 2002 at 00:00 (+0200), David Haller wrote:
On Tue, 02 Apr 2002, Bernhard Walle wrote: [ls und test]
Befehl ja, aber beide sind bash-builtin und somit ist test auch kein eigenes Programm wie etwa grep.
Jein. test ist _AUCH_ ein builtin, ls (zumindest hier) nicht. [...]
Es kann uebrigens sein, dass SuSE irgendwo im Pfad einen symlink '[' auf /usr/bin/test angelegt hat...
Richtig. Und damit ist sowohl test als auch [ _auch_ ein Builtin. Wo ist also der Unterschied? Dass [ nur ein symbolischer Link ist und test eine Binärdatei?
Der Unterschied ist primaer die Ausfuehrungsgeschwindigkeit: beim builtin muss kein neuer Prozess gestartet werden. Andererseits funktioniert /usr/bin/test mit jeder shell (z.B. csh, zsh, ksh, perlsh...), ein [ nur, wenn auch der symlink gelegt ist (was bei mir z.B. nicht der Fall ist). Ausserdem finde _ich_ 'if test ....' lesbarer/weniger irritierend als ein 'if [ ... ]'. Ich vermute uebrigens, das das auch ein Grund ist, warum hier so gerne so ueberfluessige Konstrukte wie: Befehl if [ $? = 0 ] gemailt werden, wo ja ein einfaches 'if Befehl' reichen wuerde... Ich vermute, dass so mancher if [ .. ] faelschlicherweise fuer zur Syntax von if .. then .. fi zugehoerig haelt... -dnh -- »Microsoft Outlook Express - Designed to enable Virus replication.« see http://www.microsoft.com/mac/products/office/2001/virus_alert.asp -- Sig stolen from Juergen P. Meier
Hallo, On Fri, 05 Apr 2002 at 09:32 (+0200), David Haller wrote:
On Fri, 05 Apr 2002, Bernhard Walle wrote:
On Fri, 05 Apr 2002 at 00:00 (+0200), David Haller wrote:
On Tue, 02 Apr 2002, Bernhard Walle wrote: [ls und test]
Befehl ja, aber beide sind bash-builtin und somit ist test auch kein eigenes Programm wie etwa grep.
Jein. test ist _AUCH_ ein builtin, ls (zumindest hier) nicht. [...]
Es kann uebrigens sein, dass SuSE irgendwo im Pfad einen symlink '[' auf /usr/bin/test angelegt hat...
Richtig. Und damit ist sowohl test als auch [ _auch_ ein Builtin. Wo ist also der Unterschied? Dass [ nur ein symbolischer Link ist und test eine Binärdatei?
Der Unterschied ist primaer die Ausfuehrungsgeschwindigkeit: beim builtin muss kein neuer Prozess gestartet werden.
Schon klar. Das war ja nicht die Frage, ich wollte nur anmerken, dass es sich sowohl bei [ als auch bei test um beides -- ein Builtin und ein externes Programm -- handelt.
Andererseits funktioniert /usr/bin/test mit jeder shell (z.B. csh, zsh, ksh, perlsh...), ein [ nur, wenn auch der symlink gelegt ist (was bei mir z.B. nicht der Fall ist).
Sind das bei Dir noch die Originalpakete?
Ausserdem finde _ich_ 'if test ....' lesbarer/weniger irritierend als ein 'if [ ... ]'. Ich vermute uebrigens, das das auch ein Grund ist, warum hier so gerne so ueberfluessige Konstrukte wie:
Befehl if [ $? = 0 ]
Kann gut sein. Man ist es halt gewohnt, in anderen Programmiersprachen nach dem if ein Paar (runder) Klammern zu setzen, also macht man es auch in der Shellprorammierung. Andererseits finde ich if [ $? = 0 ] ; then lesbarer als if test $? = 0 ; then , eben u. a. aus dem o. g. Grund. Andererseits ... Naja, man kann es ewig diskutieren und wird nie zu einem Ende kommen. Zugegeben, ich habe damit angefangen *duck*. Gruß, Bernhard -- "Don't do tomorrow what you can do today." -- Anne-Marie Mahfouf
Hallo, On Fri, 05 Apr 2002, Bernhard Walle wrote:
On Fri, 05 Apr 2002 at 09:32 (+0200), David Haller wrote:
On Fri, 05 Apr 2002, Bernhard Walle wrote:
Richtig. Und damit ist sowohl test als auch [ _auch_ ein Builtin. Wo ist also der Unterschied? Dass [ nur ein symbolischer Link ist und test eine Binärdatei?
Der Unterschied ist primaer die Ausfuehrungsgeschwindigkeit: beim builtin muss kein neuer Prozess gestartet werden.
Schon klar. Das war ja nicht die Frage, ich wollte nur anmerken, dass es sich sowohl bei [ als auch bei test um beides -- ein Builtin und ein externes Programm -- handelt.
Achso, klar, [ und test als builtin sind das gleiche, bei test und [ als externes Programm ist eins halt ein binary ist, das andere ein (sym)link.
Andererseits funktioniert /usr/bin/test mit jeder shell (z.B. csh, zsh, ksh, perlsh...), ein [ nur, wenn auch der symlink gelegt ist (was bei mir z.B. nicht der Fall ist).
Sind das bei Dir noch die Originalpakete?
Aeh, ja (sh_utils-1.16), ich weiss aber grad nicht mehr wo ich das mit dem symlink [ gesehen habe...
Ausserdem finde _ich_ 'if test ....' lesbarer/weniger irritierend als ein 'if [ ... ]'. Ich vermute uebrigens, das das auch ein Grund ist, warum hier so gerne so ueberfluessige Konstrukte wie:
Befehl if [ $? = 0 ]
Kann gut sein. Man ist es halt gewohnt, in anderen Programmiersprachen nach dem if ein Paar (runder) Klammern zu setzen, also macht man es auch in der Shellprorammierung. Andererseits finde ich
if [ $? = 0 ] ; then
lesbarer als
if test $? = 0 ; then ,
Klar, letzteres ist ja auch in praktisch allen Faellen ueberfluessig. Wenn man den exitstatus eines befehls mehrfach braucht, dann sollte man sowieso eine (benannte) Variable verwenden. Ansonsten ja eben if Befehl; then und nicht den Test $? -eq 0 (oder "$?" = "0") (siehe 'help test', '=' ist ein string und keine arithmetischer Vergleich).
eben u. a. aus dem o. g. Grund. Andererseits ... Naja, man kann es ewig diskutieren und wird nie zu einem Ende kommen. Zugegeben, ich habe damit angefangen *duck*.
Hehe: noch was ganz anderes: In vielen Faellen kann man ja auch: Befehl && nochn_Befehl || Fehlermeldung verwenden, statt if Befehl; then nochn_Befehl; else Fehlermeldung; fi *g* -dnh -- Flhacs wird im Usenet grundsätzlich alsfhc geschrieben. Schreibt man lafhsc nicht slfach, so ist das schlichtweg hclafs. (Hajo Pflueger in de.newuser.questions)
* Bernhard Walle schrieb am 05.Apr.2002:
Kann gut sein. Man ist es halt gewohnt, in anderen Programmiersprachen nach dem if ein Paar (runder) Klammern zu setzen, also macht man es auch in der Shellprorammierung. Andererseits finde ich
if [ $? = 0 ] ; then
lesbarer als
if test $? = 0 ; then ,
eben u. a. aus dem o. g. Grund. Andererseits ... Naja, man kann es ewig diskutieren und wird nie zu einem Ende kommen. Zugegeben, ich habe damit angefangen *duck*.
Ja. Und ich finde if test $? = 0 then ... lesbarer, wobei test $? = 0 überflüssig ist, besser da steht gleich der Befehl, der vorher ausgeführt worden ist nach if. Bernd -- LILO funktioniert nicht? Hast Du /etc/lilo.conf verändert und vergessen, lilo aufzurufen? Ist Deine /boot-Partition unter der 1024 Zylindergrenze? Bei anderen LILO Problemen mal in der SDB nachschauen: http://localhost/doc/sdb/de/html/rb_bootdisk.html |Zufallssignatur 6
participants (9)
-
Alex Klein -
B.Brodesser＠t-online.de -
Bernhard Walle -
David Haller -
Martin Borchert -
Michael Schulz -
Ratti -
Thomas Bendler -
Thomas Hart