Effektiver ist es jedoch, einen einzigen Befehl auszuführen und der global, also auch rekursiv, den String sucht und ersetzt.

find . -type f | xargs sed -i .bak ‘s/alterString/neuerString/g’

Dieser Befehl durchsucht jede Datei in dem Verzeichnis. Sie wird zunächst geöffnet, dann wird nach “alterString” gesucht. Wird dieser gefunden, wird ein Backup der Datei *.bak erstellt und erst dann wir der bisherige String durch “neuerString” ersetzt.

Ist man sich der Sache sicher, was man tut, kann man z.B. die Backup-Option ausschalten

find . -type f | xargs sed -i ‘s/alterString/neuerString/g’

Das funktioniert zwar, aber es gibt gravierende Nachteile: Es wird jede Datei berührt, unabhängig davon ob der gewünschte String vorkommt, und es gibt einen Konflikt mit dem Schrägstrich bei Pfadangaben. Dieser muss dann mit “\” maskiert werden. Für die Maskierung sähe der Befehl nun so aus:

find . -type f | xargs sed -i ‘s/alter\/String/neuer\/String/g’

Damit das System nicht unnötig belastet wird und nicht jede Datei einzeln berührt wird, muss der Befehl um eine weitere Option erweitert werden.

Ein Beispiel:

$ scp /folder/tranfer-file-name username@remote.host.net:
   /folder/destination-file-name

Das Passwort des Users auf dem Remote-Rechner wird nach Bestätigen des Befehls angefordert. Danach muss man warten, bis die Übertragung der Datei abgeschlossen ist. Für kleine Datenmengen ist das okay, aber bei größeren Mengen, sagen wir beispielsweise 40 GB, oder bei instabilem Netzwerk, ist es lästig, die Verbindung zum Quellrechner aufrecht zu halten (was beim instabilen Netz schon fast zur Verzweiflung führt). Um dem aus dem Weg zu gehen, kann SCP als Hintergrundprozess ausgeführt werden:

$ scp /folder/tranfer-file-name username@remote.host.net:
   /folder/destination-file-name > /dev/null 2>&1

Auch in diesem Fall wird das Passwort des Users auf dem Remote-Rechner angefordert; nach dessen Eingabe und der Bestätigung durch Enter, muss der Prozess mit STRG + Z unterbrochen werden. SCP liefert daraufhin folgenden Output:

[1]+  Stopped        scp /folder/tranfer-file-name username@remote.host.net:
   /folder/destination-file-name > /dev/null 2>&1

Damit der SCP-Prozess im Hintergrund fortgesetzt wird, muss folgender Befehl eingegeben werden:

$ bg

Diesmal sieht der Output von SCP so aus:

[1]+ scp /folder/tranfer-file-name username@remote.host.net:
   /folder/destination-file-name > /dev/null 2>&1 &

Mit Eingabe von

$ jobs

kann kontrolliert werden, ob der Hintergrundprozess (noch) läuft. Wenn er noch läuft, sieht das Ergebnis so aus:

[1]+  Running        scp /folder/tranfer-file-name username@remote.host.net:
   /folder/destination-file-name > /dev/null 2>&1 &

Um den Prozess wieder vordergründig ausführen zu lassen, genügt die Eingabe von

$ fg

C:\>del C:\oracle\ora92\network\log\listener.log
C:\oracle\ora92\network\log\listener.log
Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird.

Viele DBAs stoppen an dieser Stelle einfach den TNS Listener Prozess, benennen die Datei um oder entfernen sie; danach starten sie den TNS Listener Prozess wieder. Das führt aber zu Verbindungsfehlern bei Benutzern, die in dieser Zeit versuchen, auf die Datenbank zuzugreifen.
Selbst unter Unix kann es zu Problemen kommen, wenn versucht wird, die Datei listener.log umzubenennen, während der TNS Listener Prozess aktiv ist. Wie Windows so blockiert auch Unix den File-Handler. Unter Unix kann allerdings die Datei gelöscht werden, aber ORACLE wird beim nächsten Versuch, die Datei zu beschreiben, diese nicht neu anlegen. Der TNS Listener muss gestoppt und neu gestartet werden, damit die Datei listener.log neu angelegt werden kann.

Hier ist für Windows und Unix nun eine Lösung, wie die Datei listener.log umbenannt oder gelöscht werden kann, ohne den TNS Listener zu stoppen und neu zu starten: