kleine Scriptfrage

[Joachim H.]

Hi,

wie kann ich in einem kleinen Shellscript kurz und knapp feststellen, ob
ein bestimmter Ordner gemounted ist?

Die Info krieg ich ja z.B. über mount | grep Ordner

oder

cat /proc/mounts | grep Ordner.

Doch wie frage ich ab, ob die Ausgabe leer (ungemounted) oder gefüllt
(gemounted) ist?

Danke

Joachim

[Jan Ritzerfeld]

Post by Joachim H.
wie kann ich in einem kleinen Shellscript kurz und knapp feststellen, ob
ein bestimmter Ordner gemounted ist?
(...).

# mountpoint -q Ordner && echo "Ordner gemountet"
# mountpoint -q Ordner || echo "Ordner nicht gemountet"

Gruß
Jan

[mararm]

Post by Joachim H.
cat /proc/mounts | grep Ordner.
Doch wie frage ich ab, ob die Ausgabe leer (ungemounted) oder gefüllt
(gemounted) ist?

man grep sagt:
EXIT STATUS
The exit status is 0 if selected lines are found, and 1 if not found.
If an error occurred the exit status is 2. (Note: POSIX errorhandling
code should check for '2' or greater.)

grep teilt dir also über seinen Rückgabewert mit, ob es etwas gefunden hat
oder nicht.

Das kannst du ausnutzen, in dem du entweder die Aktion direkt an den grep-
Aufruf anhängst

cat /proc/mounts | grep Ordner && echo "eingebunden"
cat /proc/mounts | grep Ordner || echo "nicht eingebunden"

(geht auch gleichzeitig:
cat /proc/mounts | grep Ordner && echo "eingebunden" || echo "nicht
eingebunden"

oder den Rückgabewert abfragst und später verarbeitest

cat /proc/mounts | grep Ordner
gefunden=$?
if [ $gefunden ]; then ...

Gruß
mararm

[Carsten Neumann]

Post by mararm

Post by Joachim H.
cat /proc/mounts | grep Ordner.
Doch wie frage ich ab, ob die Ausgabe leer (ungemounted) oder gefÃŒllt
(gemounted) ist?

EXIT STATUS
The exit status is 0 if selected lines are found, and 1 if not found.
If an error occurred the exit status is 2. (Note: POSIX errorhandling
code should check for '2' or greater.)
grep teilt dir also ÃŒber seinen RÃŒckgabewert mit, ob es etwas gefunden hat
oder nicht.
Das kannst du ausnutzen, in dem du entweder die Aktion direkt an den grep-
Aufruf anhÀngst
cat /proc/mounts | grep Ordner && echo "eingebunden"
cat /proc/mounts | grep Ordner || echo "nicht eingebunden"
cat /proc/mounts | grep Ordner && echo "eingebunden" || echo "nicht
eingebunden"
oder den RÌckgabewert abfragst und spÀter verarbeitest
cat /proc/mounts | grep Ordner
gefunden=$?
if [ $gefunden ]; then ...

Ähmm ... nicht ganz.
Besser:

if [ $gefunden = 0 ]; then ...

:-)

Post by mararm
Gruß
mararm

G, C*

[s***@vimutik.de]

Hallo Carsten,

Post by mararm

Post by Joachim H.
cat /proc/mounts | grep Ordner.
Doch wie frage ich ab, ob die Ausgabe leer (ungemounted) oder
gefüllt (gemounted) ist?

EXIT STATUS
The exit status is 0 if selected lines are found, and 1 if
not found. If an error occurred the exit status is 2. (Note: POSIX
errorhandling code should check for '2' or greater.)
grep teilt dir also über seinen Rückgabewert mit, ob es etwas
gefunden hat oder nicht.
Das kannst du ausnutzen, in dem du entweder die Aktion direkt an den
grep- Aufruf anhängst
cat /proc/mounts | grep Ordner && echo "eingebunden"
cat /proc/mounts | grep Ordner || echo "nicht eingebunden"
cat /proc/mounts | grep Ordner && echo "eingebunden" || echo "nicht
eingebunden"
oder den Rückgabewert abfragst und später verarbeitest
cat /proc/mounts | grep Ordner
gefunden=$?
if [ $gefunden ]; then ...

