rm -i in script werkt niet correct

[Boudewijn]

hoihoi

En we zijn weer wat raars (of mijn onkunde ) in bash tegengekomen :

code:

#!/bin/bash
# Date: 12-01-2011
# Purpose: remove the files named in "files". "files" should be a plaintext file in the same directory as the script. It expects input such as /data2/Apps/CVs/COU1/CV-262264.zip: Eicar-Test-Signature FOUND as lines


function removeFiles {
        a=0
        while read line
        do a=$(($a+1));
                # remove the virus type from the line so we only get the filename
                line=`echo "$line" |cut -d ':' -f 1`
                if [ -f "$line" ]
                then
                        echo "FILE EXISTS: $line"
                        rm -i "$line"
                else
                        echo "FILE DOES NOT EXIST: $line"
                fi
                #echo $line
                #echo $a;
        done < "files"
}

removeFiles

De dit script moet files verwijderen in deze vorm:
filename:virustype
En die wordt aangeleverd door een file met $x lines van dit formaat.

Dit script heb ik net geschreven, en gebruikt -i niet goed; hij pleurt de files rucksichtlos weg.
Erg bizar, maar de omgeving (klant, productiebak) is ook niet helemaal jofel:

# which rm
alias rm='rm -i'
        /bin/rm

Nu lees ik dat 2x -i gebruiken ook niet de bedoeling is, maar als ik puur rm in mijn script gebruik wordt er ook niet om bevestiging gevraagd.

Weet iemand waar dit aan kan liggen?
Het is een RHEL5.4 doos , met bash 3.2.25, en het script wordt gerund als root.

[Verwijderd]

Probeer eens "/bin/rm -i" ipv alleen rm.
Op die manier wordt de alias niet gebruikt en zou het wellicht goed moeten gaan.

[Aragnut]

Verwijderd schreef op woensdag 12 januari 2011 @ 11:39:
Probeer eens "/bin/rm -i" ipv alleen rm.
Op die manier wordt de alias niet gebruikt en zou het wellicht goed moeten gaan.

inderdaad in de alias verwijzen naar het absolute pad van rm. Overigens weet ik niet hoe gezond het is om een alias te maken met dezelfde naam als een executable dat in je PATH variabele staat. Uiteraard wil je dit om te beschermen tegen per ongeluk rm te gebruiken, maar als je erop vertrouwt, en je trapt het script een keer vanuit een andere user af (of cron) die niet de alias heeft dan sta je heel raar te kijken.

edit: wel een slordig script. Je overschrijft je eigen variabelen (line) door het manipuleren van de inhoud van die variabele.

Ook vind ik a=$(($a+1)) nogal creatief. Ik zou gaan voor ((a+=1)) of let a=a+1.

[ Voor 14% gewijzigd door Aragnut op 12-01-2011 11:48 ]

[Boudewijn]

edit: wel een slordig script. Je overschrijft je eigen variabelen (line) door het manipuleren van de inhoud van die variabele.

Ik zie het slordige er niet aan. Is eerder efficient geheugengebruik.

Zal zo eens kijken of het scheelt als ik direct /bin/rm aanroep. Qua alias: het is niet mijn machine, daar heeft iemand anders dat ingesteld en kan (nou ja mag) het niet zomaar verwijderen.

Die a=$(($a+1)) : Tsja copy-pasta van teh interwebz. Buiten dat niet echt boeiend.

[Aragnut]

qua efficiency: die lijn overschrijven kun je ook vermijden door de file niet gescheiden te maken met een colon, maar met spatie. Dan hoef je je string niet meer te manipuleren. Een ander alternatief (waar ik zelf te veel gebruik van maak) is awk. Ik neem aan dat de "files" aan de onderkant een variabele is? (ik mis de $ namelijk).

Gezien je verwijdert met rm -i, en dus het script handmatig afvuurt, waarom geen logging bijhouden van de gevonden bestanden?

edit: ik gok trouwens dat dit een onderdeel is van een groter script, want anders is het een beetje raar om een functie de definieren en dan vervolgens alleen die functie af te trappen.

[ Voor 16% gewijzigd door Aragnut op 12-01-2011 13:09 ]

[CrankyGamerOG]

Waarom niet gewoon de files listen en dan met read een keuze laten maken tussen deleten of inpakken en wegmoven?

[Boudewijn]

