Datenzuwach auf Server per Script protokollieren
Hallo zusammen,
ich habe zwar eine Teillösung für mein Problem gefunden
(Datenmenge auf Festplatte protokollieren)
bin damit aber nicht ganz zufrieden.
Da ich scripting-Anfänger bin jetzt meine Frage:
Ich will ebenfalls an meinem Server die Datenmenge protokollieren aber noch mehr ins Detail gehen.
Ich will jeden Ordner/Unterordner mit der dazugehörigen Größenangabe mit einem script einmal täglich auslesen lassen um den täglichen Datenzuwachs zu kontrollieren.
Gibt es hierfür eine Möglichkeit bzw. ein fertiges script?!?
Danke schon mal für eure Hilfe.
Gruß
ROYAL
ich habe zwar eine Teillösung für mein Problem gefunden
(Datenmenge auf Festplatte protokollieren)
bin damit aber nicht ganz zufrieden.
Da ich scripting-Anfänger bin jetzt meine Frage:
Ich will ebenfalls an meinem Server die Datenmenge protokollieren aber noch mehr ins Detail gehen.
Ich will jeden Ordner/Unterordner mit der dazugehörigen Größenangabe mit einem script einmal täglich auslesen lassen um den täglichen Datenzuwachs zu kontrollieren.
Gibt es hierfür eine Möglichkeit bzw. ein fertiges script?!?
Danke schon mal für eure Hilfe.
Gruß
ROYAL
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 43422
Url: https://administrator.de/forum/datenzuwach-auf-server-per-script-protokollieren-43422.html
Ausgedruckt am: 22.12.2024 um 17:12 Uhr
18 Kommentare
Neuester Kommentar
Hallo Royal!
Speichere die folgenden Zeilen als "FolderSizes.bat":
Rufe die Batchdatei wie folgt auf: FolderSizes "BasisVerzeichnis" "Protokolldatei", also zB
Sollten in einem Pfad oder Dateinamen Leerstellen enthalten sein (siehe Beispiel), müssen an Anfang und Ende des Namens Anführungszeichen gesetzt werden.
Schönheitsfehler: Datei- oder Verzeichnisnamen mit dem Bestandteil "Datei(en)" bringen das Ergebnis durcheinander ...
HTH
bastla
[Edit] Verzeichnisse in der Ausgabe unter Anführungszeichen gesetzt; Suchbegriffe ausgetauscht, Größenangaben "importfreundlicher" gemacht [/Edit]
Speichere die folgenden Zeilen als "FolderSizes.bat":
@echo off & setlocal
if exist %temp%\Tempsize.txt del %temp%\Tempsize.txt
set Write=0
for /f "tokens=2*" %%i in ('dir %1 /a /s /-c ^| findstr /i ":\ Datei(en)"') do Call :Combine "%%j"
findstr /v /c:"Bytes frei" %temp%\Tempsize.txt > %2
del %temp%\Tempsize.txt
goto :eof
:Combine
if %Write% EQU 0 (set Write=1) & (set Line=%1) & goto :eof
set Write=0
set Size=%~1
echo %Line%; %Size:~0,-6% >> %temp%\Tempsize.txt
goto :eof
Rufe die Batchdatei wie folgt auf: FolderSizes "BasisVerzeichnis" "Protokolldatei", also zB
FolderSizes D:\ "Z:\Logs der Verzeichnisgrößen\D-06-1031.txt"
Sollten in einem Pfad oder Dateinamen Leerstellen enthalten sein (siehe Beispiel), müssen an Anfang und Ende des Namens Anführungszeichen gesetzt werden.
Schönheitsfehler: Datei- oder Verzeichnisnamen mit dem Bestandteil "Datei(en)" bringen das Ergebnis durcheinander ...
HTH
bastla
[Edit] Verzeichnisse in der Ausgabe unter Anführungszeichen gesetzt; Suchbegriffe ausgetauscht, Größenangaben "importfreundlicher" gemacht [/Edit]
@bastla
Da der Batch ja ohnehin "nur" unter einer deutschsprachigen DIR-Ausgabe laufen würde (was aber in diesem Fall auch vollkommen okay ist), kannst Du den Findstr-Befehl doch von
...ändern auf...
Dieser Suchstring ist sicherlich wesentlich seltener in Verzeichnismanen enthalten.
Umgekehrt auch verschärfen würde ich die Ausschlussbedingung:
...in...
Grüße
Biber
P.S. Die Standard-Batch-Eröffnungsfloskel "@echo off & setlocal" ist Dir beim Copy & Paste verlorengegangen.
[Edit]
P.P.S. Die erste Anmerkung ist inzwischen hinfällig - bastla war schneller.. *g
[/Edit]
Da der Batch ja ohnehin "nur" unter einer deutschsprachigen DIR-Ausgabe laufen würde (was aber in diesem Fall auch vollkommen okay ist), kannst Du den Findstr-Befehl doch von
findstr /i "Verzeichnis Bytes"
findstr "Verzeichnis(se),"
Dieser Suchstring ist sicherlich wesentlich seltener in Verzeichnismanen enthalten.
Umgekehrt auch verschärfen würde ich die Ausschlussbedingung:
findstr /i /v "frei"...
findstr /v /c:"Bytes frei"...
Grüße
Biber
P.S. Die Standard-Batch-Eröffnungsfloskel "@echo off & setlocal" ist Dir beim Copy & Paste verlorengegangen.
[Edit]
P.P.S. Die erste Anmerkung ist inzwischen hinfällig - bastla war schneller.. *g
[/Edit]
Moin bastla,
Und der String "Verzeichnis" innerhalb eines Dateinamens kann wirklich vorkommen.
(z.B. Word-Datei "Inhaltsverzeichnis.doc").
Denke, der Schnipsel ist jetzt robust genug zum Alleine-Laufen-Können.
Is' ja nur ein Batch, kein Satellitensteuerungsprogramm...
Gruß
Biber
Spricht eigentlich etwas gegen die derzeitige Variante mit ":\" als Suchstring ..?
Nein, das passt genauso. Es sollte ja nur ein Suchstring sein, der "nach menschlichem Ermessen" nicht in Dateinamen auftreten kann.Und der String "Verzeichnis" innerhalb eines Dateinamens kann wirklich vorkommen.
(z.B. Word-Datei "Inhaltsverzeichnis.doc").
Denke, der Schnipsel ist jetzt robust genug zum Alleine-Laufen-Können.
Is' ja nur ein Batch, kein Satellitensteuerungsprogramm...
Gruß
Biber
Im RK gibt's "diruse.exe", aber manche Räder schreien danach, neu erfunden zu werden ...
Das stimmt... irgenwo in diesem Forum müsste auch eine DirSize.bat stehen, die auch letzten Endes nur ein DirUse-Billich-Clone ist.
::------snipp Dirsize.bat (Parameter1 Verzeichnisname [opt Par2: /R wie Rekursiv] /opt. par3 =Ebenen
@echo off & setlocal & Set DIRCMD=
IF /i [%2]==[/R] for /R "%~1" %%a in (.) do @%0 "%%a" %3
if not [%2]== Set /a "Level=%2+2"
if defined level for /f "delims=\ tokens=1,%level%" %%i in ("%~1") do if not [%%j]== goto :eof
set "space20= "
for /f "tokens=3" %%c in ('dir "%~1" /s ^2^>nul^| findstr /c:"Datei(en)" ') do set DirSize=%%c
if defined DirSize set "Dirsize=%space20%%Dirsize%"
if defined DirSize echo %DirSize:~-15% %~f1
::------snapp Dirsize.bat
Die habe allerdings die Zielrichtung, nur so-und-so-viele Unterebenen aufzudröseln, also so:
Output:
>dirsize %windir%\System32\wbem /R 4
36.531.418 C:\WINDOWS\system32\wbem
(=13:09:35 D:\temp=)
>dirsize %windir%\System32\wbem /R 6
36.531.418 C:\WINDOWS\system32\wbem
7.122.572 C:\WINDOWS\system32\wbem\AutoRecover
205.786 C:\WINDOWS\system32\wbem\Logs
73.689 C:\WINDOWS\system32\wbem\mof
0 C:\WINDOWS\system32\wbem\mof\bad
73.689 C:\WINDOWS\system32\wbem\mof\good
2.929 C:\WINDOWS\system32\wbem\Performance
10.607.952 C:\WINDOWS\system32\wbem\Repository
10.607.932 C:\WINDOWS\system32\wbem\Repository\FS
0 C:\WINDOWS\system32\wbem\snmp
66.942 C:\WINDOWS\system32\wbem\xml
Kann da bastla nur beipflichten: alles ist besser als als diese M$-DirUse.exe.
...außer der ForFiles.exe vielleicht...
Grüße
Biber
[Edit]
und sorry wegen der Editiererei, ....
Ich würde so etwas nie machen *heftigGestikulierendAllesAbstreitet*...aber man muss ja nicht jeden Thread zum "Rekordversuch" umfunktionieren..
Weiss gar nicht, von welchem Thread Du redest *lüüüchWieGedruckt*[/Edit]
@Biber
Im Sinne des alten Spruches "Iterieren ist menschlich, rekursieren ist göttlich" würde mir ja folgendes noch besser gefallen (auch, weil die Unsicherheiten durch das Filtern wegfallen):
Leider hat diese Variante gleich zwei Fehler:
Erstens werden immer die Gesamtwerte (also auch für alle Unterverzeichnisse) erfasst und zweitens (im Hinblick auf obigen Spruch): sie ist nicht auf meinem Mist gewachsen (jedenfalls nicht viel davon) ...
Wer sie trotzdem testen will:
Als "FolderSizes.vbs" speichern und wie folgt aufrufen:
Grüße
bastla
Im Sinne des alten Spruches "Iterieren ist menschlich, rekursieren ist göttlich" würde mir ja folgendes noch besser gefallen (auch, weil die Unsicherheiten durch das Filtern wegfallen):
sStartFolder = WScript.Arguments(0)
sResult = ""
Set fso = CreateObject("Scripting.FileSystemObject")
DoSubFolders fso.GetFolder(sStartFolder)
Wscript.Echo sResult
Sub DoSubFolders(oFolder)
For Each oSubFolder in oFolder.SubFolders
sResult = sResult & Chr(34) & oSubFolder.Path & Chr(34) & ";" & oSubFolder.Size & vbCrLF
DoSubFolders oSubFolder
Next
End Sub
Leider hat diese Variante gleich zwei Fehler:
Erstens werden immer die Gesamtwerte (also auch für alle Unterverzeichnisse) erfasst und zweitens (im Hinblick auf obigen Spruch): sie ist nicht auf meinem Mist gewachsen (jedenfalls nicht viel davon) ...
Wer sie trotzdem testen will:
Als "FolderSizes.vbs" speichern und wie folgt aufrufen:
cscript //nologo FolderSizes.vbs D:\ > "Z:\Logs der Verzeichnisgrößen\D-06-1031.txt"
Grüße
bastla
...an die Eleganz und spielerische Leichtigkeit von M$-DirUse.exe werden weder Du noch ich mit unseren jeweils knapp 10 zusammengeschredderten Zeilen jemals heranreichen können... *tröst*
...aber verglichen mit den "100 besten Batch-Tipps" aus der c't oder der Computerbild sind wir schon ganz gut, denke ich
...aber verglichen mit den "100 besten Batch-Tipps" aus der c't oder der Computerbild sind wir schon ganz gut, denke ich
Hallo,
du kann man vielleicht von hier nehmen:
http://freshmeat.net/projects/thinstallunixtools/
Wenn es so, wie unter UNI"X funktioniert (das von CYGWIN verhält sich auf jeden Fall so), dann erfolgt der Aufruf mit -b (für Ausgabe in Byte) und --max-depth=N (Anzahl der max. Verzeichnistiefe)
du -b --max-depth=4 "%WINDIR%\System32\wbem"
Viele Grüsse
-= Axel =-
du kann man vielleicht von hier nehmen:
http://freshmeat.net/projects/thinstallunixtools/
Wenn es so, wie unter UNI"X funktioniert (das von CYGWIN verhält sich auf jeden Fall so), dann erfolgt der Aufruf mit -b (für Ausgabe in Byte) und --max-depth=N (Anzahl der max. Verzeichnistiefe)
du -b --max-depth=4 "%WINDIR%\System32\wbem"
Viele Grüsse
-= Axel =-
Hallo Biber!
Grüße
bastla
...an die Eleganz und spielerische Leichtigkeit von M$-DirUse.exe werden weder Du noch ich mit unseren jeweils knapp 10 zusammengeschredderten Zeilen jemals heranreichen können... *tröst*
Damit kann ich leben ......aber verglichen mit den "100 besten Batch-Tipps" aus der c't oder der Computerbild sind wir schon ganz gut, denke ich
... und damit auch. Grüße
bastla
Moin Axel,
Da aber diese Unixtools (eben ohne Installation) in einer kleinen "bash-2.05b$"-Shell laufen,
sind 2 kleine Zugeständnisse an bash-Syntax nötig:
Der Backslash muss durch einen einfachen "/" ersetzt werden.
Und die Variable %windir% wird so wie geschrieben nicht als Variable erkannt
und deshalb auch nicht aufgelöst (=als Verzeichnisname gesucht und nicht gefunden).
Ergebnis sieht dann so aus:
Andere nach Windows portierte *NIX-Tools (die als kleine Windows-EXEn laufen), haben zum Teil den "--max-depth"-Parameter nicht, so zum Beispiel die auch ganz beliebten "GNU-Utils".
However, natürlich hast Du Recht, dass man/frau doch nicht jedes Rad -zig mal neu erfinden muss.
Aber das Gegenargument ist eben - wozu zwei Kisten mit Spezialwerkzeugen mit sich herumschleppen, wenn sich doch auch aus zwei Büroklammern und einem Stück Holz wundervolle Sachen basteln lassen?
Kennst Du MacGuyver?
bastla und ich wollten doch nur ein bisschen spielen...
Grüße
Biber
P.S. Eine weitere Krux bei vielen Utilties aus vielen Quellen ist bei den Zahlenwerten zu sehen. Ich habe die beiden du-Outputs parallel in zwei Windows-Fenstern erzeugt, relativ zeitgleich.
Du musst also bei jedem Programmierer noch mal nachfragen, wie er denn Byte in KiloByte et vice versa umrechnet...
du -b --max-depth=4 "%WINDIR%\System32\wbem"
Sinngemäß ja.Da aber diese Unixtools (eben ohne Installation) in einer kleinen "bash-2.05b$"-Shell laufen,
sind 2 kleine Zugeständnisse an bash-Syntax nötig:
Der Backslash muss durch einen einfachen "/" ersetzt werden.
Und die Variable %windir% wird so wie geschrieben nicht als Variable erkannt
und deshalb auch nicht aufgelöst (=als Verzeichnisname gesucht und nicht gefunden).
Ergebnis sieht dann so aus:
bash-2.05b$ du -b --max-depth=4 c:\windows\System32\wbem
du: `c:windowsSystem32wbem': No such file or directory
bash-2.05b$ du -b --max-depth=4 c:/windows/System32/wbem
7221248 c:/windows/System32/wbem/AutoRecover
196608 c:/windows/System32/wbem/Logs
0 c:/windows/System32/wbem/mof/bad
73728 c:/windows/System32/wbem/mof/good
73728 c:/windows/System32/wbem/mof
4096 c:/windows/System32/wbem/Performance
10996736 c:/windows/System32/wbem/Repository/FS
10997760 c:/windows/System32/wbem/Repository
0 c:/windows/System32/wbem/snmp
68608 c:/windows/System32/wbem/xml
37076992 c:/windows/System32/wbem
bash-2.05b$
Andere nach Windows portierte *NIX-Tools (die als kleine Windows-EXEn laufen), haben zum Teil den "--max-depth"-Parameter nicht, so zum Beispiel die auch ganz beliebten "GNU-Utils".
>du --version
du (GNU fileutils) 3.16
(=17:30:00 D:\temp=)
>du -b "%WINDIR%\System32\wbem"
7190944 C:\WINDOWS\System32\wbem/AutoRecover
190942 C:\WINDOWS\System32\wbem/Logs
0 C:\WINDOWS\System32\wbem/mof/bad
73689 C:\WINDOWS\System32\wbem/mof/good
73689 C:\WINDOWS\System32\wbem/mof
2929 C:\WINDOWS\System32\wbem/Performance
10993732 C:\WINDOWS\System32\wbem/Repository/FS
10993752 C:\WINDOWS\System32\wbem/Repository
0 C:\WINDOWS\System32\wbem/snmp
66942 C:\WINDOWS\System32\wbem/xml
36970746 C:\WINDOWS\System32\wbem
However, natürlich hast Du Recht, dass man/frau doch nicht jedes Rad -zig mal neu erfinden muss.
Aber das Gegenargument ist eben - wozu zwei Kisten mit Spezialwerkzeugen mit sich herumschleppen, wenn sich doch auch aus zwei Büroklammern und einem Stück Holz wundervolle Sachen basteln lassen?
Kennst Du MacGuyver?
bastla und ich wollten doch nur ein bisschen spielen...
Grüße
Biber
P.S. Eine weitere Krux bei vielen Utilties aus vielen Quellen ist bei den Zahlenwerten zu sehen. Ich habe die beiden du-Outputs parallel in zwei Windows-Fenstern erzeugt, relativ zeitgleich.
Du musst also bei jedem Programmierer noch mal nachfragen, wie er denn Byte in KiloByte et vice versa umrechnet...
Moinmoin,
seit wann müssen die Unixtools in der Bash laufen?
Wenn du du, sed und Frag-mich-nicht unter Windows starten willst, laufen alle Tools in der %COMSPEC%-Shell. Und die wird hoffentlich dein %WINDIR% noch kennen Man könnte zu Beginn den Pfad zu erweitern, dass man die Unixtools ohne Pfad ansprechen kann. Bei Tools die nicht allg. im Suchpfad sind (manchmal braucht man Konverter oder Packprogramme etc.), setze ich eine Variable zum Binary:
set BINDIR=c:\cygwin\bin
und anschliessend die Binaries z.B. auf
set ExeDU=%BINDIR%\du
Innerhalb des Skriptes wird dann nur %ExeDU% aufgerufen.
-- Backslashes:
Wenn ich
du %WINDIR%\SYSTEM32\DRIVERS
oder
du %WINDIR%/SYSTEM32/DRIVERS
aufrufe, funktioniert das "du" so, wie es soll (die Ausgabe mixt / und \ - aber es geht ... das könnte man aber filtern, wenn man es "sauber" bräuchte). Wohlgemerkt unter CMD.
In der Bash solltest du die Shell-Syntax beachten und Variablen mit ${Variablenname} ansprechen - WINDIR ist so auch in der Bash bekannt. Zur Shell-Syntax gehört auch, dass \ das nächstfolgende Zeichen maskiert.
Das \ und / zu verwechseln ist so ein typischer Microsoft-Fehler, der z.B. auch im IE zum Tragen kommt...
-- 2 Werkzeugkisten
Für den einen ist es Ballast - der andere braucht es. Ich kann mein Backup-Skript für Mysql unter LINUX unter Windows mit der CMD neu umsetzen oder aber in der Bash mit minimalen Anpassungen unter Windows laufen lassen.
Mancheiner, der kein Linux hat/ kennt/ braucht, hat natürlich ganz andere Voraussetzungen. Ich bediene mich daher gern aus mehreren Werkzeugkisten, wenn ich weiss, dass die Funktionalität schon da ist.
Was nicht heisst, dass ich "faul" bin - ich bastle auch gerne. Jawohl!
Jute Nacht denn! Und bis demnächst hier im Forum!!
Axel
seit wann müssen die Unixtools in der Bash laufen?
Wenn du du, sed und Frag-mich-nicht unter Windows starten willst, laufen alle Tools in der %COMSPEC%-Shell. Und die wird hoffentlich dein %WINDIR% noch kennen Man könnte zu Beginn den Pfad zu erweitern, dass man die Unixtools ohne Pfad ansprechen kann. Bei Tools die nicht allg. im Suchpfad sind (manchmal braucht man Konverter oder Packprogramme etc.), setze ich eine Variable zum Binary:
set BINDIR=c:\cygwin\bin
und anschliessend die Binaries z.B. auf
set ExeDU=%BINDIR%\du
Innerhalb des Skriptes wird dann nur %ExeDU% aufgerufen.
-- Backslashes:
Wenn ich
du %WINDIR%\SYSTEM32\DRIVERS
oder
du %WINDIR%/SYSTEM32/DRIVERS
aufrufe, funktioniert das "du" so, wie es soll (die Ausgabe mixt / und \ - aber es geht ... das könnte man aber filtern, wenn man es "sauber" bräuchte). Wohlgemerkt unter CMD.
In der Bash solltest du die Shell-Syntax beachten und Variablen mit ${Variablenname} ansprechen - WINDIR ist so auch in der Bash bekannt. Zur Shell-Syntax gehört auch, dass \ das nächstfolgende Zeichen maskiert.
Das \ und / zu verwechseln ist so ein typischer Microsoft-Fehler, der z.B. auch im IE zum Tragen kommt...
-- 2 Werkzeugkisten
Für den einen ist es Ballast - der andere braucht es. Ich kann mein Backup-Skript für Mysql unter LINUX unter Windows mit der CMD neu umsetzen oder aber in der Bash mit minimalen Anpassungen unter Windows laufen lassen.
Mancheiner, der kein Linux hat/ kennt/ braucht, hat natürlich ganz andere Voraussetzungen. Ich bediene mich daher gern aus mehreren Werkzeugkisten, wenn ich weiss, dass die Funktionalität schon da ist.
Was nicht heisst, dass ich "faul" bin - ich bastle auch gerne. Jawohl!
Jute Nacht denn! Und bis demnächst hier im Forum!!
Axel
@AxelHahn
Natürlich müssen die portiertien Unix-Tools nicht in einer bash laufen...
Aber unter dem oben angegebenen Link ist eine "Unix-In-One-Exe"-Variante, d.h. die Unix-Tools.exe emuliert dort, wo sie gestartet wird, einen virtuellen cygwin-Drive:
[Gestartet habe ich die Unix-Tools auf F:\\Administrator\AxelHahn.... cygwin habe ich nicht installiert]
Das war das, was ich oben meinte.
Natürlich kann ich den Sack Unix-Tools auspacken und zu den anderen "kleinen praktischen Helferlein" packen - wo für 800 Utilities Platz ist, werden auch 830 unterkommen...
Nichtsdestotrotz - es ist ein bisschen wie mit Küchenmessern.
Auch wenn Du zu Weihnachten wieder ganz viele Designer-Messer im Molybdänblock aus dem Tchibo-Shop geschenkt bekommst - Du wirst für Alltagsaufgaben wieder zu dem alten schartigen Ding greifen, mt dem Du schon dreimal umgezogen bist.
Aber die obigen Code-Schnipsel sollten auch nicht wirklich als ernstzunehme Alternative zu professionellen Standardtools angepriesen werden.
Grüße
Biber
Natürlich müssen die portiertien Unix-Tools nicht in einer bash laufen...
Aber unter dem oben angegebenen Link ist eine "Unix-In-One-Exe"-Variante, d.h. die Unix-Tools.exe emuliert dort, wo sie gestartet wird, einen virtuellen cygwin-Drive:
bash-2.05b$ ls -las *.exe
491 -rwxr-xr-x 1 44836 Domain U 502784 Jul 29 2002 bash.exe
17 -rwxr-xr-x 1 44836 Domain U 17408 Feb 20 2002 cat.exe
76 -rwxr-xr-x 1 44836 Domain U 77312 Jun 15 2001 cp.exe
39 -rwxr-xr-x 1 44836 Domain U 39936 Jun 15 2001 df.exe
38 -rwxr-xr-x 1 44836 Domain U 38912 Jun 15 2001 du.exe
77 -rwxr-xr-x 1 44836 Domain U 78848 May 20 2002 find.exe
58 -rwxr-xr-x 1 44836 Domain U 59392 Aug 4 2002 gzip.exe
74 -rwxr-xr-x 1 44836 Domain U 75776 Jan 18 2000 less.exe
67 -rwxr-xr-x 1 44836 Domain U 68608 Jun 15 2001 ls.exe
30 -rwxr-xr-x 1 44836 Domain U 30720 Jun 15 2001 mkdir.exe
82 -rwxr-xr-x 1 44836 Domain U 83968 Jun 15 2001 mv.exe
18 -rwxr-xr-x 1 44836 Domain U 18432 Jul 6 2002 ps.exe
64 -rwxr-xr-x 1 44836 Domain U 65024 Jun 15 2001 rm.exe
25 -rwxr-xr-x 1 44836 Domain U 25088 Jun 15 2001 rmdir.exe
181 -rwxr-xr-x 1 44836 Domain U 184363 Aug 5 2002 unix_tools.exe
bash-2.05b$ pwd
<b>/cygdrive/f/Administrator/AxelHahn</b>
bash-2.05b$
Das war das, was ich oben meinte.
Natürlich kann ich den Sack Unix-Tools auspacken und zu den anderen "kleinen praktischen Helferlein" packen - wo für 800 Utilities Platz ist, werden auch 830 unterkommen...
Nichtsdestotrotz - es ist ein bisschen wie mit Küchenmessern.
Auch wenn Du zu Weihnachten wieder ganz viele Designer-Messer im Molybdänblock aus dem Tchibo-Shop geschenkt bekommst - Du wirst für Alltagsaufgaben wieder zu dem alten schartigen Ding greifen, mt dem Du schon dreimal umgezogen bist.
Aber die obigen Code-Schnipsel sollten auch nicht wirklich als ernstzunehme Alternative zu professionellen Standardtools angepriesen werden.
Grüße
Biber