• Apfeltalk ändert einen Teil seiner Allgemeinen Geschäftsbedingungen (AGB), das Löschen von Useraccounts betreffend.
    Näheres könnt Ihr hier nachlesen: AGB-Änderung
  • Die Bildungsoffensive hier im Forum geht weiter! Jetzt sollen Kreativität und technische Möglichkeiten einen neue Dimension erreichen. Das Thema in diesem Monat lautet - Verkehrte Welt - Hier geht es lang --> Klick

USB-Stick mounten und umounten in der bash

roland0509

Süsser Pfaffenapfel
Registriert
21.02.11
Beiträge
667
Hallo,

ich schreib da auch jetz mal was.

Ich möchte folgendes:

  • Ich will einen USB-Stick an ein MacBook anstecken.
  • Dort liegt eine Script datei (bash).
  • Die soll ausgeführt werden.
  • Anschließend soll der Stick ausgeworfen werden.
  • Wenn geht mit einer Pop-Up-Message-Box.
ist das realisierbar?

Ich kann halbwegs mit der Bash arbeiten, hab aber selbst noch kein
Macbook zum probieren.

LG Roland
 
1) Eine "Autorun" Funktion gibt es in OS X nicht.
Du kannst aber mittels "launchd" einen Hintergrunddienst (LaunchAgent oder LaunchDaemon) basteln, der bei jedem Mountvorgang aufgerufen wird und der auf ein bestimmtes Kriterium hin eine Prüfung vornehmen kann (zB nach Volumenamen, einer Volume-UUID oder einer bestimmten Datei, die einen gewünschten Vorgang triggern soll.)

2) Ums mounten brauchst du dich nicht zu kümmern, das erledigt sich von selbst.
Das deaktivieren bzw auswerfen per Shell erledigt man mittels "diskutil".

3) Message-Boxen aus einem Shellskript heraus sind auf verschiedene Arten machbar. Möglich sind zB das Einbinden eines minimalistischen AppleSkripts (via "osascript") oder die Verwendung eines speziell für solche Zwecke geschriebenen Hilfsprogramms (zB "CocoaDialog" oder "Pashua" - das allseits verhasste "Growl" muss man sich dazu nicht antun.)
 
Wieso ist Growl "allseits verhasst"?
 
3) Message-Boxen aus einem Shellskript heraus sind auf verschiedene Arten machbar. Möglich sind zB das Einbinden eines minimalistischen AppleSkripts (via "osascript") oder die Verwendung eines speziell für solche Zwecke geschriebenen Hilfsprogramms (zB "CocoaDialog" oder "Pashua" - das allseits verhasste "Growl" muss man sich dazu nicht antun.)
Hättest du ein Beispiel?

fyysh schrieb:
Wieso ist Growl "allseits verhasst"?
Frag ich mich auch. Wenns verhasst ist, weils nur auf der Konsole ist oder so, dann zählt das nicht, ich verwende ein Linux, das ich aus der Konsole weg gebaut hab.
 
Zuletzt bearbeitet:
Keine Autorun-Funktion?
Nein. Und das ist gut so. Wenn du ein bisschen darüber sinnierst, wird sich dir 100%ig der Grund erschließen. ;)

Ich will den Stick anstecken, den Bash-Script öffnen (einfach auf die blabla.sh klicken? Hab sie unter Linux ausführbar gemacht.)
Das kann man automatisieren. Rasta hat dir gesagt wie. Musst nur noch googeln.