Aragnut schreef op woensdag 12 januari 2011 @ 13:05:
qua efficiency: die lijn overschrijven kun je ook vermijden door de file niet gescheiden te maken met een colon, maar met spatie. Dan hoef je je string niet meer te manipuleren. Een ander alternatief (waar ik zelf te veel gebruik van maak) is awk. Ik neem aan dat de "files" aan de onderkant een variabele is? (ik mis de $ namelijk).

Uhh ja dit komt van een of andere virusscanner waar ik (ook) niet aan mag rotzooien. Dus dat wordt hem niet. Ook zitten er spaces in de filenames.... (ja blegh, kan ik weer niets aan doen ).

CrankyGamerOG schreef op woensdag 12 januari 2011 @ 13:07:
Waarom niet gewoon de files listen en dan met read een keuze laten maken tussen deleten of inpakken en wegmoven?

Gezien je verwijdert met rm -i, en dus het script handmatig afvuurt, waarom geen logging bijhouden van de gevonden bestanden?

Dat gebeurt al... maar rm -i is nodig.

edit: ik gok trouwens dat dit een onderdeel is van een groter script, want anders is het een beetje raar om een functie de definieren en dan vervolgens alleen die functie af te trappen.

Nop dat is het niet, maar dan is het makkelijker uitbreidbaar indien nodig.

CrankyGamerOG schreef op woensdag 12 januari 2011 @ 13:07:
Waarom niet gewoon de files listen en dan met read een keuze laten maken tussen deleten of inpakken en wegmoven?

Is meer werk en niet nuttig. Het zijn virus-mailtjes .

[CrankyGamerOG]

Boudewijn schreef op woensdag 12 januari 2011 @ 13:11:
[...]

Uhh ja dit komt van een of andere virusscanner waar ik (ook) niet aan mag rotzooien. Dus dat wordt hem niet. Ook zitten er spaces in de filenames.... (ja blegh, kan ik weer niets aan doen ).
[...]


[...]

Dat gebeurt al... maar rm -i is nodig.


[...]

Nop dat is het niet, maar dan is het makkelijker uitbreidbaar indien nodig.


[...]
Is meer werk en niet nuttig. Het zijn virus-mailtjes .

Check dan op basis van de signature van het bestand....?

imho denk je veel te moelijk

[Verwijderd]

En wat nu als iemand een bestand maakt zoals /home/boudewijn/superbelangrijkbestand::::::::::hallo:::daar ?

[Boudewijn]

CrankyGamerOG schreef op woensdag 12 januari 2011 @ 14:32:
[...]


Check dan op basis van de signature van het bestand....?

imho denk je veel te moelijk

Nee, het gaat hier om een FS dat retetraag is door de hoeveelheid mail... groot bedrijf, grote mailserver.
Niet handig ingericht maar ik mag het niet aanpakken .

Verwijderd schreef op woensdag 12 januari 2011 @ 14:46:
En wat nu als iemand een bestand maakt zoals /home/boudewijn/superbelangrijkbestand::::::::::hallo:::daar ?

Dan zal dat alsnog met de hand moeten gebeuren.
Hey het is een mailserver, die maakt zelf die files aan . Dat is 1.
2: het wordt met de hand vanuit een mailtje naar mijn input file gecopieerd. daarbij zit er een check in.
3: rm -i

[JeroenE]

Waarom wil je per se -i gebruiken? Zoals je het nu hebt opgezet gaat dat in ieder geval niet werken. De -i betekent dat rm gaat vragen of het bestand verwijderd mag worden (of niet).

Maar je gebruikt de inhoud van het bestand "files" om op die vraag te antwoorden. Die redirect je immers in je do-loop waarom je om die bevestiging vraagt.

Tenzij je zeker weet dat alle bestanden bestaan en iedere tweede regel uit een "yes" bestaat gaat dat niet werken.

Aangezien je eerst test of het bestand bestaat ga ik er maar van uit dat je niet zeker weet of het bestand (nog) bestaat. En als je het wel zeker weet en ook zeker weet dat je het bestand wil verwijderen dan is het vragen om de bevestiging door middel van die -i weer onzin.

Wellicht snap ik gewoon niet wat je nu wil?

[Dr. Horrible]

Ik snap niet waarom je niet gewoon het volledige pad zou gebruiken, dan zijn alle problemen toch opgelost?

[Boudewijn]

