Sammlung eurer Terminalbefehle

[Skeeve]

perl - macht alles was ich will

 

[lazertis]

O doch, das ist es. Ein so beendetes Programm wird zB seine Voreinstellungen nicht mehr abspeichern.

Danke für die Korrektur, da habe ich mich geirrt (mein Post ist entsprechend korrigiert).

Sorry für das Durcheinander.

 

[iBooker]

Dann geb ich auch mal meinen Senf dazu...

top

zum anzeigen der Prozesse und Auslastung des Systems.

 

[lazertis]

Spotlight lite im Terminal:

Wer auf Betriebssystemebene ein Verzeichnis oder eine Datei sucht:

locate <Suchbegriff>

gibt alle passenden Dateinamen und -pfade aus.
Passt allerdings auch Teilstrings und kann darum ziemlich viel werden.

locate <Suchbegriff> | more

gibt das Ganze seitenweise aus.

Nachteil/Hinweis für Insider: Die locate-Datenbank /private/var/db/locate.database wird standardmässig nur einmal wöchentlich (Samstag Nacht) per regelmässigem Job (periodic weekly) aktualisiert (-> neu aufgebaut). Neues ist also nicht gleich enthalten und es wird nur aktualisiert, wenn der Rechner während der geplanten Jobzeit auch läuft.

 

[Hobbes_]

Neben dem noch von BSD-Unix stammenden Befehl locate, kann man auch direkt auf Spotlight zurückgreifen mit dem Mac OS eigenen Programm

mdfind

Dabei können auch die Tags gezielt abgefragt werden.

Weitere Infos wie immer mittels man mdfind

Gruss
psc

 

[lazertis]

Neben dem noch von BSD-Unix stammenden Befehl locate, kann man auch direkt auf Spotlight zurückgreifen mit dem Mac OS eigenen Programm

mdfind

Das ist natürlich noch besser. Hatte ich zwar mal gelesen, aber schon wieder vergessen. Als Teil-Linuxer bin ich halt locate so gewohnt und freute mich, es auf dem Mac wiederzusehen. Aber Spotlight / mdfind rulez.

Vielleicht den noch

df -m

zeigt die Füllgerade der gemounteten Volumes (in Mbyte) an.

Statt -m geht auch

-k (kByte),
-g (GByte) und
-h (human readable, also was am besten passt)

Ist zwar nicht so grafisch schön wie iStat Pro oder die Aktivitätsanzeige, ist aber dafür gleich mit dabei und zeigt alle Platten auf einmal an.

 

[der_Kay]

http://www.kernelthread.com/mac/osx/tools.html

Hochinteressant:
http://osxutils.sourceforge.net/

Es macht mehr Sinn zu verstehen, wie eine Shell funktioniert: Ein- Ausgabeumleitung bzw. Pipes, regular expressions und wie man Shell-Kommandos geschickt zusammensetzt.

 

[Tengu]

Von so was würd ich Abstand nehmen. Es hat schon seinen Grund, se warum diese AddIns nicht standartmäßig integriert sind.
Tendenziell macht es nämlich auf lange Sicht wenig Sinn unique-artige Befehle auf seinem System zu nutzen. Das Problem ist nämlich, dass man verlernt, die richtigen zu nutzen.
Okay, google "bla" kann nett sein, aber der Rest ist irgendwie auch nicht so sinnig, oder? (Das betrifft den Sourceforge Link)

 

[der_Kay]

Von so was würd ich Abstand nehmen. Es hat schon seinen Grund, se warum diese AddIns nicht standartmäßig integriert sind.

Allenfalls weil sie den Standard-Benutzer überfordern.

Tendenziell macht es nämlich auf lange Sicht wenig Sinn unique-artige Befehle auf seinem System zu nutzen.

Hä? UNIX?

Das Problem ist nämlich, dass man verlernt, die richtigen zu nutzen.

Die wären? SetFile, GetFileInfo? Die setzen installierte Developer Tools voraus.

Okay, google "bla" kann nett sein, aber der Rest ist irgendwie auch nicht so sinnig, oder? (Das betrifft den Sourceforge Link)

Hast Du eigentlich gelesen, was die leisten?
- Schon mal ein paar hundert Metadaten von Bildern und Texten auf einen Rutsch mit einer bestimmten Menge Schlüsselwörter ergänzt?
- Schonmal automatisiert webloc-Dateien erstellt, die die Seitenbeschreibung als Spotlight Kommentar enthalten?
- Schon mal gezielt hunderte Creator-Flags gesetzt, editiert oder gelöscht?
- Schon mal den Spotlight-Output in einem Script verarbeitet?

Die Tools machen definitiv Sinn.

 

[Walli]