Ähmm ... nicht ganz.
if [ $gefunden = 0 ]; then ...
:-)

Warum nicht:

gefunden=$(cat /proc/mounts | grep -c Ordner)

Mit freundlichen Grüßen

si

[Bernd Obermayr]

Post by s***@vimutik.de
gefunden=$(cat /proc/mounts | grep -c Ordner)
Mit freundlichen Grüßen
si

Weil Du damit von David den
"useless use of cat" award kriegst ;)

# gefunden=$( grep -c Ordner /proc/mounts )

reicht schon.

[Susan Ivanova]

Hallo Bernd,

Post by Bernd Obermayr

Post by s***@vimutik.de
gefunden=$(cat /proc/mounts | grep -c Ordner)
Mit freundlichen Grüßen
si

Weil Du damit von David den
"useless use of cat" award kriegst ;)
# gefunden=$( grep -c Ordner /proc/mounts )
reicht schon.

Stimmt. Ich fürchte sogar, ich habe da sogar noch einen im Schrank;-)


Mit freundlichen Grüßen

si

[David Haller]

Hallo,

Post by Susan Ivanova

Post by Bernd Obermayr
Weil Du damit von David den
"useless use of cat" award kriegst ;)
# gefunden=$( grep -c Ordner /proc/mounts )
reicht schon.

Stimmt. Ich fürchte sogar, ich habe da sogar noch einen im Schrank;-)

Dann solltest du die (jetzt) beiden mal ein bissl besser sichtbar
aufstellen, damit du öfter dran denkst ;)

Äh, keine Angst: im xterm[1] verwende ich auch sehr oft erstmal ein
'cat bla | foo ... | bar ...'

Vor Mails hier oder in Scripts z.B. wird das aber noch "korrigiert".

Ansonsten empfehle ich "Redirection" bzw. "Process Substitution".

Nur mal angenommen, awk würde keinen Dateinamen als Argument
verarbeiten:

</etc/passwd awk -F: '$7 ~ /sh/ { print; }'
(oder awk -F: '$7 ~ /sh/ { print; }' </etc/passwd)

und

getent passwd | awk -F: '$7 ~ /sh/ { print; }'
(oder awk -F: '$7 ~ /sh/ { print; }' <(getent passwd) )

Statt 'awk' sollte man sich hier jetzt mal z.B. ne längere
while-Schleife vorstellen. Dann wird's interessant für die Lesbarkeit,
zumindest die Eingabeumleitung nach vorne zu ziehen.

Gilt alles für die bash. zsh sollte sowas auch können, evtl. anders.

-dnh

[1] meine GUI: diverse xterms, gkrellm, xclock, ein paar XEmacs
Fenster, und meist noch ein seamonkey.

[Susan Ivanova]

Hallo David,

Post by David Haller
Hallo,

Post by Susan Ivanova

Post by Bernd Obermayr
Weil Du damit von David den
"useless use of cat" award kriegst ;)
# gefunden=$( grep -c Ordner /proc/mounts )
reicht schon.

Stimmt. Ich fürchte sogar, ich habe da sogar noch einen im Schrank;-)

Dann solltest du die (jetzt) beiden mal ein bissl besser sichtbar
aufstellen, damit du öfter dran denkst ;)

Ich werde sie polieren und auf meinem Schreibtisch gut sichtbar
deponieren. Dann werden sie mich vielleicht daran erinnern, abzuwarten,
bis der Meister gesprochen hat!

Mit freundlichen Grüßen

si

[David Haller]

Hallo,

Post by s***@vimutik.de
gefunden=$(cat /proc/mounts | grep -c Ordner)