Der Bash-Script soll dann arbeiten, (Wie kann ich auf den Stick zugreifen? Wie kann ich ihn ansprechen, um ein Dokument am Stick zu erstellen
Das Skript ist doch im root des Sticks, oder? Nutz $0.

und wie geht das mit diskutil? um ihn auszuwerfen? Kann man da mit dem Label arbeiten, dass ich ihm gegeben hab wie ich ihn vfat formatiert hab?
Ja. OSX mountet per default nach /Volumes/$LABEL. Oder halt du nutzt $0.


Hättest du ein Beispiel?
osascript -e 'tell app "finder"' -e 'activate' -e 'display dialog "hello world"' -e 'end'


Frag ich mich auch. Wenns verhasst ist, weils nur auf der Konsole ist oder so, dann zählt das nicht, ich verwende ein Linux, das ich aus der Konsole weg gebaut hab.
Für gewöhnlich hat Rasta andere Gründe für solche Aussagen. Nicht solch triviale.
Ich bin auf seine Antwort gespannt.
 
Keine Autorun-Funktion?
Nein. Ein latentes Sicherheitsproblem weniger.
Aber wie gesagt, sowas kann man sich mit ein paar Zeilen Shellskript selber basteln.

Ich will den Stick anstecken, den Bash-Script öffnen
Noch mal zur Klarstellung:
- Das Skript befindet sich auf deinem System? Oder auf dem externen Datenträger?
- Das Skript soll immer aktiviert werden wenn ein Volume erfasst und gemountet wird, egal von wem?
Oder nur wenn ein (oder mehrere) bestimmte(r) Benutzer gerade angemeldet ist?

Wie kann ich auf den Stick zugreifen?
Der automatisch vergebene Mountpoint liegt immer unterhalb von /Volumes/
(Das gleiche wäre bei Linux-Distris unter /media/ zu finden)
Benannt wird er nach dem Volume-Label, falls mehrere gleichzeitig aktive Volumes einen identischen Namen tragen wird vom Automount-Kobold eine aufsteigende Sequenznummer angehängt.

und wie geht das mit diskutil? um ihn auszuwerfen? Kann man da mit dem Label arbeiten...?
Funktioniert alles gleichermassen:
Code:
diskutil unmountDisk "[I]Volume Label[/I]"
diskutil unmountDisk "[I]/Volumes/Mountpoint[/I]"
diskutil unmountDisk /dev/disk[I][COLOR="red"]n[/COLOR][/I]
diskutil unmountDisk /dev/disk[I][COLOR="red"]n[/COLOR][/I]s[I][COLOR="red"]y[/COLOR][/I]
diskutil unmountDisk disk[I][COLOR="red"]n[/COLOR][/I]
diskutil unmountDisk disk[I][COLOR="red"]n[/COLOR][/I]s[I][COLOR="red"]y[/COLOR][/I]
diskutil eject "[I]Volume Label[/I]"
diskutil eject "[I]/Volumes/Mountpoint[/I]"
diskutil eject /dev/disk[i][COLOR="red"]n[/COLOR][/i]
diskutil eject /dev/disk[i][COLOR="red"]n[/COLOR][/i]s[i][COLOR="red"]y[/COLOR][/i]
diskutil eject disk[I][COLOR="red"]n[/COLOR][/I]
diskutil eject disk[I][COLOR="red"]n[/COLOR][/I]s[I][COLOR="red"]y[/COLOR][/I]
Die Variante mit 'eject' bewirkt -natürlich nur bei entsprechenden Medientypen- gleichzeitig auch den mechanischen Auswurf, bzw bei USB Geräten die Trennung vom Bus. Die Variante mit 'unmountDisk' dagegen deaktiviert nur die gemounteten Volumes, so dass man sie bei Bedarf gleich wieder erneut mounten kann (d.h. ein USB Gerät bleibt weiterhin physisch ansprechbar).
Das "Stecker ziehen" ist jedenfalls in beiden Fällen danach auf sichere Weise möglich.

Frag ich mich auch. Wenns verhasst ist, weils nur auf der Konsole ist oder so
Nein, eher nicht. Stehst du etwa auf diese penetranten Sprechbläschen, die dir in der Taskbar des Windows Explorers die Tray-Icons "erklären", immer und immer und immer und immer wieder? Naja, jeder wie er/sie es mag...
 
Zuletzt bearbeitet:
fyysh schrieb:
Nein. Und das ist gut so. Wenn du ein bisschen darüber sinnierst, wird sich dir 100%ig der Grund erschließen. ;)
Also ich hab unter windows immer schön böse sachen angestellt (bei schulkollegen). So batch scripte mit shutdown und so :-D

fyysh schrieb:
Das kann man automatisieren. Rasta hat dir gesagt wie. Musst nur noch googeln.
Ist mir glaub ich zu aufwändig. Wenn ich am Stick ein bash.sh aufmache (es ist ausführbar) dann öffnet der das im Terminal und beginnt, oder?

fyysh schrieb:
Das Skript ist doch im root des Sticks, oder? Nutz $0.
kann ich mit cd $0 also wieder ins root vom Stick? Bzw. es geht also auch ein $0/ordner/sript.sh?

fyysh schrieb:
Ja. OSX mountet per default nach /Volumes/$LABEL. Oder halt du nutzt $0.
wie heißt denn das dann unter mac? geht da ein "umount /Volumes/STICK" wie unter Linux?

fyysh schrieb:
osascript -e 'tell app "finder"' -e 'activate' -e 'display dialog "hello world"' -e 'end'
Das war glaub ich verständlich. Wenn ich die Zeile 1:1 kopiere kommt nur "hello world" oder?