Für was soll das denn gut sein, den Finder hart zu 'killen'?

Finder läuft aus meiner Erfahrung stabil genug; auch tun solche Dinge einem System nie besonderes gut...

Der Finder ist ein scheiß Programm. Muss ich einfach so sagen. Da hilft manchmal echt nur die Holzhammermethode. Aber schön, dass es auch Leute gibt, die da andere Erfahrungen gemacht haben .

Ich erledige mittlerweile fast die Hälfte aller Arbeiten im Terminal. Je nach dem was man macht ist man damit viel produktiver. Natürlich muss man einen gewissen Grundschatz an Befehlen verinnerlicht haben und der ein oder andere nette alias ist auch nicht verkehrt.

Am meisten verwende ich neben den Standardsachen wie cp, mv, rm, tail und cat wohl ssh, qsub, grep und od. Aber einen wirklichen Lieblingsbefehl habe ich nicht. Für komplexere Abläufe habe ich mir auch ein wenig Shell-Scripting angeeignet. Sehr praktisch.

 

[Hilarious]

Allenfalls weil sie den Standard-Benutzer überfordern.
Hä? UNIX?

Die wären? SetFile, GetFileInfo? Die setzen installierte Developer Tools voraus.


Hast Du eigentlich gelesen, was die leisten?
- Schon mal ein paar hundert Metadaten von Bildern und Texten auf einen Rutsch mit einer bestimmten Menge Schlüsselwörter ergänzt?
- Schonmal automatisiert webloc-Dateien erstellt, die die Seitenbeschreibung als Spotlight Kommentar enthalten?
- Schon mal gezielt hunderte Creator-Flags gesetzt, editiert oder gelöscht?
- Schon mal den Spotlight-Output in einem Script verarbeitet?

Die Tools machen definitiv Sinn.

Ich neige sonst nicht dazu »Me, too«-Beiträge zu verfassen, aber was der_Kay schreibt, ist mehr als richtig!

 

[Hobbes_]

Da hilft manchmal echt nur die Holzhammermethode. Aber schön, dass es auch Leute gibt, die da andere Erfahrungen gemacht haben .

Ich erledige mittlerweile fast die Hälfte aller Arbeiten im Terminal. Je nach dem was man macht ist man damit viel produktiver. Natürlich muss man einen gewissen Grundschatz an Befehlen verinnerlicht haben und der ein oder andere nette alias ist auch nicht verkehrt.

Das schöne am Mac ist, dass er etwas für alle bietet: Eine einfache und ästhetisch gehaltene Benutzerobefläche und auch ein vollständiges UNIX under the hood, das man als Poweruser schön ausreizen kann.

Tja, da war ich wohl bisher glücklich, dass ich keine Probleme mit Finder hatte. Er erfüllt meine Zwecke (auf GUI Ebene) auch gut. Mich hat insbesondere die von NeXT übernommene Darstellung der Verzeichnisebenen angesprochen. Doch da hat jeder wohl etwas andere Angewohnheiten und Ansprüche.

Mein von Dir zitierter Kommentar zielte jedoch insbesondere darauf ab, dass man nicht allzu leichtfertig Holzhammermethoden anwenden soll (was, wie ich sah, auch von anderen Usern bestätigt wurde).

Doch klar: Wenn ein Holzhammer notwenig ist, dann soll er kunstvoll geschwungen werden. Man soll sich dabei doch nur vergewissert haben, dass sich keine Glasscheibe zwischen Hammer und Problem befindet. :-D

 

[Walli]

Das schöne am Mac ist, dass er etwas für alle bietet: Eine einfache und ästhetisch gehaltene Benutzerobefläche und auch ein vollständiges UNIX under the hood, das man als Poweruser schön ausreizen kann.

Ja, das kann ich so unterschreiben.

Doch klar: Wenn ein Holzhammer notwenig ist, dann soll er kunstvoll geschwungen werden. Man soll sich dabei doch nur vergewissert haben, dass sich keine Glasscheibe zwischen Hammer und Problem befindet. :-D

 

[tjp]

(Ein "SIGTERM" ist die harte Methode. Der einzige Unterschied zum noch härteren "SIGKILL" (a.k.a. Signal 9) ist die Möglichkeit, das Signal per Trap abzufangen und damit gezielt zu ignorieren. Die "sanften" Methoden in Unix-Umgebungen heissen "SIGHUP" bzw "SIGQUIT".)

• SIGHUP ist der traditionelle Weg einem Daemon mitzuteilen, daß er sein Configfile neueinlesen soll. Er wird sich also nicht beenden!
• SIGINT wird immer gesendet, wenn man CTRL-C im Terminal eintippt.
• SIGTERM ist der Vorgabewert für kill.
• SIGKILL dafür kann man keinen Signalhandler installieren. Daher beendet SIGKILL immer einen Prozeß, sofern es keinen Bug im Kernel gibt.