UUOC!

if grep -q ' /Ordner ' /proc/mounts/; then
: ...
else
: ...
fi

Und verdammt nochmal: '[' ist der Befehl 'test'!
Dokumentiert als bash-builtin in 'help test', als binary in 'man
test'! Macht mal ein 'ls -l /usr/bin/['!

Das 'if [ ... ]' ist nur eine Spezialität von test, das es als letztes
Argument ein ']' verlangt, wenn es als '[' aufgerufen wird (ebenso das
builtin). Das ist _NICHT_ Shellsyntax wie [[ ... ]] oder (( ... ))
oder $[ .. ] oder $( .. ) oder oder.

Die Syntax von if ist:

if COMMANDS; then COMMANDS; [ .. ]... [ else COMMANDS; ] fi

COMMANDS ist dabei ein Liste von Befehlen, zu denen u.a. builtins wie
test oder [[ .. ]], oder eben externe Befehle (wie grep) gehören
können.

Ich empfehle daher seit Jahren jedem immer "test" zu verwenden, und
nicht die ' [ .. ] ' Version. Denn die verlangt übrigens zwingend
Leerraum um die [ und ] rum! Das ist noch ne zusätzliche Falle...
Kurzum: statt ' [ ... ] ' immer 'test ...' verwenden und es wird viel
klarer was man macht ...

Statt: if [ ... ]; then
^ ^ ^ - alles _PFLICHT_ Spaces!

immer: if test ...; then

Das ist gerade mal 1 Zeichen mehr zu tippen! Und macht einem jedesmal
auch klar, daß man 'if CMDS ; then' verwendet und nicht irgendeine
Shell-Syntax.

HTH & HAND,
-dnh

[Аl Воgnеr]

Post by David Haller
Hallo,

Post by s***@vimutik.de
gefunden=$(cat /proc/mounts | grep -c Ordner)

UUOC!

Ob das jede/r versteht? LOL, so ganz verzichte ich auf diesen Preis
direkt in der Shell auch nicht, weil es manchmal leichter zum Löschen
in der Konsole ist.

Post by David Haller
if grep -q ' /Ordner ' /proc/mounts/; then
: ...
else
: ...
fi

So habe ich das auch in Verwendung, aber gebe gerne zu, dass die
Empfehlung dazu von David kam ;-)

Post by David Haller
Ich empfehle daher seit Jahren jedem immer "test" zu verwenden, und
nicht die ' [ .. ] ' Version.

Grundsätzlich oder nur in diesem Fall?

Wenn ich nach einer leeren Variablen teste, verwende ich test -z, sonst
aber dieses if ...

[David Haller]

Hallo,

Post by Аl Воgnеr

Post by David Haller

Post by s***@vimutik.de
gefunden=$(cat /proc/mounts | grep -c Ordner)

UUOC!

Ob das jede/r versteht?

"Useless Use Of Cat" ... Die Suchmaschine (und/oder direkt Wikipedia
hilft ;)
http://de.wikipedia.org/wiki/Cat_(Unix)#Unn.C3.B6tige_Verwendung.2C_Useless_Use

Post by Аl Воgnеr
LOL, so ganz verzichte ich auf diesen Preis direkt in der Shell auch
nicht, weil es manchmal leichter zum Löschen in der Konsole ist.

Jep. Nur in Mails sollte man's dann nicht so reinschreiben.

Post by Аl Воgnеr

Post by David Haller
if grep -q ' /Ordner ' /proc/mounts/; then
: ...
else
: ...
fi

So habe ich das auch in Verwendung, aber gebe gerne zu, dass die
Empfehlung dazu von David kam ;-)

:)

Post by Аl Воgnеr

Post by David Haller
Ich empfehle daher seit Jahren jedem immer "test" zu verwenden, und
nicht die ' [ .. ] ' Version.

Grundsätzlich oder nur in diesem Fall?

Grundsätzlich! Immer! In jedem Fall!