fyysh schrieb:
Für gewöhnlich hat Rasta andere Gründe für solche Aussagen. Nicht solch triviale.
Ich bin auf seine Antwort gespannt.
Das interessiert mich jetzt auch.
 
Wenn ich am Stick ein bash.sh aufmache (es ist ausführbar) dann öffnet der das im Terminal und beginnt, oder?
Kommt drauf an ob du das Suffix *.sh nicht selbst einem anderen Programm zugeordnet hast, zB einem Texteditor.
So würde sich das jedenfalls gehören, denn *.sh nennt man nur Entwürfe, Beispielcode oder Skripten die gedacht sind um aus anderen heraus "gesourced" zu werden. Dateien mit *.sh sind (von braven Menschen) als Quelltext zu interpretieren, genau wie *.c , *.h , *.cpp oder ähnliches.
(Üblicherweise macht man sie daher auch nicht ausführbar, das ist eine Unsitte.)
Es gibt zwei (funktionell identische) Suffixe, die speziell dem Programm "Terminal.app" gehören und die das gleiche bewirken, das sind *.tool oder *.command - Die Verwendung dieser beiden sorgt für mehr Klarheit.

kann ich mit cd $0 also wieder ins root vom Stick? Bzw. es geht also auch ein $0/ordner/sript.sh?
Der Parameter $0 ist der Pfad des gerade ausgeführten Programms/Skripts.

geht da ein "umount /Volumes/STICK" wie unter Linux?
Von den "LowLevel" Befehlen aus der Unix-Steinzeit wie mount*, umount, fdisk, gpt, mkfs*, fsck* etc lass mal lieber die Finger. Mit diesen Primitivmitteln hast du als Benutzer keinen Kontakt mehr.
Benutze nach Möglichkeit immer die höher angesiedelten (sehr viel weitergehend abstrahierten) Framework-Schnittstellen. OS X hat viele "utils" in Petto:
Für physische Datenträger (DiskManagement.framework) --> diskutil
Für virtuelle Datenträger (DiskImages.framework) --> hdiutil
Für optisch beschreibbare Medien (DiskRecording.framework) --> drutil
Für Hi-Level Text Management --> textutil
Für die konsolenbasierte Verwaltung des Installationssystems --> pkgutil
usw usf...

Kleine Faustregel für frischgebackene "*nix-2-OSX" Umsteiger:
1) Suche für dein Aufgabengebiet ein passendes Programm namens ????util
2) Findest du keines, hat es vermutlich irgendein etwas detaillierter orientiertes ????tool dafür
3) Erst wenn sich auch da nichts brauchbares findet (und wirklich erst dann), denk darüber nach es so zu machen wie es unter den diversen Bastler-Unixen früher mal (aka "nach'm Krieg") üblich war. Die "BSD/GNU Basiswerkzeuge" sind immer nur der letzte Ausweg.
 
<OT>
Von den "LowLevel" Befehlen aus der Unix-Steinzeit wie mount*...

Jetzt sag nicht, dass es irgend ein *util oder *tool gibt, um SMB, NFS, AFP... shares zu mounten. Bisher kannte ich das nur über bspw. mount_afp oder mount -t afp. Oder eben über osascript oder open, wobei das ja u.U. Zugang zum GUI erfordert - geht aber um Mounten mit auschließlichem Zugang zum CLI.
</OT>



Nein, eher nicht. Stehst du etwa auf diese penetranten Sprechbläschen, die dir in der Taskbar des Windows Explorers die Tray-Icons "erklären", immer und immer und immer und immer wieder? Naja, jeder wie er/sie es mag...
Achsooo. :-)
Also diese Windows-Bläschen mag ich auch nicht, aber Growl, nur für die unobtrusiven (sorry, dt. Wort fällt mir grad nicht ein) Meldungen, die man haben will, ist ja gar nicht soooo schlecht. Growl kann man ja auch beeinflussen, so dass du eben nicht mit unnötigem Zeug zugebombert wirst. Das geht (AFAIK) bei den Win Tool Tips nicht, d.h. du hast nur die Wahl zw. alle oder keine - ein wesentlicher Unterschied IMHO.
Da gibt's übrigens ein commandline Tool namens "growlnotify", ist irgendwo in den Extras auf der Growl-DMG.
 
Hallo,

Fangen Scripte unter Mac auch so an?
Code:
#!/bin/bash