JeroenE schreef op woensdag 12 januari 2011 @ 15:13:
Waarom wil je per se -i gebruiken? Zoals je het nu hebt opgezet gaat dat in ieder geval niet werken. De -i betekent dat rm gaat vragen of het bestand verwijderd mag worden (of niet).

Ja dat weet ik.
Het rm -i gebeuren :policy.

Maar je gebruikt de inhoud van het bestand "files" om op die vraag te antwoorden. Die redirect je immers in je do-loop waarom je om die bevestiging vraagt.

Befehl ist Befehl.

Tenzij je zeker weet dat alle bestanden bestaan en iedere tweede regel uit een "yes" bestaat gaat dat niet werken.

Wat bedoel je?

Aangezien je eerst test of het bestand bestaat ga ik er maar van uit dat je niet zeker weet of het bestand (nog) bestaat.

Robuust programmeren.

En als je het wel zeker weet en ook zeker weet dat je het bestand wil verwijderen dan is het vragen om de bevestiging door middel van die -i weer onzin.

Nee, policy.

Dr. Horrible schreef op woensdag 12 januari 2011 @ 15:26:
Ik snap niet waarom je niet gewoon het volledige pad zou gebruiken, dan zijn alle problemen toch opgelost?

Dat gaan we straks nog even proberen ja.

[Verwijderd]

Boudewijn schreef op woensdag 12 januari 2011 @ 15:43:
Robuust programmeren.

Daar is anders niets robuust aan, maar als je dit soort vragen op een forum moet gaan stellen en alles stapje voor stapje in een Nazi-gevangenis moet gaan lopen uitvoeren, dan heb je grotere problemen.

Als je iemand in Bash iets in elkaar laat "klussen", krijg je gewoon kwalitatief bende qua software. Als je iets programmeert in een taal zorg dan in ieder geval dat je weet wat je aan het doen bent.

Dat hele Linux distributies gebaseerd zijn op sh heeft daar overigens niets mee te maken; dat het mogelijk is om foutloze systemen te maken wil niet zeggen dat dit relatief snel gebeurt of dat dit al is gedaan.

[CAPSLOCK2000]

Boudewijn schreef op woensdag 12 januari 2011 @ 15:43:

[...]

Befehl ist Befehl.

Ik geloof dat je het punt van JeroenE mist, die correct heeft gezien waar je script fout loopt.
Het venijn zet hem in de staart:

done < "files"

Je redirect STDIN
rm -i leest STDIN
probleem

[Boudewijn]

CAPSLOCK2000 schreef op donderdag 13 januari 2011 @ 00:25:
[...]


Ik geloof dat je het punt van JeroenE mist, die correct heeft gezien waar je script fout loopt.
Het venijn zet hem in de staart:

done < "files"

Je redirect STDIN
rm -i leest STDIN
probleem

Inderdaad, logische verklaring. Ik ga die vrijdag even testen, heb morgen wat anders te doen.
Dank je JeroenE (ervanuitgaande dat dat het is).

[JeroenE]

[b][message=35353466,noline]Boudewijn schreef op woensdag 12 januari 2011 @ 15:43
Het rm -i gebeuren :policy.
[...]
Befehl ist Befehl.

Tja, met zo'n mentaliteit valt natuurlijk niet te werken

Als je een manier hebt gevonden waardoor je de stdin kan redirecten en tegelijkertijd toch tussendoor op antwoorden via een toetsenbord kan wachten dan hoor ik het graag. Dan kan ik die bug kan melden bij de maintainers van bash

Het ging mij eigenlijk meer om de achterliggende gedachte. Ik snap dat er een mailserver is en dat er spam/virussen etc op binnen komen. Nu beheer ik nergens een mailserver dus ik ben niet super bekend met de best practices, maar zoals je het nu gaat oplossen komen mij niet handig over.

Het lijkt mij toch redelijk standaard dat virusmailtjes inclusief attachments in een "quarantine" directory terecht komen. Je stuurt de geadresseerde een mailtje met "He, Pietje Puk stuurde jou dit virus. Als je een goede reden hebt waarom je hem toch wil ontvangen meld je dan even bij de mailbeheerder zodat die het virus op een USB stick kan zetten."
En vervolgens delete je alle mail inclusief attachments waarop niemand heeft gereageerd na 30 dagen (ervan uitgaand dat iemand maximaal 3 weken op vakantie is).


