File-Duplikate in einem Verzeichnis löschen und symbolisch verlinken.
- Ersteller tobiasbeil
- Erstellt am
tobiasbeil
Bitchass User
TCM schrieb:
jein,
auf AIX mit bash/ksh/sh gehts,
auf cygwin gehts in sh nicht.
ich starte das script immer mit "sh rmdupl.sh"
wie gesagt, jein.
EDIT:
update/bugfix!!!
das script verhällt sich komisch, wenn die files mit einem Punkt anfangen,
zum glück waren nur 2 zeilen betroffen, ich habe schon befürchtet ich müsste
sehr viel code umstellen. ganz dummer fehler, als windows mensch übersieht
man gerne solche fälle....
gefixter code:
EDIT2:
und weil das ganze kürzer und schneller geht, kompletter designwechsel:
gefixter gefixter code:
Code:
siehe ersten Beitrag für neueste Version.
Zuletzt bearbeitet:
tobiasbeil
Bitchass User
Mir ist ein bug aufgefallen, sodass ichleider das script etwas langsamer und komplizierter machen muss.
In der Theorie ist alles ok und das script ist logisch.
in der praxis sagt er bei wirklich vielen dateien "environment or parameterlist too long".
Also muss ich es fehlertoleranter machen.
bin gerade dabei...
In der Theorie ist alles ok und das script ist logisch.
in der praxis sagt er bei wirklich vielen dateien "environment or parameterlist too long".
Also muss ich es fehlertoleranter machen.
bin gerade dabei...
tobiasbeil
Bitchass User
jein,
das kommt immer, wenn ich cat *.md5 usw. schreibe.
ich änder das so um, dass immer nach eine ganz bestimmten
datei gesucht wird, also for filename in $(cat filenames) do cat $filename.md5 ... usw.
ist noch preziser. aber dein beipsiel ist auch net schlecht, werd ich mir
anschauen, vielleicht ist es schneller als meine fors, while hab ich mir nur
noch net angeschaut. man(n) fürchtet was man(n) nicht kennt...
edit:
ich vermute aber, dass wenn das "environment bzw. die parameter list" trotzdem
zu gross ist, mir das mit dem while nichts hilft, ausser dass es kürzer zum tippen ist.
fehlerteufel ist dann der "*", nicht die frage ob for oder while.
(habs aber nicht getestet)
das kommt immer, wenn ich cat *.md5 usw. schreibe.
ich änder das so um, dass immer nach eine ganz bestimmten
datei gesucht wird, also for filename in $(cat filenames) do cat $filename.md5 ... usw.
ist noch preziser. aber dein beipsiel ist auch net schlecht, werd ich mir
anschauen, vielleicht ist es schneller als meine fors, while hab ich mir nur
noch net angeschaut. man(n) fürchtet was man(n) nicht kennt...
edit:
ich vermute aber, dass wenn das "environment bzw. die parameter list" trotzdem
zu gross ist, mir das mit dem while nichts hilft, ausser dass es kürzer zum tippen ist.
fehlerteufel ist dann der "*", nicht die frage ob for oder while.
(habs aber nicht getestet)
Zuletzt bearbeitet:
tobiasbeil
Bitchass User
UPDATE:
der code wurde upgedated.
(bezüglich des "bugs", siehe 2 posts weiter oben...)
siehe ersten post im thread.
der code wurde upgedated.
(bezüglich des "bugs", siehe 2 posts weiter oben...)
siehe ersten post im thread.
also jetzt nochmal kritik:
ich finde, dass du viel zu viel zeit mit dem script verschwendest. durch die komplexitaet stoesst du mittlerweile auf probleme (doppelte ausfuehrung -> mktemp -> kein mktemp unter aix, "parameter list too long" etc. etc.), die mit dem eigentlichen problem ueberhaupt nichts mehr zu tun haben und die nur entstehen, weil du unbedingt in /bin/sh bleiben willst.
shell ist wunderbar fuer one-shot hacks, bei denen man auf anhieb die loesung sieht. siehe mein script, welches einfach blind hasht und dadurch recht einfach zu erdenken und umzusetzen war.
schon allein bei der zusaetzlichen forderung, auf dateigroessen zu achten und nur gleichgrosse dateien zu hashen, habe ich gemerkt, dass die umsetzung komplexer wird, als ich mir in einer minute ausdenken kann. das zeigt mir, dass ich entweder bei der durchschaubaren aber unoptimierten loesung bleiben sollte, oder auf einen interpreter umsteigen muss, welcher zb assoziative arrays kennt. damit waere das ganze ein klacks. schon ein umstieg auf die zsh _fuer dieses spezifische problem_ waere einfacher, als so weiterzumachen. zsh sollte eh ueberall installiert sein als interaktive shell
dein problem ist eine schraube, und du willst unbedingt den hammer nehmen.
ich weiss, dass man eine sache nicht aufgeben will, wenn man erst mal einen bestimmten aufwand reingesteckt hat. aber genau das ist es. wenn du mal schnell was zusammenhackst, dann sorge dafuer, dass du so wenig zeit wie moeglich reinsteckst, damit du nicht damit zusammenwaechst. wenn du merkst, dass sich eine gewisse komplexitaet einschleicht, dann schau, ob du das tool wechseln kannst.
das ganze wird langsam kontraproduktiv, weil es verhindert, dass du ein gefuehl fuer elegante und saubere loesungen kriegst imho. der lerneffekt wird behindert.
du sagst, dass du installationsdateien "saeubern" willst. ich gehe mal davon aus, dass sich gerade solche dateien nicht alle nase lang aendern. vor dem hintergrund waere es mir ehrlich gesagt piepegal, ob ich blind einmal alle dateien durchhashe, wenn ich dafuer nur eine minute brauch, um 13 zeilen shell zusammenzukratzen. ansonsten wuerde ich mir 5 minuten nehmen und auf zsh wechseln oder so. aber wenn ich von weitem auf das script im ersten post schaue, dann weiss ich, dass da schon irgendwas aus dem ruder laeuft.
ich finde, dass du viel zu viel zeit mit dem script verschwendest. durch die komplexitaet stoesst du mittlerweile auf probleme (doppelte ausfuehrung -> mktemp -> kein mktemp unter aix, "parameter list too long" etc. etc.), die mit dem eigentlichen problem ueberhaupt nichts mehr zu tun haben und die nur entstehen, weil du unbedingt in /bin/sh bleiben willst.
shell ist wunderbar fuer one-shot hacks, bei denen man auf anhieb die loesung sieht. siehe mein script, welches einfach blind hasht und dadurch recht einfach zu erdenken und umzusetzen war.
schon allein bei der zusaetzlichen forderung, auf dateigroessen zu achten und nur gleichgrosse dateien zu hashen, habe ich gemerkt, dass die umsetzung komplexer wird, als ich mir in einer minute ausdenken kann. das zeigt mir, dass ich entweder bei der durchschaubaren aber unoptimierten loesung bleiben sollte, oder auf einen interpreter umsteigen muss, welcher zb assoziative arrays kennt. damit waere das ganze ein klacks. schon ein umstieg auf die zsh _fuer dieses spezifische problem_ waere einfacher, als so weiterzumachen. zsh sollte eh ueberall installiert sein als interaktive shell
dein problem ist eine schraube, und du willst unbedingt den hammer nehmen.
ich weiss, dass man eine sache nicht aufgeben will, wenn man erst mal einen bestimmten aufwand reingesteckt hat. aber genau das ist es. wenn du mal schnell was zusammenhackst, dann sorge dafuer, dass du so wenig zeit wie moeglich reinsteckst, damit du nicht damit zusammenwaechst. wenn du merkst, dass sich eine gewisse komplexitaet einschleicht, dann schau, ob du das tool wechseln kannst.
das ganze wird langsam kontraproduktiv, weil es verhindert, dass du ein gefuehl fuer elegante und saubere loesungen kriegst imho. der lerneffekt wird behindert.
du sagst, dass du installationsdateien "saeubern" willst. ich gehe mal davon aus, dass sich gerade solche dateien nicht alle nase lang aendern. vor dem hintergrund waere es mir ehrlich gesagt piepegal, ob ich blind einmal alle dateien durchhashe, wenn ich dafuer nur eine minute brauch, um 13 zeilen shell zusammenzukratzen. ansonsten wuerde ich mir 5 minuten nehmen und auf zsh wechseln oder so. aber wenn ich von weitem auf das script im ersten post schaue, dann weiss ich, dass da schon irgendwas aus dem ruder laeuft.
tobiasbeil
Bitchass User
vielleicht denke ich ja wirklich zu kompliziert,
aber wozu studiere ich informatik ? komplexe
algorythmen erfordern komplexen code.
"einfache" aufgaben können mit einfachem code auskommen.
es war explizit meine (eigene) anforderung, dass der nicht
blind hashed, denn selbst in meinen minimal-testumgebungen teste ich
mit "nur" 2 ordner (zusammen 2.7 gig gross) und das dauert
42 min. Aber ich wills ja für meinen (reellen) einsatz primär korrekt
und fehlertollerant kriegen, und sekundär für alle anderen einsätze,
also nicht nur für AIX sondern auch für Linux, aber eben nur sekundär.
danke für deine faulheits-empfehlungen,
aber im Praktikum (in dem ich mich befinde) sollte man was lernen.
Und meine kollegen werden es mir danken, und mir schadet es nicht
wenn ich nebenbei nen mörder-script schreibe.
wenn alle so denken würden wie du gäbe es IT Stillstand.
kryptoanalyse wäre ein fremdwort,
brute force lässt sich in 5 Zeilen programmieren...
ich könnte ewig so weitermachen...
ausserdem bin ich so faul wegem einem einsatz
nicht gleich ne neue shell kennenzulernen, nur
wegen einem script.
du lernst ja auch nicht ne neue Programmiersprache
nur weil du mit einem einzigem feature liebäugelst.
aber wozu studiere ich informatik ? komplexe
algorythmen erfordern komplexen code.
"einfache" aufgaben können mit einfachem code auskommen.
es war explizit meine (eigene) anforderung, dass der nicht
blind hashed, denn selbst in meinen minimal-testumgebungen teste ich
mit "nur" 2 ordner (zusammen 2.7 gig gross) und das dauert
42 min. Aber ich wills ja für meinen (reellen) einsatz primär korrekt
und fehlertollerant kriegen, und sekundär für alle anderen einsätze,
also nicht nur für AIX sondern auch für Linux, aber eben nur sekundär.
danke für deine faulheits-empfehlungen,
aber im Praktikum (in dem ich mich befinde) sollte man was lernen.
Und meine kollegen werden es mir danken, und mir schadet es nicht
wenn ich nebenbei nen mörder-script schreibe.
wenn alle so denken würden wie du gäbe es IT Stillstand.
kryptoanalyse wäre ein fremdwort,
brute force lässt sich in 5 Zeilen programmieren...
ich könnte ewig so weitermachen...
ausserdem bin ich so faul wegem einem einsatz
nicht gleich ne neue shell kennenzulernen, nur
wegen einem script.
du lernst ja auch nicht ne neue Programmiersprache
nur weil du mit einem einzigem feature liebäugelst.
tobiasbeil
Bitchass User
ich habe mittlerweile sogar erfahren,
wie man das script zu einem zsh script konvertieren kann.
einfach in die erste zeile:
# emulate sh
eifügen und per zsh script.zsh starten.
wie man das script zu einem zsh script konvertieren kann.
einfach in die erste zeile:
# emulate sh
eifügen und per zsh script.zsh starten.
Vielen Dank, dass Ihr mich ignoriert habt *sich den Fussabdruck vom Schlips wischend*
Vielleicht war mein Post nicht informativ genug, aber hat sich jemand mal die Mühe gemacht, mein C-Programm anzuschauen? Es ging mir nicht um Eitelkeiten, sondern um einen konstruktiven Beitrag.
Zu den philosophischen Fragen:
Shell == q(uick)&d(irty)
'richtige Sprachen' == Arbeitstiere für komplexere Aufgaben.
Die Aufgabe mit den File-Duplikaten ist unter realen Bedingungen (Nicht-Praktikum) durchaus eine kompliziertere Aufgabe z.B. Mehrbenutzer-Betrieb, Rechte, aktuelle Zugriffe, Ausführungsgeschwindigkeit, Häufigkeit des Aufrufs, Ressourcen-Verbrauch (warum Temp-Dateien), etc. Ein weites Feld. ;-)
Gruß, Sascha
Vielleicht war mein Post nicht informativ genug, aber hat sich jemand mal die Mühe gemacht, mein C-Programm anzuschauen? Es ging mir nicht um Eitelkeiten, sondern um einen konstruktiven Beitrag.
Zu den philosophischen Fragen:
Shell == q(uick)&d(irty)
'richtige Sprachen' == Arbeitstiere für komplexere Aufgaben.
Die Aufgabe mit den File-Duplikaten ist unter realen Bedingungen (Nicht-Praktikum) durchaus eine kompliziertere Aufgabe z.B. Mehrbenutzer-Betrieb, Rechte, aktuelle Zugriffe, Ausführungsgeschwindigkeit, Häufigkeit des Aufrufs, Ressourcen-Verbrauch (warum Temp-Dateien), etc. Ein weites Feld. ;-)
Gruß, Sascha
tobiasbeil
Bitchass User
Was ? Wer bist du denn ?
Im Ernst:
Ich kann noch nicht so gut C.
Ich habe nur nen Primzahlprog und ein Mann Wolf Ziege Kohl Prog geschrieben in C.
Deswegen kann ich dazu nichts intelligentes sagen,
wie auch sonst nicht.
Im Ernst:
Ich kann noch nicht so gut C.
Ich habe nur nen Primzahlprog und ein Mann Wolf Ziege Kohl Prog geschrieben in C.
Deswegen kann ich dazu nichts intelligentes sagen,
wie auch sonst nicht.