Nochmal:
Ich habe einen iPod, der hat einen Unterordner "bash" und dort liegt die datei script.
Wenn ich die Dort ausführe, kann ich dann den befehl so ausführen?
Code:
cp ~/test ./
Also die datei test, aus dem user-home-verzeichnis, auf den iPod in den unterordner bash.
Bzw. ein
Code:
touch test.local
erstellt die datei: iPod/bash/test.local!?

Wenn mein iPod ROLAND heißt, kann ich ihn dann mit

Code:
diskutil eject "ROLAND"
auswerfen oder? Ist das case-sensitive?

Unter Linux hat man *.sh für die Scripte von daher der Ansatz.

Welches Suffix würdest du empfehlen?

Werden beide standardmäßig von Terminal.app geöffnet?
 
Rastafari schrieb:
Noch mal zur Klarstellung:
- Das Skript befindet sich auf deinem System? Oder auf dem externen Datenträger?
- Das Skript soll immer aktiviert werden wenn ein Volume erfasst und gemountet wird, egal von wem?
Oder nur wenn ein (oder mehrere) bestimmte(r) Benutzer gerade angemeldet ist?
Ich hab ein Script am iPod und das will ich einmal öffnen. (Die Frage ist nur wie)

Rastafari schrieb:
... wie es unter den diversen Bastler-Unixen früher mal (aka "nach'm Krieg") üblich war. Die "BSD/GNU Basiswerkzeuge" sind immer nur der letzte Ausweg.
Also bitte, das verwendet man heute noch.
Es funktioniert halt einfach super, und ist einfach. (Obwohl theorietisch sind wir na noch "nach'm Krieg")
 
Sorry, aber irgendwie passt diese Aussage
Wenns verhasst ist, weils nur auf der Konsole ist oder so, dann zählt das nicht, ich verwende ein Linux, das ich aus der Konsole weg gebaut hab.
nicht zu deinem letzten Post.

Fangen Scripte unter Mac auch so an?
Bash Script ist Bash Script, egal wo.

Wenn ich die Dort ausführe, kann ich dann den befehl so ausführen?
Wenn $PWD = Ziel ist, dann funktioniert das. Sonst nicht. Eine *.command startet bei Doppelklick nicht einfach im Pfad des Scripts.
Ich würde cp ~/test "$(dirname "$0")" empfehlen (wenn's dahin soll, wo das Script liegt).



Ist das case-sensitive?
Warum probierst du's nicht einfach aus? :-)
 
Fangen Scripte unter Mac auch so an?
#!/bin/bash
"Unter Mac" ist nur die Tischplatte. Oder vllt auch deine Oberschenkel... :-)
Und ja, natürlich. Ein korrektes "Shebang" ist das A und O eines jeden Interpreterprogramms. Egal welches OS, egal welche Sprache (die damit klargestellt wird) und egal welcher Rechner. Diese Konvention ist deutlich älter als Unix und stammt noch aus der Zeit der rein mechanisch aufgebauten Hollerith-Maschine.
"Shebang" als verkürzt gesprochenes "Shalt use this ... program to run. Bang!"; Bang==Ausrufezeichen (engl. Slang)
Damit wird der zu startende Interpreter definiert, der folgendes Skript abarbeiten soll (und optional noch einige Aufrufparameter dazu).
Fehlt diese Angabe, wird die Standard-Shell des Benutzers verwendet, und das muss nicht unbedingt die richtige sein. Also ist das ein *muss*.

Ich habe einen iPod, der hat einen Unterordner "bash" und dort liegt die datei script.
Wenn ich die Dort ausführe, kann ich dann den befehl so ausführen?
cp ~/test ./
Jein.
Du musst zunächst mittels "cd ....." in diesen Ordner wechseln, um ihn zum "aktuellen Arbeitsverzeichnis" zu machen.
Beim Start des Skripts ist ein anderer Ordner als $PWD (=="present working directory") vordefiniert. Je nach der Methode mit der das Skript gestartet wird, ist das meist dein Benutzerordner oder das Wurzelverzeichnis ('/').