Als ik je verhaal goed begrijp ben je nu iets enorm ingewikkelds aan het brouwen. Iemand moet de mailtjes bekijken, de attachment-bestandsnaam handmatig in een bestand kopiëren en daarna een script draaien wat dat bestand weer gaat uitlezen en vervolgens handmatig gaan bevestigen dat die bestanden echt weg gegooid moeten worden.

Zelfs al zou je toch een ingewikkeld handmatig proces willen gebruiken zou ik dat proces versimpelen: laat iemand de mail bekijken en dan gelijk handmatig het bestand weggooien. Klaar.

[Boudewijn]

JeroenE schreef op donderdag 13 januari 2011 @ 08:23:
Het lijkt mij toch redelijk standaard dat virusmailtjes inclusief attachments in een "quarantine" directory terecht komen. Je stuurt de geadresseerde een mailtje met "He, Pietje Puk stuurde jou dit virus. Als je een goede reden hebt waarom je hem toch wil ontvangen meld je dan even bij de mailbeheerder zodat die het virus op een USB stick kan zetten."
En vervolgens delete je alle mail inclusief attachments waarop niemand heeft gereageerd na 30 dagen (ervan uitgaand dat iemand maximaal 3 weken op vakantie is).

Nee in dit geval is het nog veel fijner. Het gaat hier om een grote machine waar echt veel mail op staat. Als het SAN vol begint te lopen wordt er een mailtje gestuurd naar de beheerpartner en die gaan dan wellicht de virussen wegmikken. Deze laatste stap betekent dat soms een jaar lang een quarantained mailtje bestaat...
Oh ja de organisatie van wie de server is moet ook nog de lijst met te verwijderen files accorderen.

Als ik je verhaal goed begrijp ben je nu iets enorm ingewikkelds aan het brouwen. Iemand moet de mailtjes bekijken, de attachment-bestandsnaam handmatig in een bestand kopiëren en daarna een script draaien wat dat bestand weer gaat uitlezen en vervolgens handmatig gaan bevestigen dat die bestanden echt weg gegooid moeten worden.

Zelfs al zou je toch een ingewikkeld handmatig proces willen gebruiken zou ik dat proces versimpelen: laat iemand de mail bekijken en dan gelijk handmatig het bestand weggooien. Klaar.

Nee. Bureaucratie, en het is dus geen machine waar ik zelf dingen op mag doen, anders word ik of mijn klant met de haren bij een of andere verbintenis gesleept.
Wij krijgen puur een mailtje als eea vol zit en dan kunnen we pas handelen, en de eigenaar van het systeem (of diens vertegenwoordiger) moet verwijderingen goedkeuren. Dat het technisch gezien erg omslachtig is onderken ik maar al te graag, echter kan ik daar niets aan doen. Daarom de Befehl ist Befehl opmerking.


Daarom check ik dus ook of de file nog bestaat, soms duurt het dus erg lang voor die files verwijderd worden. Ik zie het gebeuren dat iemand die files ondertussen (al dan niet deels) verwijdert.

[ Voor 12% gewijzigd door Boudewijn op 14-01-2011 01:14 ]

[Verwijderd]

Boudewijn schreef op vrijdag 14 januari 2011 @ 01:11:
[...]
Wij krijgen puur een mailtje als eea vol zit en dan kunnen we pas handelen, en de eigenaar van het systeem (of diens vertegenwoordiger) moet verwijderingen goedkeuren.

Zou je qua opzet niet zoals hieronder kunnen doen?

code:

function removeFiles {
    for file in `cat /list.txt`; do
        if[ -f $file ]; then
            rm -i $line
        else
            echo "$file does not exist\n"
        fi
    done
}


function listFiles {
    for file in `ls  -la | cut -d ':' -f1`; do
        echo $file >> /list.txt
    done
}

[JeroenE]

Boudewijn schreef op vrijdag 14 januari 2011 @ 01:11:
Oh ja de organisatie van wie de server is moet ook nog de lijst met te verwijderen files accorderen.

Je bedoelt dat iemand van die organisatie achter het scherm gaat zitten om "yes" in te tikken als rm -i daar om vraagt??

Of beoordelen ze de lijst en krijg jij te horen wat wel en niet weg mag? In dat geval kan je gewoon de lijst met toegestane bestanden gebruiken en hoef je geen -i te gebruiken.

Ik vind het apart dat iemand dus wel aan een bestandsnaam kan beoordelen of die verwijderd mag worden of niet, maar zelf blijkbaar niet in staat is om "rm" in te tikken in een terminal.

Wij krijgen puur een mailtje als eea vol zit en dan kunnen we pas handelen, en de eigenaar van het systeem (of diens vertegenwoordiger) moet verwijderingen goedkeuren. Dat het technisch gezien erg omslachtig is onderken ik maar al te graag, echter kan ik daar niets aan doen. Daarom de Befehl ist Befehl opmerking.

Je kan natuurlijk ook gewoon vertellen dat wat zij willen niet mogelijk is en een alternatief aandragen. Als ze zo graag zelf de verantwoordelijkheid willen dragen dan moeten ze ook zelf handelen. Je moet natuurlijk niet akkoord gaan met het feit dat ze een niet werkbare procedure hebben bedacht. Of ga je ook even een journaling filesystem in bash bouwen. Gewoon omdat Befehl ist Befehl enneh we willen er morgen mee live

Daarom check ik dus ook of de file nog bestaat, soms duurt het dus erg lang voor die files verwijderd worden. Ik zie het gebeuren dat iemand die files ondertussen (al dan niet deels) verwijdert.

Waarom zou het erg zijn als iemand de melding krijgt dat het bestand al verwijderd is? Sterker nog in dit geval lijkt het me juist wenselijk zodat ze kunnen onderzoeken hoe het kan dat dat bestand niet meer bestaat.

Ik heb natuurlijk makkelijk kletsen, maar ik zou het in ieder geval allemaal niet zo ingewikkeld maken.

code:

cut -d: -f1 < files|xargs -I : rm :

En laat ze dan maar lekker een tijdje yes intikken.

Als je een lijst hebt met bestanden die al van te voren goedgekeurd zijn kan je de -i er afhalen en hoeven ze verder niets te doen.

Verwijderd schreef op vrijdag 14 januari 2011 @ 05:43:
Zou je qua opzet niet zoals hieronder kunnen doen?

for breekt op spaties. Omdat in de bestandsnamen spaties kunnen voorkomen kan je die dus niet gebruiken.

[Boudewijn]

JeroenE schreef op vrijdag 14 januari 2011 @ 08:31:
[...]
Je bedoelt dat iemand van die organisatie achter het scherm gaat zitten om "yes" in te tikken als rm -i daar om vraagt??

Of beoordelen ze de lijst en krijg jij te horen wat wel en niet weg mag? In dat geval kan je gewoon de lijst met toegestane bestanden gebruiken en hoef je geen -i te gebruiken.

$klant moet de lijst accepteren en de uitvoerder moet volgens policy rm -i doen.

Ik vind het apart dat iemand dus wel aan een bestandsnaam kan beoordelen of die verwijderd mag worden of niet, maar zelf blijkbaar niet in staat is om "rm" in te tikken in een terminal.

Tsja 2 verschillende mensen. Ik ben zelf ook geen onderdeel van de organisatie die rm maar externe... dus tsja... het zij zo. Niet mijn keuze maar dat is voor hun rekening.

Je kan natuurlijk ook gewoon vertellen dat wat zij willen niet mogelijk is en een alternatief aandragen. Als ze zo graag zelf de verantwoordelijkheid willen dragen dan moeten ze ook zelf handelen. Je moet natuurlijk niet akkoord gaan met het feit dat ze een niet werkbare procedure hebben bedacht. Of ga je ook even een journaling filesystem in bash bouwen. Gewoon omdat Befehl ist Befehl enneh we willen er morgen mee live

Neen, maar als zij daarvoor kiezen en de inefficientie van het door hen gekozen systeem voor lief nemen is dat prima.

Waarom zou het erg zijn als iemand de melding krijgt dat het bestand al verwijderd is? Sterker nog in dit geval lijkt het me juist wenselijk zodat ze kunnen onderzoeken hoe het kan dat dat bestand niet meer bestaat.

Vind ik niet netjes.

Ik heb natuurlijk makkelijk kletsen, maar ik zou het in ieder geval allemaal niet zo ingewikkeld maken.

Inderdaad.

Als je een lijst hebt met bestanden die al van te voren goedgekeurd zijn kan je de -i er afhalen en hoeven ze verder niets te doen.

Zie hierboven .

for breekt op spaties. Omdat in de bestandsnamen spaties kunnen voorkomen kan je die dus niet gebruiken.