Post by Аl Воgnеr
Wenn ich nach einer leeren Variablen teste, verwende ich test -z, sonst
aber dieses if ...

'if [ .. ]; then' oder 'if test ..; then'?

Letzteres ist absolut ok ...

'foo && bar || baz' hat eben die Logikprobleme falls "bar" auch false
liefern kann...

-dnh

[Аl Воgnеr]

Post by David Haller
Hallo,

Post by Аl Воgnеr

Post by s***@vimutik.de
gefunden=$(cat /proc/mounts | grep -c Ordner)

UUOC!

Ob das jede/r versteht?

"Useless Use Of Cat" ... Die Suchmaschine (und/oder direkt Wikipedia
hilft ;)
http://de.wikipedia.org/wiki/Cat_(Unix)#Unn.C3.B6tige_Verwendung.2C_Useless_Use

War _mir_ schon klar ;-)

[Carsten Neumann]

Post by Аl Воgnеr

Post by David Haller
Hallo,

Post by s***@vimutik.de
gefunden=$(cat /proc/mounts | grep -c Ordner)

UUOC!

Ob das jede/r versteht? LOL, so ganz verzichte ich auf diesen Preis
direkt in der Shell auch nicht, weil es manchmal leichter zum Löschen
in der Konsole ist.

Interaktiv ergibt sich das hÀufiger, dass man ein cat in eine vorbereitete Pipe loslÀsst.
In einem Skript macht es natÃŒrlich durchaus Sinn, statt dieses ÃŒberfÃŒssige cat direkt aus der Datei zu lesen.

Post by Аl Воgnеr

Post by David Haller
if grep -q ' /Ordner ' /proc/mounts/; then
: ...
else
: ...
fi

So habe ich das auch in Verwendung, aber gebe gerne zu, dass die
Empfehlung dazu von David kam ;-)

Post by David Haller
Ich empfehle daher seit Jahren jedem immer "test" zu verwenden, und
nicht die ' [ .. ] ' Version.

GrundsÀtzlich oder nur in diesem Fall?
Wenn ich nach einer leeren Variablen teste, verwende ich test -z, sonst
aber dieses if ...

Ja, so Àhnlich handhabe ich es auch.
Im Prinzip ist es eine Geschmackssache.
Die eckigen Klammern haben halt den Vorteil, dass sie vom Auge schneller erfasst werden können, um die Struktur eines Programms zu erkennen.
Als C-Programmierer bevorzuge ich auffÀlligere Symbole wie runde, eckige oder geschweifte Klammern gegenÌber Wörtern wie test (bash) oder begin und end (z.B. Pascal).
Ich verwende aber sogar beides - manchmal auch im selben Skript! - selbst wenn das stilistisch verworren wirkt - manchmal kommt dann der kleine Anarcho-Rebell in mir hervor.
Eigentlich mag ich jedes Programm stilistisch schön einheitlich. :-)

Mach's einfach so, dass Du die Struktur Deines Programms am besten lesen kannst.

G, C*

[David Haller]

Hallo,

Post by Carsten Neumann

Post by Аl Воgnеr

Post by David Haller
Ich empfehle daher seit Jahren jedem immer "test" zu verwenden, und
nicht die ' [ .. ] ' Version.

[..]

Post by Carsten Neumann

Post by Аl Воgnеr
Grundsätzlich oder nur in diesem Fall?

[..]

Post by Carsten Neumann
Die eckigen Klammern haben halt den Vorteil, dass sie vom Auge
schneller erfasst werden können, um die Struktur eines Programms zu
erkennen.

*BUFF* Reingefallen. Das Konstrukt ' [ .. ]' (man achte auf die
NOTWENDIGEN Leerzeichen!) ist eben _KEIN_ Teil der Struktur des
Scripts (Programms), sondern ein Sonderfall eines anderen Befehls,
nämlich von 'test', egal ob builtin oder nicht.