Um auf elegante Weise in denjenigen Ordner zu wechseln, in dem sich auch das gerade laufende Skript befindet, kannst du folgendes Konstrukt benutzen:
Code:
cd $(dirname "$0")
cp ~/test .
Jetzt befindest du dich aber in einem Ordner auf dem externen Volume, und solange das dein $PWD ist, darfst du das Volume nicht auswerfen. Du musst also dieses Volume erst wieder verlassen bevor du das Medium abmelden kannst (oder das Ende des Skripts erreicht haben - was aber nicht geht, denn das möchtest du ja auch gleich in diesem Skript erledigen...).
Du müsstest also (neben evtl weiteren Aktionen) folgendes tun:
Code:
cd $(dirname "$0")
cp ~/test .
cd ~
[I][COLOR="DarkSlateGray"]# ...andere Aktionen, und dann auswerfen.[/COLOR][/I]
Oder aber (noch eleganter) du wechselst erst gar nicht dort hin und verwendest stattdessen das cp-Kommando etwas anders, setzt das gewünschte Ziel gleich dort ein:
Code:
cp ~/test $(dirname "$0")
diskutil eject "Volume Label"
Oder aber (nochmals etwas draufgesetzt) du ermittelst auch noch den Namen des auszuwerfenden Volumes mittels dieser Methodik. Das sähe dann (etwas fortgeschrittenerer) so aus:
Code:
cp ~/test $( dirname "$0" )
diskutil eject $( stat -f %Sd "$0" )

Ist das case-sensitive?
Ja, das gilt (grundsätzlich) für jedes Shellkommando.
(Besser formuliert: Wenn du klug bist, gehst du immer davon aus, auch wenn es gerade mal nicht zutrifft.)
Aber... mach einfach das oben beschriebene, dann brauchst du den Namen gar nicht zu kennen. Das dort eingesetzte 'stat'-Kommando beschafft dir die nötige Information "on the fly", und zwar immer zuverlässig richtig.

Erklärung: In der oben verwendeten Form gibt 'stat' den "Device-Identifier" des Geräts zurück, auf dem sich die mittels "$0" angegebene Datei befindet, das ganze formatiert als String, also in Klartextform. Dieser Ausgabetext von 'stat' wird dann durch das umschliessende '$( ... )' in den 'diskutil'-Befehl eingesetzt.
(Wenn du genau hinsiehst, findest du die roten Stellen im Kommando)

Unter Linux hat man *.sh für die Scripte
Ungeliebte Tatsache: Linux ist weitreichend ein System von und für Amateure/Autodidakten.
Da machten (und machen) sich viele Unsitten breit.

Welches Suffix würdest du empfehlen?
Für nur unter OS X verwendbare Skripten ist *.tool angemessen.
Für plattformneutral gehaltene Dinge empfiehlt sich *.command
(weil dieses Suffix auch in anderen Systemen bekannt ist und dort ähnlich verwendet wird)
Aber das ist nur Konvention zur Klarstellung, funktionieren wird das alles auch ganz ohne irgendein Suffix.

Werden beide standardmäßig von Terminal.app geöffnet?
Ja. Solange du nicht selbst was anderes definierst jedenfalls.
 
fyysh schrieb:
... irgendwie passt diese Aussage ... nicht zu deinem letzten Post.
Naja, sicher ist sicher, vielleicht war das ja auch nach'm Krieg so.
Rastafari schrieb:
Fehlt diese Angabe, wird die Standard-Shell des Benutzers verwendet, und das muss nicht unbedingt die richtige sein. Also ist das ein *muss*.
Sowas war mir nicht ganz klar.

fyysh schrieb:
Wenn $PWD = Ziel ist, dann funktioniert das. Sonst nicht. Eine *.command startet bei Doppelklick nicht einfach im Pfad des Scripts.
Ich würde cp ~/test "$(dirname "$0")" empfehlen (wenn's dahin soll, wo das Script liegt).
Versteh ich nicht ganz. Gibts eine Endung, die den Script, sofern er ausführbar ist (ist er) mit dem Terminal.app öffnet und abarbeitet?

fyysh schrieb:
Warum probierst du's nicht einfach aus?
Rastafari schrieb:
"Unter Mac" ist nur die Tischplatte. Oder vllt auch deine Oberschenkel...
Kann ich nicht probieren, bzw. da ist kein Oberschenkel. Ich hab noch keinen Mac. Der Script ist für einen Schulkollegen. Ich will mir im Sommer ein Macbook kaufen.

Rastafari schrieb:
Code:
cp ~/test $( dirname "$0" )
diskutil eject $( stat -f %Sd "$0" )
Danke, genau sowas hab ich gesucht.

Rastafari schrieb:
(Wenn du genau hinsiehst, findest du die roten Stellen im Kommando)
Mit sowas hab ich mich schon öfter unter Linux gespielt.

Rastafari schrieb:
Ja. Solange du nicht selbst was anderes definierst jedenfalls.
Der hat keinen Schimmer von Computern (deshalb schreib ja auch ich das Script). Der wird also nicht einmal ahnen, das es die Terminal.app gibt, bzw. das man endungen Programme zuweisen kann.

Danke erstmal, ich glaub jetzt sollte alles so hinhauen.

LG Roland