Ik zie geen for-lus?


Kunnen we het aub over de technische aspecten van het script hebben ipv over de organisaties die erbij betrkoken zijn? Bedankt.

[Verwijderd]

JeroenE schreef op vrijdag 14 januari 2011 @ 08:31:
for breekt op spaties. Omdat in de bestandsnamen spaties kunnen voorkomen kan je die dus niet gebruiken.

Dus?

Ook dan zie ik het probleem niet. Met basename pak je de volledige bestandsnaam met spatie en al.

[JeroenE]

Boudewijn schreef op vrijdag 14 januari 2011 @ 08:55:
$klant moet de lijst accepteren en de uitvoerder moet volgens policy rm -i doen.

Right. Dus zij hebben al gezegd dat het mag en daarna moet jij zelf ook nog ene keer vertellen dat het mag? Dat slaat toch nergens op? Maar goed, blijkbaar vind je het prima om zelf gedachteloos 600 keer "yes" in te tikken

Ik zie geen for-lus?

Ik zie er zelfs twee (in iedere functie van Typnix staat er 1).

Kunnen we het aub over de technische aspecten van het script hebben ipv over de organisaties die erbij betrkoken zijn? Bedankt.

Tuurlijk, maar dat heb ik al uitgelegd. Je kan niet de stdin redirecten en dan tegelijkertijd input vragen van een gebruiker via stdin. Dat is echt technisch niet mogelijk. Hoeveel Befehlen die organistaie je ook geeft.

Verwijderd schreef op vrijdag 14 januari 2011 @ 09:09:
Dus?

Dus werkt het niet als in je list.txt een je een bestandsnaam met spaties staat. Heb je het al eens geprobeerd?

code:

#!/bin/bash

echo bestandsnaam1 > list.txt
echo bestandsnaam2 >> list.txt
echo bestandsnaam met spaties er in >> list.txt

for file in `cat list.txt`
do
    echo rm -i $file
done

geeft deze uitvoer:

code:

rm -i bestandsnaam1
rm -i bestandsnaam2
rm -i bestandsnaam
rm -i met
rm -i spaties
rm -i er
rm -i in

[Boudewijn]

JeroenE schreef op vrijdag 14 januari 2011 @ 09:45:
[...]

Right. Dus zij hebben al gezegd dat het mag en daarna moet jij zelf ook nog ene keer vertellen dat het mag? Dat slaat toch nergens op? Maar goed, blijkbaar vind je het prima om zelf gedachteloos 600 keer "yes" in te tikken

Voor de 4e keer: ik ga daar niet over.

*knip*
Je kunt het ook met normaal taalgebruik brengen natuurlijk

Tuurlijk, maar dat heb ik al uitgelegd. Je kan niet de stdin redirecten en dan tegelijkertijd input vragen van een gebruiker via stdin. Dat is echt technisch niet mogelijk. Hoeveel Befehlen die organistaie je ook geeft.

Laat maar.

[ Voor 14% gewijzigd door blaataaps op 14-01-2011 18:41 ]

[JeroenE]

Want je kan niet praten tegen je baas ofzo?

Als je het voor elkaar krijgt om geen redirection te hoeven gebruiken is het vrij simpel

code:

BACKUPIFS=$IFS
IFS=$'\n'
for line in `cut -d: -f1 < files`
do
  if [ -f "$line" ]
  then
      echo "File exists: $line"
      rm -i "$line"
  else
      echo "WARNING: unauthorised deletion of file $line detected. Please call security!"
  fi
done
IFS=$BACKUPIFS

Maar goed, ga jij je Befehl maar proberen uit te voeren hoor. Laat je het weten wanneer het is gelukt?

[Boudewijn]

JeroenE schreef op vrijdag 14 januari 2011 @ 10:03:
Want je kan niet praten tegen je baas ofzo?

Nee want ook mijn 'baas' (klant, ik ben zelfstandige) accepteert de situatie. Zijn baas en klant kennelijk ook.
Sowieso: ik merkte al eerder op dat ik de zin van die stappen niet hier wil bespreken, ik moet het gewoon daarmee doen.

Als je het voor elkaar krijgt om geen redirection te hoeven gebruiken is het vrij simpel

code:

BACKUPIFS=$IFS
IFS=$'\n'
for line in `cut -d: -f1 < files`
do
  if [ -f "$line" ]
  then
      echo "File exists: $line"
      rm -i "$line"
  else
      echo "WARNING: unauthorised deletion of file $line detected. Please call security!"
  fi
