Script-hajer søges :-)

jeg er ingen haj men jeg vil tro du kan bruge



sort -t\n





har du ikke problemer med spaces i din



cp -pT $local_file $remote_file





det ville jeg i hvert fald have gættet på

den svære men korrecte måde ville værre at rode med finds -print0 eller -fprint0 output formatering, den slags er jeg for doven til så her er et sed eksempel istedet.





find |sed 's/ /\\ /g' |xargs stat



jeg bruger en simpel søgning of piper til stat via xargs for lige at teste.

i dit exempel burde det virke hcis du ersttatter $(find ./ -iname "$fn") med $(find ./ -iname "$fn" | sed 's/ /\\ /g' )



Håber det hjælp dig nærmere til en løsning.

#0: Det hele fungerer perfekt, bortset fra at filnavne med mellemrum bliver klippet før mellemrummet i $missing_log.



Jeg er ikke vild med kombinationen af "for" og navne med mellemrum. Du må have kildet den under hagen (med IFS?) for at få ovenstående til at virke, eller?



Jeg tror while er bedre til formålet for den kører på linjeskift (ligesom output af find).





missing_log="missing.log"

touch $missing_log

rm $missing_log



find -iname "*.txt" | while read localFile

do

remoteFile="../remotedir/$localFile"

( [ ! -e "$remoteFile" ] && echo "$remoteFile does not exist" || echo "$remoteFile DOES exist" ) >> $missing_log

done



Jeres input er værdsat og vil blive studeret nærmere.



Selv om det er lykkedes mig at lave nogle nyttige scripts i tidens løb, er jeg bestemt ingen ørn til bash scripting, som I sikkert kan se, og finder ofte syntaksen kontraintuitiv eller inkonsistent.



Som regel undgår jeg mellemrum i filnavne, men de sniger sig ind af og til alligevel, og i et script, der skal tage backup eller kontrollere, at den er korrekt, må man jo også tage højde for den mulighed.



#1:

cp -pT $local_file $remote_file

ville sikkert have givet problemer, som du skriver, med da jeg kørte alle tests med

L_only="true" # log only

blev cp aldrig udført.

#4:

Selv om det er lykkedes mig at lave nogle nyttige scripts i tidens løb, er jeg bestemt ingen ørn til bash scripting, som I sikkert kan se, og finder ofte syntaksen kontraintuitiv eller inkonsistent.



du er ikke den eneste, Bash har sine problemer som script sprog især omkring whitespace hvor folk ofte tyr til sed, perl eller awk oneliners for fixe problemerne, og subshell er et kapitel for sig, det er nogle gange halvsvært self for erfarne brugere at holde snor i bash, men det giver dig en muglighed for at konvertere manuelt workflow til script uden at skifte syntax, eller lære formel programering.



#3: Jeg er ikke vild med kombinationen af "for" og navne med mellemrum. Du må have kildet den under hagen (med IFS?) for at få ovenstående til at virke, eller?

Det løser vel ikke rod problemet at mv cp, cat, echo, osv opdatter whitespace som seperator?

#5: Det løser vel ikke rod problemet at mv cp, cat, echo, osv opdatter whitespace som seperator?



echo er ligeglad med white-spaces - den skriver, det den bliver bedt om uanset whitespaces.



Derfor: Punkt 1 var at få (for/while) loop'en til at fungere. Hvis for-loopen ikke fungerer forklarer det jo også hvorfor echo til fil ikke fungerede for filnavne med mellemrum (som skrevet i #0).



I min erfaring kan man enten escape whitespaces eller omklamre hele stien med anførselstegn. Jeg foretrækker det sidste fordi den også er resisitent overfor andre specialkarakterer i filnavne - fx '-' ("minus").



Flg. har jeg lige testet og det virker for filer med mellemrum inkl. cp kommando:





missing_log="missing.log"

touch $missing_log

rm $missing_log

find -iname "*.txt" | while read localFile

do

remoteFile="../remotedir/$localFile"

( [ ! -e "$remoteFile" ] && echo "$remoteFile does not exist - copying.." && cp "$localFile" "$remoteFile" ) >> $missing_log



done