Ein ' [ .. ];' spiegelt vor, Teil der Syntax zu sein, ist es aber
nicht, sondern nur ein Sonderfall von 'test .. ;' und spiegelt
_GERADE NICHT_ die Struktur des Scriptes (Programms) wider, sondern
verschleiert sie sogar! Somit ist ein "schnelleres Erfassen" der
Struktur des Scripts (Programms) eben genau _NICHT_ möglich, denn das
Konstrukt ' [ .. ]' verschleiert die Struktur des Scripts (Programms)
sogar!

Ergo: Setzen, sechs.

-dnh

[Carsten Neumann]

Post by David Haller
Hallo,

Post by Carsten Neumann

Post by Аl Воgnеr

Post by David Haller
Ich empfehle daher seit Jahren jedem immer "test" zu verwenden, und
nicht die ' [ .. ] ' Version.

[..]

Post by Carsten Neumann

Post by Аl Воgnеr
GrundsÀtzlich oder nur in diesem Fall?

[..]

Post by Carsten Neumann
Die eckigen Klammern haben halt den Vorteil, dass sie vom Auge
schneller erfasst werden können, um die Struktur eines Programms zu
erkennen.

*BUFF* Reingefallen. Das Konstrukt ' [ .. ]' (man achte auf die

Nö!

Post by David Haller
NOTWENDIGEN Leerzeichen!) ist eben _KEIN_ Teil der Struktur des

Jaja, die bösen bösen Leerzeichen!

Post by David Haller
Scripts (Programms), sondern ein Sonderfall eines anderen Befehls,
nÀmlich von 'test', egal ob builtin oder nicht.

Das ist doch nun alles bekannt!
Du wiederholst Dich.

Als Du das letzte Woche herausgefunden hattest, hast Du das wohl als persönlichen Angriff gewertet.

Post by David Haller
Ein ' [ .. ];' spiegelt vor, Teil der Syntax zu sein, ist es aber

Spiegelt ... aha!

Post by David Haller
nicht, sondern nur ein Sonderfall von 'test .. ;' und spiegelt
_GERADE NICHT_ die Struktur des Scriptes (Programms) wider, sondern
verschleiert sie sogar! Somit ist ein "schnelleres Erfassen" der
Struktur des Scripts (Programms) eben genau _NICHT_ möglich, denn das
Konstrukt ' [ .. ]' verschleiert die Struktur des Scripts (Programms)
sogar!