done
IFS=$BACKUPIFS

Maar goed, ga jij je Befehl maar proberen uit te voeren hoor. Laat je het weten wanneer het is gelukt?

Waarvan akte.

[JeroenE]

Boudewijn schreef op vrijdag 14 januari 2011 @ 10:12:
Nee want ook mijn 'baas' (klant, ik ben zelfstandige) accepteert de situatie. Zijn baas en klant kennelijk ook.

Waarom zoude ze de situatie niet accepteren als zij niet verantwoordelijk zijn voor de uitvoering? Blijkbaar zit er bij hen geen "pijn" dus lekker belangrijk. Er zijn anderen die de uitvoering moeten (proberen) te verzorgen dus wat maakt hen het uit?

Het kan ook heel verhelderend zijn om tegen een klant gewoon te zeggen dat iets niet kan.

Ik heb ook klanten van klanten die iets rechtsom willen. Dus maak je het zo. En daarna belt de andere afdeling van de klant van de klant dat ze het graag linksom willen. Dan maak je het zo. Daarna de eerste afdeling van de klant van de klant aan de bel die het toch echt rechtsom willen. Oke, dan weer rechtsom (zie ben best coulant door het een paar keer te veranderen).

Leuk tijdverdrijf voor die afdelingen, maar ik heb wel iets zinnigers te doen. Dus mogen die twee afdeling van mij nu eerst onderling bepalen of het rechtsom of linksom moet en als ze dat weten dan hoor ik het wel weer van de klant.
In de praktijk betekent dat dat je ongeveer iedere 6 maanden wordt gebeld met de vraag of het echt niet linksom kan want de klant van de klant wil dat zo graag. Dan refereer ik aan de eerdere mededeling en vraag ik een bevestiging van die andere afdeling dat ze het er mee eens zijn. Heel gek, maar daar hoor ik dan niets meer van. Tot ze 6 maanden later weer bellen of het echt niet linksom kan.

Gaat pas een jaar of 5 jaar op deze manier dus zo heel belangrijk zal het linksom gaan toch ook weer niet zijn denk ik dan maar.

Maar goed, daar wilde je het niet over hebben.

[cherwin]

1. Gebruik een for loop.
2. Aliassen werken standaard niet in een script.
3. Jouw script ziet er verder goed uit. Controleren of een bestand wel echt een file is, is A Good Thing®

@JeroenE
Om splitting te voorkomen in een for loop moet je IFS=$'\n' setten. Wat je ook kan doen is je file koppelen aan een file descriptor.

code:

exec 9<  "$file_list"
while read -r -u9 file
do
    rm -i "$file"
done
9<&-

Dit komt omdat je een commando gebruikt dat van stdin wilt lezen terwijl de while loop dat nodig heeft.

Hmm, ik had de gehele topic niet aandachtig genoeg doorgelezen. Ik zie dat jij al hetzelfde hebt verteld over het gedrag van een for loop.

[ Voor 123% gewijzigd door cherwin op 14-01-2011 22:34 . Reden: Punt 3 toegevoegd en reactie op JeroenE ]

[JeroenE]

cherwin schreef op vrijdag 14 januari 2011 @ 18:14:
Wat je ook kan doen is je file koppelen aan een file descriptor.

Die truc kende ik nog niet. Thanks
Je kan het zelfs in ietsie-pietsie minder code doen door bij de done gelijk met "9<" te redirecten..

code:

while read -u9 line
do
  file=`echo $line | cut -d: -f1`
  if [ -f "$file" ]
  then
    echo "File exists: $file"
    rm -i "$file"
  else
    echo "WARNING: unauthorised deletion of file $file detected. Please call security!"
  fi
done 9< files

Boudewijn ook weer blij: kan hij toch redirecten en via stdin invoer vragen van de gebruiker. Weliswaar redirect hij geen stdin, maar ik weet niet of dat ook per se stdin moest zijn. .

[sam.vimes]

Tja, het script is geen toonbeeld van elegantie, maar als je de 'rm' regel vervangt door

code:

rm -i "$file" < /dev/tty

zou het moeten werken.

Behalve als er filenamen worden ingevoerd met een ":" in de naam natuurlijk.

[sanfranjake]

Gesloten op verzoek topicstarter.