Tak igen for jeres kommentarer. Jeg vil, som tidligere nævnt, studere jeres guldkorn med interesse.

#5:

Tak for opbakningen. Det er rart at vide, at man ikke er den eneste.

Muligheden for at automatisere et ellers manuelt workflow er jo det centrale, men jeg har da sommetider overvejet, om ikke det var værd at prøve med et andet sprog.



#6:

Ja, jeg havde også tænkt på at prøve med anførselstegn, som jeg i andre sammenhænge har brugt flittigt og med held, men det er nok blevet ved tanken, eller også har jeg ikke testet det godt nok. Tak for at minde mig om det.



I øvrigt forstår jeg ikke meningen med



touch $missing_log

rm $missing_log



#7: Ja, jeg havde også tænkt på at prøve med anførselstegn, som jeg i andre sammenhænge har brugt flittigt og med held, men det er nok blevet ved tanken, eller også har jeg ikke testet det godt nok. Tak for at minde mig om det.



Det er beskrevet rigtig mange steder, og som nævnt fyldt med problematikker. Jeg skal gerne indrømme at jeg ikke gider selv.



https://www.google.dk/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF…



#7: $missing



Så vidt jeg husker, at finde mapper/filer uden specificeret fil type i bash.



# remove old logs

if [ -f "$missing_log" ]; then

rm $missing_log

fi



Måske er det nemmere at løse det overordnede problem i f.eks. Python?

#7: I øvrigt forstår jeg ikke meningen med..





touch $missing_log

rm $missing_log





Det var bare en hurtig (og doven) måde at slette den gamle log. Problemet var at rm giver en fejl, hvis filen ikke eksisterer. "touch" sikrer at der er en fil med det pågældende navn. Jeg kunne også have brugt rm -f. Eller tjekket for filens eksistens, som frogmaster gør i den bid kode, som han har snuppet fra Google (og lader som om han lige hiver frem fra hukommelsen - uden rigtig at forstå den) i #8.

#9: (og lader som om han lige hiver frem fra hukommelsen - uden rigtig at forstå den)



Det er korrekt jeg ikke husker bash i detaljer, og at jeg søger på løsninger før jeg svarer. Også at jeg kan tage fejl, selv hvor jeg har min ekspertiser, men prøv for fanden at lade være med at opføre dig som en fucking psykopat.