Das ist Blödsinn!
/usr/bin/[ bzw. das Built-In wurde ja nicht von irgendwelchen Idioten eingefÃŒhrt.
Und nur, um David Haller zu Àrgern.

Oder willst Du Tausenden von Programmierern unterstellen, sie benÃŒtzen die eckigen Klammern in ihren Shell-Skripten, um die Struktur ihrer Programme zu verschleiern?

Post by David Haller
Ergo: Setzen, sechs.

Das musstest Du wohl wÀhrend Deiner Schulzeit ein paar mal zu oft hören.
Traumatisches Erlebnis!

Post by David Haller
-dnh

[David Haller]

Hallo,

Post by Carsten Neumann
if [ $gefunden = 0 ]; then ...

Stringvergleich, wenn Integervergleich gefordert ist.
Setzen sechs.

-dnh

[Carsten Neumann]

Post by David Haller
Hallo,

Post by Carsten Neumann
if [ $gefunden = 0 ]; then ...

Stringvergleich, wenn Integervergleich gefordert ist.
Setzen sechs.

Soso, das fÀllt Dir auf, aber das mit `[ $gefunden ]Ž ist Dir nicht aufgefallen.
Trotzdem funktioniert mein Test, was der ursprÃŒngliche _nicht_ tat.

Ich sage mal:
Vorlaut, ab in die Ecke!

Post by David Haller
-dnh

[David Haller]

Hallo,

Post by David Haller

Post by Carsten Neumann
if [ $gefunden = 0 ]; then ...

Stringvergleich, wenn Integervergleich gefordert ist.
Setzen sechs.

Soso, das fällt Dir auf, aber das mit `[ $gefunden ]? ist Dir nicht
aufgefallen. Trotzdem funktioniert mein Test, was der ursprüngliche
_nicht_ tat.

Natürlich ist mir das aufgefallen, Dumpfbacke. Und jetzt kriech zurück
unter deinen Stein.

-dnh
--

*grummel* Man sollte das Baggern gesetzlich verbieten. Ständig wird
mit diesem Unfug irgendwo Chaos angerichtet...

Stimmt. Besonders in Discos oder solche Teile. Da sind durch falsches baggern
schon die besten Freundschaften auseinander gegangen.
[Eilert Brinkmann und Bernd Brodesser in suse-talk]

[Carsten Neumann]

Post by David Haller
Hallo,

Post by David Haller

Post by Carsten Neumann
if [ $gefunden = 0 ]; then ...

Stringvergleich, wenn Integervergleich gefordert ist.
Setzen sechs.

Soso, das fÀllt Dir auf, aber das mit `[ $gefunden ]? ist Dir nicht
aufgefallen. Trotzdem funktioniert mein Test, was der ursprÃŒngliche
_nicht_ tat.

NatÃŒrlich ist mir das aufgefallen, Dumpfbacke. Und jetzt kriech zurÃŒck
unter deinen Stein.

Meine GÃŒte!
Was hast Du Dir denn reingezogen?
Zieh Dir noch 'ne Nase rein und heul Dich dann bei Mami aus, lass aber Deinen Hochmut und Aggros nicht in der Liste ab, du Troll!

Post by David Haller
-dnh

[David Haller]

Post by Carsten Neumann
lass aber Deinen Hochmut und Aggros nicht in der Liste ab, du Troll!

-dnh

[David Haller]

Hallo,

Post by mararm

Post by Joachim H.
cat /proc/mounts | grep Ordner.

[..]

Post by mararm
Das kannst du ausnutzen, in dem du entweder die Aktion direkt an den grep-
Aufruf anhängst
cat /proc/mounts | grep Ordner && echo "eingebunden"
cat /proc/mounts | grep Ordner || echo "nicht eingebunden"

UUOC.

if grep -q 'Ordner' /proc/mounts ; then
echo "Ordner gemounted";
else
echo "Ordner nicht gemounted";
fi

Post by mararm
cat /proc/mounts | grep Ordner && echo "eingebunden" || echo "nicht
eingebunden"

Ausserdem ist 'foo && bar || baz' nicht robust, falls 'bar'
"false" als Exitstatus liefern könnte. Z.B.:

$ { grep -q ' / ' /proc/mounts
&& ( echo $?; exec 1>&-; echo "mounted"; )
|| echo "unmounted" >&2 ; }
0
bash: echo: write error: Bad file descriptor
unmounted

Ja, das ist konstruiert, zeigt aber das Verhalten, daß der Teil
'|| echo ...' ausgeführt wird, obwohl '/' natürlich gemounted ist.

(Zusatzaufabe: erkläre, was obiger "Einzeiler" macht ;)

Post by mararm
oder den Rückgabewert abfragst und später verarbeitest
cat /proc/mounts | grep Ordner
gefunden=$?
if [ $gefunden ]; then ...

UUOC und falsche Anwendung von 'test'.

$ test 0 ; echo $?; test 1 ; echo $?
0
0

Wenn, dann mußt du $? (also $gefunden) numerisch mit 0 vergleichen:

if test $gefunden -eq 0 ; then
: mounted
else
: unmounted
fi

HTH,
-dnh
--

Post by mararm

Post by Joachim H.
Ich spiele mit dem Gedanken, netdigest abzubestellen.
Habbich eh alles schon gelesen. -- Konni

.... oder geschrieben. -- Hanno

Kann das mal jemand einreichen? ;-) -- Konni