Wenn kein Signalhandler installiert ist, werden bei allen vier Signalen die Prozesse beendet und sie unterscheiden sich in ihrer Auswirkung gar nicht.

 

[Rastafari]

SIGHUP ist der traditionelle Weg einem Daemon mitzuteilen, daß er sein Configfile neueinlesen soll. Er wird sich also nicht beenden!

Mit "Tradition" hat das gar nichts zu tun, eher mit "Ad Hoc Recycling".

"HUP" (für "Hung Up") ist die informative Benachrichtigung an einen Prozess, dass er absolut keinerlei Verbindung mit seinem kontrollierenden Terminal mehr besitzt, und dass diese Verbindung auch dauerhaft getrennt bleiben wird.
(HUP wurde traditionell vom Akustikkoppler initiiert, sobald er durch den Wegfall des "Carrier-Tons" davon ausgehen musste, dass jemand am anderen Ende der Telefonleitung einfach den Hörer aufgehängt hat, daher der Name.)

Demzufolge sind alle weiteren Versuche, nach einem HUP eine Interaktion mit dem Anwender durchzuführen von vorneherein zum scheitern verurteilt. Die einzig logische Konsequenz für ein auf diese Weise "taubstumm" gewordenes Programm ist es, sich selbst und all seine Kindprozesse ohne Rückfragen, aber nach Möglichkeit in disziplinierter, geregelter Form zu beenden.
Und genau dafür wird dieses Signal traditionell eingesetzt: Um Programme sauber zu schliessen und ihnen die Möglichkeit einzuräumen, begonnene Dateioperationen noch zu Ende zu bringen.

Bei daemons nun, die per Definition weder ein solches kontrollierendes Terminal besitzen, noch dazu gedacht sind, überhaupt jemals beendet zu werden, macht ein solches Signal absolut keinen Sinn.
Da man (milde formuliert) etwas knapp an Signalen war, hat man also einfach kurzerhand HUP für einen völlig anderen Zweck umfunktioniert - aber nur, soweit es ganz bestimmte, ausgewählte daemons betraf.
Leider Gottes kamen dann später immer mehr Programmierer einfach nicht dahinter, warum es mittlerweile "User Defined" Signale gibt und führten diese Zweckentfremdung von HUP unverdrossen fort. "Tradition" ist für solche Frickel-Notstands-Ausnahme-Lösungen der denkbar unpassendste Begriff.

Was den Rest deiner Antwort betrifft:
Wenn HUP, TERM, INT, QUIT, STOP, KILL, ABRT und all die weiteren Signale, die einen laufenden Prozess normal oder abnormal beenden können, wirklich das gleiche bewirken würden...
...was denkst du eigentlich, warum es dann so viele davon gibt? Zum Jux?

 

[tjp]

Wenn HUP, TERM, INT, QUIT, STOP, KILL, ABRT und all die weiteren Signale, die einen laufenden Prozess normal oder abnormal beenden können, wirklich das gleiche bewirken würden...

Nein, das habe ich nicht geschrieben! Lies Dir das nochmals durch.

Es gibt nur fünf vordefinierte Ereignisse

• Abort, der Prozeß wird mit Core Dump beendet
• Termination, der Prozeß wird direkt beendet
• Continue, die Prozeß wird wieder ausgeführt, wenn er angehalten war, ansonsten wird's ignoriert
• Stop, der Prozeß wird angehalten
• Ignore, das Signal wird ignoriert

Wenn ein Signalhandler für ein Signal registriert wurde, dann hängt das vom Handler ab was passieren wird. Und für diesen Fall, daß der Prozeß eigene Handler installieren will, gibt es so viele verschiedene Signale.

 

[ilame]

Nicht zu vergessen - der vielleicht beste Editor der Welt - vim

 

[Hobbes_]

Nicht zu vergessen - der vielleicht beste Editor der Welt - vim

Ja, der ist cool

 

[Hilarious]

Nicht zu vergessen - der vielleicht beste Editor der Welt - vim

Ja, toller Editor, wenn die Kaffeetasse mit den ganzen vim-Befehlen nicht gerade in der Spülmaschine steckt. Dann helfen mir nur noch Panik, Entsetzen und zur Not pico.

 

[Tengu]

emacs kann aber mehr

Was auch sehr nett ist, ist

write

. Sitzt man in nem Linux Netzwerk, logt man sich per ssh beim Nachbarn ein, und per write kriegt er mal was zu Lesen.

Was ich noch suche ist der Befehl, wie man ne DVD/CD auswirft... unmount ist das nicht, oder?