Beklager afsporing af tråd, mich :(



#10: Også at jeg kan tage fejl, selv hvor jeg har min ekspertiser, men prøv for fanden at lade være med at opføre dig som en fucking psykopat.



Wow. Hvem er mest mentalt belastet:

* ham, der, på et forum, hvor man optræder anonymt, prøver at lade som om han ved en helt masse om et emne, hvor han ikke aner en tøddel

* eller ham, der påpeger det?



Der er ikke noget i vejen med at google-søge og kopiere svaret, men lad nu vær med at forsøge at tillægge dine svar et troværdighedsniveau, som de ikke kan bære. Hvis du finder et svar, baseret på nogle termer, der tilfældigvis rammer samme emne, så skriv det for hulen da!



Skriv: "jeg ved ikke meget om emnet, men måske du kan bruge disse søge-resultater". Lad vær med at finde på en dækhistorie om at "du måske husker forkert, men det er vist noget i retning af....". Et "-f" check i bash har jo intet med at finde en fil at gøre. At du kan søge på "$missing_log" på google og så kopiere første forekomst: https://github.com/wyuka/kdesdk/blob/master/scripts/qt4/icons-kde3tokde… , der intet har med at finde filer at gøre, er jo for langt ude! Til din orientering: "$missing_log" er et variabelnavn (et vilkårligt valgt navn) og at du finder den på google er en ren tilfældighed, der intet har med mich's forespørgsel at gøre.



Det er problematisk, at du svarer på ting, du ikke ved noget om og samtidig forsøger at gøre dem troværdige, ved at lade som om du er ekspert. Du gør det igen og igen - så lad da vær!



Det næste bliver at du finder en løsning, der - mod forventning - sletter harddisken og gengiver den til en intetanende bruger, som kopierer den i den tro at du ved noget om det.

#11: Wow. Hvem er mest mentalt belastet



Det er du uden tvivl. Denne gang høster du en klage for din opførsel.



#11: Det næste bliver at du finder en løsning, der - mod forventning - sletter harddisken og gengiver den til en intetanende bruger, som kopierer den i den tro at du ved noget om det.



Du har før optrådt psykopatisk. Nu stopper det ...

#12: Denne gang høster du en klage for din opførsel



Tak. Passende med en klage på denne tråd. Dine udfald er langt under sidens niveau.



#12: Du har før optrådt psykopatisk



Så nu er du også ekspert i psykologi? Du er bekymrende fascineret af psykopatbegrebet. Jeg kan kun gisne om hvorfor.



#12: Nu stopper det



Sålænge jeg har adgang til denne side, har jeg tænkt mig at påtale når dine svar er latterlige - det skylder jeg de evt. uerfarnce brugere, der ikke selv kan vurdere det. Uanset, hvor meget du kommer til at hade det og hvilke ting, du kalder mig.

Du skal bare tale ordentligt. Men klagen er sendt. Jeg har ingen interesse i at gøre mere ud af det, og jeg respektere din viden, men der er grænser for hvad du kan tillade dig at knalde af. Du skal ikke fyre det pis af igen ...

#14: Du skal ikke fyre det pis af igen



Igen: uanset, hvor grimt du taler, har du absolut ingen indflydelse på hvad jeg kommenterer.

Jeg har ingen interesse i hvad du kommenterer, udover hvor jeg er involveret, men gør du det, så skal du fame tale i en acceptabel tone. Vi behøver ikke være enige, og har du ret, så vil jeg ende med at give dig ret, som jeg vil med alle andre.



Her går du bare over grænsen.

Okay, stop venligst her!



I er begge kommet for langt ud. Frogmaster erkender et forbehold for koden ved at skrive "så vidt jeg husker" - om så hukommelsen er støttet af en googlesøgning er så noget andet som i mine øjne ikke er specielt relevant. Der er tit ting som er meget diffuse i min erindring som jeg derfor googler, men derfor kan det jo godt udgå fra hukommelsen. Frogmaster har hjulpet rigtigt mange mennesker herinde, om det sker via Google er irrelevant i mine øjne.



På den anden side er det ikke i orden at kalde en anden bruger"fucking psykopat". Det er ærligt talt under lavmålet og tjener intet formål. Der er intet psykopatisk i mrbrown79's opførsel iflg. min forståelse af diagnosen, men jeg lader nu psykiatere om at diagnosticere psykiske sygdomme. Man kan måske kalde det dårlig stil og manglende respekt at skrive som i #9, men lad os holde os væk fra kliniske diagnoser.



Tilbage til emnet, tak!

Hvad med en dry rsync? (kan evt. Googles :-) )

rsync er fantastisk godt til backup, men som jeg forstår #0 så er det ikke sagen her. Han vil gerne tjekke om filer på den lokale maskine findes på backupdrevene, men det jo være i en hel anden mappestruktur, og så dur rsync jo ikke.



Men ellers er det da rigtigt at en rsync dry run er godt til at finde forskelle imellem mappestrukturer. Her gætter jeg bare på at strukturen ikke er ens.

#6:

echo er ligeglad med white-spaces - den skriver, det den bliver bedt om uanset whitespaces.



Derfor: Punkt 1 var at få (for/while) loop'en til at fungere. Hvis for-loopen ikke fungerer forklarer det jo også hvorfor echo til fil ikke fungerede for filnavne med mellemrum (som skrevet i #0).



I min erfaring kan man enten escape whitespaces eller omklamre hele stien med anførselstegn. Jeg foretrækker det sidste fordi den også er resisitent overfor andre specialkarakterer i filnavne - fx '-' ("minus").



Jeg er lidt halvparanoid om altid at escape whitespaces men mest fordi jeg har brændt nællerne på det ofte nok. Og oftenst har løsningen for mig været regex(min go to maslow's hammer)



Interesant iøvrigt at while og for bruger forskellige item seperatorer den vil jeg huske til fremtidig brug.



edit: pga forumets whitespace problem ;-)