[unix] Veiligheid: bestanden beginnend met een -

[Anoniem: 38402]

Ik probeerde laatst wat bestanden beginnend met een - (-2344432 etc) te wissen met "rm *". Hier kreeg ik echter een foutmelding voor omdat rm deze bestandsnamen als opties ziet. Om deze bestanden te wissen moest ik expliciet "rm -- *" geven.

Dat kan natuurlijk misbruikt worden...!

Hier een voorbeeldje met een directory inclusief 2 bestanden, die niet gewist mogen worden door een "rm *" in een hogere directory:

code:

test@koen:~/test2$ ls -la
total 12
drwxr-xr-x   3 test test 4096 Oct 27 21:49 .
drwx------  17 test test 4096 Oct 27 21:49 ..
drwxr-xr-x   2 test test 4096 Oct 27 21:49 testdir
test@koen:~/test2$ find .
.
./testdir
./testdir/testfile1
./testdir/testfile2
test@koen:~/test2$ rm *
rm: cannot remove `testdir': Is a directory
test@koen:~/test2$ find .
.
./testdir
./testdir/testfile1
./testdir/testfile2
test@koen:~/test2$

Echter, als er een bestand -rf in de hogere directory staat gebeurd er dit:

code:

test@koen:~/test1$ ls -la
total 16
-rw-r--r--   1 test test    1 Oct 27 21:48 -rf
drwxr-xr-x   3 test test 4096 Oct 27 21:48 .
drwx------  17 test test 4096 Oct 27 21:49 ..
drwxr-xr-x   2 test test 4096 Oct 27 21:49 testdir
test@koen:~/test1$ find .
.
./testdir
./testdir/testfile1
./testdir/testfile2
./-rf
test@koen:~/test1$ rm *
test@koen:~/test1$ find .
.
./-rf
test@koen:~/test1$

Oftewel: het is net of ik een "rm -rf *" heb gegeven ipv een "rm *"!

Hiermee kun je dus ongemerkt enkele nare opties mee geven met commando's...!

[RSpliet]

uhm, leuk Is dit alleen bij Unix, en gaat het om SCO Unix, HPUX, of een (voor mij) minder bekende? Of is het ook met linuxen en freebsd-en?

Edit: Tsja, met Bash2 en RHFC2 gaat dit dus ook op, misschien een report naar de makers van bash dan?

[ Voor 28% gewijzigd door RSpliet op 27-10-2004 22:05 ]

[Anoniem: 117327]

Kan je niet gewoon "rm \-* doen?

Als het goed is kan je alles achter een \ prakken, dus ook de - lijkt me

Edit: nee, werkt niet.

[ Voor 16% gewijzigd door Anoniem: 117327 op 27-10-2004 22:07 ]

[Anoniem: 38402]

Seven of Nine schreef op 27 oktober 2004 @ 22:03:
uhm, leuk Is dit alleen bij Unix, en gaat het om SCO Unix, HPUX, of een (voor mij) minder bekende? Of is het ook met linuxen en freebsd-en?

Inderdaad handig om te vermelden: ik heb het op linux (debian unstable) getest, maar ik vermoed dat het voor alle unix varianten geldt waar de GNU tools gebruikt worden.

[Anoniem: 38402]

Anoniem: 117327 schreef op 27 oktober 2004 @ 22:04:
Kan je niet gewoon "rm \-* doen?

Als het goed is kan je alles achter een \ prakken, dus ook de - lijkt me

Nee, want "rm -rf" zelf doet niets; er moet een bestand (of een wildcard) meegegeven worden voordat er iets gewist kan worden:

code:

test@koen:~/test1$ ls -l
total 4
-rw-r--r--  1 test test 1 Oct 27 21:48 -rf
test@koen:~/test1$ rm \-rf
test@koen:~/test1$ ls -l
total 4
-rw-r--r--  1 test test 1 Oct 27 21:48 -rf
test@koen:~/test1$

Of met "rm \-*":

code:

test@koen:~/test1$ ls -l
total 4
-rw-r--r--  1 test test 1 Oct 27 21:48 -rf
test@koen:~/test1$ rm \-*
test@koen:~/test1$ ls -la
total 12
-rw-r--r--   1 test test    1 Oct 27 21:48 -rf
drwxr-xr-x   2 test test 4096 Oct 27 21:50 .
drwx------  17 test test 4096 Oct 27 21:49 ..
test@koen:~/test1$

[ Voor 25% gewijzigd door Anoniem: 38402 op 27-10-2004 22:08 ]

[RSpliet]

HerrFlick, het gaat er niet op dat je die bestanden wel KAN verwijderen, maar noem je een bestand bijvoorbeeld -v, dan ziet rm dat niet als een bestandsnaam (als je rm * ) als commando meegeeft, maar als een extra parameter. Afgezien van dat het bestand -v gewoon word genegeert door rm, kan je zo ook vervelende andere parameters meegeven aan rm, en vermoedelijk ook andere commando's.

[Erkens]

mja dat is niet de schuld van rm, maar van bash (of welke shell je ook gebruikt) die replaces immers die wildcard door de bestanden, en "-rf" komt eerder.

[A_L]

Volgens mij kun je het met de -- optie wel doen. -- geeft immers aan dat er nu geen opties meer komen. Daarachter kun je dus de "-rf" opgeven. (da's de theorie, moet het nog uitproberen :-) )

[Anoniem: 38402]

Erkens schreef op 27 oktober 2004 @ 22:11:
mja dat is niet de schuld van rm, maar van bash (of welke shell je ook gebruikt) die replaces immers die wildcard door de bestanden, en "-rf" komt eerder.

Bovenstaande tests zijn met bash gedaan.

En inderdaad: het is niet de schuld van rm, die doet ook maar wat opgedragen wordt. Het is alleen wel iets om op te letten. Potentieel kun je dus (met rm) flink wat directories wissen. Er zijn vast andere scenario's te verzinnen met andere commando's om wat anders vervelends uit te halen.

met csh gaat het overigens ook mis:

code:

test@koen:~/test1$ csh
koen:~/test1> ls -la
total 16
-rw-r--r--   1 test test    1 Oct 27 21:48 -rf
drwxr-xr-x   3 test test 4096 Oct 27 22:12 .
drwx------  17 test test 4096 Oct 27 21:49 ..
drwxr-xr-x   2 test test 4096 Oct 27 21:49 testdir
koen:~/test1> rm *
koen:~/test1> ls -la
total 12
-rw-r--r--   1 test test    1 Oct 27 21:48 -rf
drwxr-xr-x   2 test test 4096 Oct 27 22:12 .
drwx------  17 test test 4096 Oct 27 21:49 ..
koen:~/test1>

Meer shells heb ik niet om te testen...

[Anoniem: 38402]

A_L schreef op 27 oktober 2004 @ 22:17:
Volgens mij kun je het met de -- optie wel doen. -- geeft immers aan dat er nu geen opties meer komen. Daarachter kun je dus de "-rf" opgeven. (da's de theorie, moet het nog uitproberen :-) )

Inderdaad, dat werkt.

Als je mijn eerste berichtje leest staat dat er ook in: met "rm -- *" gaat het wel goed.

[A_L]

Anoniem: 38402 schreef op 27 oktober 2004 @ 22:19:
[...]Als je mijn eerste berichtje leest staat dat er ook in: met "rm -- *" gaat het wel goed.

ja dus kun je ook "rm -rf -- -rf" doen denk ik.

btw. het staat ook in de unix-faq punt 2.1

[ Voor 23% gewijzigd door A_L op 27-10-2004 22:55 . Reden: unix-faq link ]

[kwiebus]

Je kan toch gewoon het inode number van de/het bestand(en) opzoeken en de/het bestand(en) dan op inode number verwijderen?

[Anoniem: 38402]

kwiebus schreef op 27 oktober 2004 @ 22:41:
Je kan toch gewoon het inode number van de/het bestand(en) opzoeken en de/het bestand(en) dan op inode number verwijderen?

Nogmaals: het gaat niet om het wissen van het bestandje "-rf", dat is geen probleem.
Wat vervelend is, is dat als je een "rm *" doet bestanden als parameters meegegeven worden, mits ze met een - beginnen. Zo doe je dus per ongeluk een "rm * -rf" zonder dat je dat wilt. En dat kan vervelend uitpakken.

[ Voor 8% gewijzigd door Anoniem: 38402 op 27-10-2004 22:47 ]

[kwiebus]

Anoniem: 38402 schreef op 27 oktober 2004 @ 22:45:
[...]


Nogmaals: het gaat niet om het wissen van het bestandje "-rf", dat is geen probleem.
Wat vervelend is, is dat als je een "rm *" doet bestanden als parameters meegegeven worden, mits ze met een - beginnen. Zo doe je dus per ongeluk een "rm * -rf" zonder dat je dat wilt. En dat kan vervelend uitpakken.

Dan zou je misschien interactief kunnen deleten zodat je bij elk bestand dat je wilt verwijderen een bevesting moet geven. Hiervoor zou je een alias voor het rm commando naar rm -i kunnen maken. Als je dan rm * geeft voer je in feite een rm -i * uit.

[ Voor 8% gewijzigd door kwiebus op 27-10-2004 23:01 ]

[DiedX]

kan je 'm niet "tabben"?

dus rm -<tab>?

En anders Midnight Commander

[Spider.007]

DiedX schreef op 27 oktober 2004 @ 23:26:
kan je 'm niet "tabben"?

dus rm -?

En anders Midnight Commander

Lees het topic eens goed

[slager]

Bij mijn Slackware systeem gaat voorbeeld 2 van de TS wel goed (ik krijg dus wel een melding "rm: 'testdir' is a directory".) Sta je in de directory 'testdir', en doe je dan 'rm *', dan gaat het wel fout.

[pierre-oord]

Kan er niet iets aan RM gepatches worden waardoor die even extra checked of een optie die die krijgt (van bash dus, wat mogelijk een file is) ook als bestand beschikbaar is, en zo ja, de bewerking annuleerd en expliciet vraagt gebruik te maken van de "--" optie?

[Erkens]

pierre-oord schreef op 27 oktober 2004 @ 23:52:
Kan er niet iets aan RM gepatches worden waardoor die even extra checked of een optie die die krijgt (van bash dus, wat mogelijk een file is) ook als bestand beschikbaar is, en zo ja, de bewerking annuleerd en expliciet vraagt gebruik te maken van de "--" optie?

je zou dan bash moeten patchen want rm kan dat nooit zien of die -rf door bash is gedaan of door de user

[DataGhost]

Erkens schreef op 27 oktober 2004 @ 23:55:
[...]

je zou dan bash moeten patchen want rm kan dat nooit zien of die -rf door bash is gedaan of door de user

als ie even kijkt of het bestand '-rf' bestaat kan ie toch weigeren iets te doen?

[ Voor 3% gewijzigd door DataGhost op 28-10-2004 00:08 ]

[Erkens]

DataGhost schreef op 28 oktober 2004 @ 00:08:
[...]

als ie even kijkt of het bestand '-rf' bestaat kan ie toch weigeren iets te doen?

mja, eik zou bash alle files moeten escapen die met een - beginnen, want rm is niet het enige commando wat vervelende dingen kan doen

[DataGhost]

Erkens schreef op 28 oktober 2004 @ 00:09:
[...]

mja, eik zou bash alle files moeten escapen die met een - beginnen, want rm is niet het enige commando wat vervelende dingen kan doen

maar het ging nu even specifiek over -rf

[Erkens]

DataGhost schreef op 28 oktober 2004 @ 00:17:
[...]

maar het ging nu even specifiek over -rf

nee het ging over bestanden die met een - beginnen
en dat is het probleem, rm is niet het probleem namelijk.

[PowerSp00n]

Erkens schreef op 28 oktober 2004 @ 00:09:
[...]

mja, eik zou bash alle files moeten escapen die met een - beginnen, want rm is niet het enige commando wat vervelende dingen kan doen

Juist, dat lijkt mij in ieder geval de netste oplossing (dé oplossing eigenlijk). Dat doet het trouwens met andere speciale tekens al wel (spatie e.d.)? Blijkbaar hebben ze er een over het hoofd gezien.

[ Voor 3% gewijzigd door PowerSp00n op 28-10-2004 00:23 ]

[frim]

mjs als rm controleert of het eerste argument bestaat als filename zou deze bug al verholpen zijn

[Erkens]

frim schreef op 28 oktober 2004 @ 00:22:
mjs als rm controleert of het eerste argument bestaat als filename zou deze bug al verholpen zijn

nee, want ik heb het zojuist getest en het maakt niet uit waar je argumenten staan. Het enige wat dit oplost is door bash te laten escapen

[dawuss]

Dit is toch al minstens 20 jaar bekend of zo? Wat mij betreft is het absoluut geen bug. Dat je bijzondere (ambiguune) files en directories moet escapen is toch basis unix kennis?

Anders kan ik ook wel zeggen dat het een beveiligingsrisico is om een directory ~ aan te maken:

code:

dawuss@bellerophon /tmp/test $ mkdir \~
dawuss@bellerophon /tmp/test $ ls -al
total 2
drwxr-xr-x   3 dawuss users   72 Oct 28 00:32 .
drwxrwxrwt  19 root   root  1704 Oct 28 00:31 ..
drwxr-xr-x   2 dawuss users   48 Oct 28 00:32 ~
dawuss@bellerophon /tmp/test $ rm -rf ~    #Oei, oei oei!
dawuss@bellerophon /tmp/test $ rmdir \~    #Juist! dat is 'm!

Volgens mij doen alle bourne achtige shells dit, maar ook tcsh vertoont dit gedrag. Hartstikke normaal dus

[downtime]

Ik zie het probleem niet zo. Het hele concept van Unix houdt in dat het OS ervan uit gaat dat de gebruiker weet wat ie doet. Daarin verschilt het van Windows.
Windows beschermt je tegen jezelf en maakt het onmogelijk om bestandsnamen te maken met "verboden" karakters. Unix laat het toe omdat de gebruiker immers weet wat ie doet. Een ervaren Unix gebruiker zal geen rm -rf intikken omdat ie weet wat ie doet. Als ie dat niet weet heeft ie niks op het systeem te zoeken.

Voorbeeldje: Ik slaagde er een tijdje geleden met VI (als ik me goed herinner) in om een bestandsnaam te maken die alleen uit Esc karakters bestond. Is moeilijk te verwijderen voor een beginnend Unix gebruikers als ondergetekende. Onder Windows was dat nooit gelukt. Windows laat het gewoon niet toe om dit soort namen te maken.

[kaas-schaaf]

/downtime/ schreef op 28 oktober 2004 @ 00:37:
... Windows laat het gewoon niet toe om dit soort namen te maken.

Windows laat deze bestanden niet zien. ~!,.- etc. komen wel in bestandsnamen voor maar worden niet (actief, dus zonder dat je er nadrukkelijk on vraagt / programatuur gebruikt om dat op te vragen.) weergegeven. Esc characters is idd een ander verhaal, chr 7 zou wel eens lekker zijn. Doet je pc speaker ook nog eens wat.

ontopic:
ik zie het probleem niet zo. Als je het niet gebruikt/wil misbruiken, vermijden. En als je denkt dat kwaadwillende het op jouw voorzien hebben zou ik je beveiliging nog maar eens onder de loop nemen.

[ Voor 19% gewijzigd door kaas-schaaf op 28-10-2004 01:03 ]

[CyBeR]

Dit is al eeuwen zo inderdaad. Het probleem ligt bij de gebruiker die a) gek genoeg is om bestanden te maken die met een '-' beginnen en b) niet oplet waardoor de enorme flexibiliteit van UNIX 'm in de voet schiet.

[PowerSp00n]

dawuss schreef op 28 oktober 2004 @ 00:35:
Dit is toch al minstens 20 jaar bekend of zo? Wat mij betreft is het absoluut geen bug. Dat je bijzondere (ambiguune) files en directories moet escapen is toch basis unix kennis?

Anders kan ik ook wel zeggen dat het een beveiligingsrisico is om een directory ~ aan te maken:

code:

dawuss@bellerophon /tmp/test $ mkdir \~
dawuss@bellerophon /tmp/test $ ls -al
total 2
drwxr-xr-x   3 dawuss users   72 Oct 28 00:32 .
drwxrwxrwt  19 root   root  1704 Oct 28 00:31 ..
drwxr-xr-x   2 dawuss users   48 Oct 28 00:32 ~
dawuss@bellerophon /tmp/test $ rm -rf ~    #Oei, oei oei!
dawuss@bellerophon /tmp/test $ rmdir \~    #Juist! dat is 'm!

Volgens mij doen alle bourne achtige shells dit, maar ook tcsh vertoont dit gedrag. Hartstikke normaal dus

Euh, in jouw voorbeeld kies je er zelf voor om [teken met speciale functie] te gebruiken. In het voorbeeld van de TS niet, daar gaat het er juist om dat er een wildcard gebruikt word voor de files maar deze dus ook gewoon als parameter kunnen functioneren. Tuurlijk zul je hetzelfde probleem krijgen als je rm -rf * doet in het voorbeeld wat jij noemt (neem ik aan dan), ik vind daar nogal een verschil in zitten (dat je het speciale teken zelf bewust gebruikt, of dat het erbij gegooit wordt door een wildcard.

CyBeR schreef op 28 oktober 2004 @ 01:07:
Dit is al eeuwen zo inderdaad. Het probleem ligt bij de gebruiker die a) gek genoeg is om bestanden te maken die met een '-' beginnen en ...

Tja dat is natuurlijk wel zo , gewoon zorgen dat je die files nooit hebt...

[ Voor 11% gewijzigd door PowerSp00n op 28-10-2004 01:14 ]

[Zwerver]

Hier zie je dus weer waarom je n00bs geen rechten moet geven waar ie schade mee aan kan richten. M.a.w. it's not a bug, it's a feature Nee, even serieus: Dit soort dingen zitten al jaren in elke shell, zelfs mijn aftandse Rs6k gaat hier de "fout" mee in. Niks om je zorgen om te maken, alleen moet je eerst nadenken voordat je iets doet. Is dat niet de stelregel voor elk *nix systeem?

[Polichism]

code:

[illusionnet] ~/testdir> ls
-rf     test1   test2   test3   test4
[illusionnet] ~/testdir> rm *
[illusionnet] ~/testdir> ls
-rf
[illusionnet] ~/testdir> rm -rf ./-*
[illusionnet] ~/testdir> ls -l
[illusionnet] ~/testdir>

je kan hem dus wel deleten

[MadEgg]

Het verwijderen was het probleem ook niet

Hoezo, dit lijkt me toch meer een bug dan een feature. De functie van de asterisk is dat hij vervangen wordt door een lijstje van alle bestandsNAMEN, niet door commandline flags...
Als je in bovenstaand geval rm * doet verwacht je dat hij ervan maakt:

code:

rm -- -rf testdir1

Met natuurlijk als output:

code:

testdir1: not a file

of iets dergelijks. Maar hij maakt er dus van:

code:

rm -rf testdir1

Wat als gevolg heeft dat het bestand -rf uiteindelijk niet eens weg is.

Iets wat de gebruiker nooit en te nimmer bedoeld zal hebben. Manieren waarom dit gedrag functioneel gebruikt zou kunnen worden zou ik niet kunnen bedenken, manieren waarop dit door derden misbruikt kan worden des te meer. Dus zelfs als dit geen bug is, dan is het wel een zeer onaangename en onveilige "feature".

[CyBeR]

MadEgg schreef op 28 oktober 2004 @ 06:19:
Het verwijderen was het probleem ook niet

Hoezo, dit lijkt me toch meer een bug dan een feature. De functie van de asterisk is dat hij vervangen wordt door een lijstje van alle bestandsNAMEN, niet door commandline flags...
Als je in bovenstaand geval rm * doet verwacht je dat hij ervan maakt:

code:

rm -- -rf testdir1

Nee, ik verwacht dit:

code:

cordelia:~/tmp marco$ ls
-moof   bar     foo     test
cordelia:~/tmp marco$ echo rm *
rm -moof bar foo test
cordelia:~/tmp marco$

Ik zeg namelijk 'rm *', niet 'rm -- *'. Het ding moet doen wat ik zeg, niet wat het denkt dat ik bedoel.

[TrailBlazer]

ik ben het met Cyber eens. De arrogante houding van moet je maar geen fouten maken en weten wat je doet gaat hier niet op. Dit is gewoon onverwacht gedrag en daar kan je je heel moeilijk op voorbereiden. Hooguit door schade en schande leer je hier van. Een krachtig tooltje is handig maar niet als die kracht opeens boven komt als je het neit verwacht

[dawuss]

PowerSp00n schreef op 28 oktober 2004 @ 01:13:
Euh, in jouw voorbeeld kies je er zelf voor om [teken met speciale functie] te gebruiken. In het voorbeeld van de TS niet, daar gaat het er juist om dat er een wildcard gebruikt word voor de files maar deze dus ook gewoon als parameter kunnen functioneren. Tuurlijk zul je hetzelfde probleem krijgen als je rm -rf * doet in het voorbeeld wat jij noemt (neem ik aan dan), ik vind daar nogal een verschil in zitten (dat je het speciale teken zelf bewust gebruikt, of dat het erbij gegooit wordt door een wildcard.

Als je in mijn voorbeeld rm -rf * doet, zal dat sterretje inderdaad door de shell vervangen worden door die tilde, en dus door je homedir, waardoor je onbedoeld je hele homedir recursief aan het weggooien bent. Precies hetzelfde probleem dus

[leuk_he]

Dit soort grappen zit er al heel lang in. Een soortgelijk probleem is bestanden met spaties en "*" erin. Je moet dus heel voorzichtig zijn met aannames over bestand namen. bij rm en mogelijk twijfelachtige name gebruik ik ook wel "rm -i" die nogmaals vraagt wat je wil verwijderen.

Overigen heeft windows dit probleem (met name spaties in file namen) ook sinds lange fielanmen worden ondersteund.

Wat was het leven toch mooi in het 8.3 tijdperk

[Anoniem: 38402]

Zwerver schreef op 28 oktober 2004 @ 02:32:
Hier zie je dus weer waarom je n00bs geen rechten moet geven waar ie schade mee aan kan richten. M.a.w. it's not a bug, it's a feature Nee, even serieus: Dit soort dingen zitten al jaren in elke shell, zelfs mijn aftandse Rs6k gaat hier de "fout" mee in. Niks om je zorgen om te maken, alleen moet je eerst nadenken voordat je iets doet. Is dat niet de stelregel voor elk *nix systeem?

Tja, je kunt nog zo weinig rechten hebben, als je home dir gewist wordt omdat de bestanden "-rf" en "~" staan in de directory waar je "rm *" uitvoert... Het systeem heeft geen schade, maar de gebruikersdata is weg. En dat vind ik een graadje vervelender dan een lege /bin directory.

Ik reken me zelf niet tot een 'n00b', maar was wel degelijk verrast toen ik een directory met bestanden a la '-3244233' probeerde leeg te halen met 'rm *' en vervolgens een foutmelding kreeg van rm. Als hier dus een '-rf' en een '~' hadden gestaan was mijn home dir mooi leeg gegooid.

Ik kan me ook niet voorstellen dat dit niet al eerder is 'ontdekt'. Ik neem dan ook aan dat er voor gekozen is om de bestandsnamen specifiek zo door te blijven geven aan commando's, inclusief '-rf' en '~'....

[ Voor 8% gewijzigd door Anoniem: 38402 op 28-10-2004 10:23 ]

[Erkens]

dawuss schreef op 28 oktober 2004 @ 10:03:
[...]

Als je in mijn voorbeeld rm -rf * doet, zal dat sterretje inderdaad door de shell vervangen worden door die tilde, en dus door je homedir, waardoor je onbedoeld je hele homedir recursief aan het weggooien bent. Precies hetzelfde probleem dus

mja zodra je bij rm -f gebruikt dan hoor je _wel_ te weten wat je doet
maar verder heb je helemaal gelijk, bij mij is het zelfs zo dat mijn homedir een symlink is naar een andere partitie en een "rm ~" zou mijn symlink verwijderen, wat toch wel wat problemen kan opleveren. Dus zelfs als er een file "~" zou bestaan en ik die wil verwijderen samen met alle andere files in een dir dan zou die symlink weg zijn en niet dat bestand

Toch ben ik van mening dat de shells dat moeten escapen, immers bij andere "vage" tekens doen ze dit wel afaik. En dat argument dat je hoort te weten wat je doet vind ik tegenwoordig niet echt meer op gaan. Immers er zijn steeds meer mensen die linux (o.a.) gebruiken die niet zo'n "power user" zijn en die gewoon willen doen wat ze willen doen, een stukje gebruiksvriendelijkheid iets wat "linux" nog niet heel erg goed kent

[Anoniem: 38402]

[quote]Erkens schreef op 28 oktober 2004 @ 10:24:
[...]

mja zodra je bij rm -f gebruikt dan hoor je _wel_ te weten wat je doet
[/qoute]

De grap is dus dat je niet eens expliciet een -f meegeeft. Het is zelfs zo dat als er een bestand '-rf' in je directory staat, de -f een -i overruled.

code:

heinjan@koen:/tmp/testdir$ ls
-rf  bestand1  bestand2
heinjan@koen:/tmp/testdir$ rm -i *   #voor de zekerheid interactief rm'en
heinjan@koen:/tmp/testdir$           #????

Dus hoe voorzichtig je ook bent, je moet blijven oppassen....

Wel vreemd overigens, een & wordt niet als parameter gepakt:

code:

heinjan@koen:/tmp/testdir$ ls
&
heinjan@koen:/tmp/testdir$ rm &
rm: too few arguments
Try `rm --help' for more information.
[1] 12373
[1]   Exit 1                  rm
heinjan@koen:/tmp/testdir$ rm *
heinjan@koen:/tmp/testdir$

@Cyber: is dat ook wat je verwacht? Of moet in bovenstaand voorbeeld de 'rm *' als 'rm &' uitgevoerd worden en het bestand dus niet wissen?

[ Voor 39% gewijzigd door Anoniem: 38402 op 28-10-2004 10:40 ]

[Erkens]

Anoniem: 38402 schreef op 28 oktober 2004 @ 10:32:
Het is zelfs zo dat als er een bestand '-rf' in je directory staat, de -f een -i overruled:

das waar ook

[Robtimus]

De laatste wordt gebruikt, dus een rm -rfi negeert de -f en rm -rif negeert de -i. In dit geval komt -rf dus na de -i, dus dat heeft idd geen zin.

[CyBeR]

Anoniem: 38402 schreef op 28 oktober 2004 @ 10:32:

Wel vreemd overigens, een & wordt niet als parameter gepakt:

code:

heinjan@koen:/tmp/testdir$ ls
&
heinjan@koen:/tmp/testdir$ rm &
rm: too few arguments
Try `rm --help' for more information.
[1] 12373
[1]   Exit 1                  rm
heinjan@koen:/tmp/testdir$ rm *
heinjan@koen:/tmp/testdir$

@Cyber: is dat ook wat je verwacht? Of moet in bovenstaand voorbeeld de 'rm *' als 'rm &' uitgevoerd worden en het bestand dus niet wissen?

Dat is ook wat ik verwcht, ja. De shell pakt die & als een 'gooi't in de achtergrond'-commando. Maar alleen als je 't op de commandline ingeeft. Als je rm * doet en er is een file '&' aanwezig dan doet de shell niet meer dan die * expanden naar de files in de huidige directory en dat meegeven aan de argv van het uitgevoerde commando. Die doet er vervolgens niets speciaals mee.

Erkens: het is /niet/ de bedoeling dat shells gewone characters zoals - gaan escapen. Ze escapen alleen characters met een speciale betekenis (tildes, quotes, uitroeptekens, spaties, etc.) Een streepje heeft geen speciale betekenis voor de shell. Alleen hebben veel applicaties ervoor gekozen om er commandline opties mee aan te geven. Overigens is het onmogelijk om te escapen. \- wordt nog steeds als '-' aan in de argv gepropt, en '--' wordt door slechts enkele apps gebruikt om aan te geven dat er geen opties meer komen.

[ Voor 10% gewijzigd door CyBeR op 28-10-2004 10:53 ]

[Erkens]

CyBeR schreef op 28 oktober 2004 @ 10:52:
Erkens: het is /niet/ de bedoeling dat shells gewone characters zoals - gaan escapen. Ze escapen alleen characters met een speciale betekenis (tildes, quotes, uitroeptekens, spaties, etc.) Een streepje heeft geen speciale betekenis voor de shell. Alleen hebben veel applicaties ervoor gekozen om er commandline opties mee aan te geven. Overigens is het onmogelijk om te escapen. \- wordt nog steeds als '-' aan in de argv gepropt, en '--' wordt door slechts enkele apps gebruikt om aan te geven dat er geen opties meer komen.

heb je helemaal gelijk in (behalve dan dat de tilde ook niet ge-escaped wordt ) echter als bash die file die "-rf" heet gaat escapen dan wordt dan "\-rf" en wordt als zodanig naar het commando gegeven:

rm *

wordt:

rm \-rf

Wat ik denk dat handiger is, als bash alle files omsluit met quotes, hoewel ik denk dat niet elke applicatie hiermee kan leven
[edit]
idd dat dacht ik al:

$ touch "-rm"
touch: failed to get attributes of `m': No such file or directory

[ Voor 9% gewijzigd door Erkens op 28-10-2004 11:03 ]

[Robtimus]

Gewoon voortaan met find doen

find . -maxdepth 1 -exec rm \{\} \;

edit:
krijg je wel foutmeldingen over . en ..

[ Voor 25% gewijzigd door Robtimus op 28-10-2004 11:13 ]

[CyBeR]

Erkens schreef op 28 oktober 2004 @ 11:02:
[...]

heb je helemaal gelijk in (behalve dan dat de tilde ook niet ge-escaped wordt ) echter als bash die file die "-rf" heet gaat escapen dan wordt dan "\-rf" en wordt als zodanig naar het commando gegeven:

Tildes idd niet, daar zitten andere voorwaarden aan.
Anyway. Een shell zou '-rf' wel naar '\-rf' kunnen escapen, maar dat heeft weinig nut. De app krijgt dan namelijk niet '\-rf' mee (en wil dat ook niet) maar gewoon '-rf'. Escapes zijn voor de shell, zodat ze speciale characters niet als special zien. Voorbeeld:

code:

rm foo\ bar

rm krijgt nu niet 'foo\ bar' als argument aangeleverd maar 'foo bar'.

Wat ik denk dat handiger is, als bash alle files omsluit met quotes, hoewel ik denk dat niet elke applicatie hiermee kan leven
[edit]
idd dat dacht ik al:

$ touch "-rm"
touch: failed to get attributes of `m': No such file or directory

[/quote]
Bash kan best alle files omsluiten met quotes, maar dan zie je het zelfde als net. Die quotes krijgt de app niet door:

code:

rm "foo bar"

rm krijgt niet '"foo bar"' (met quotes) maar 'foo bar' (zonder). Alweer zijn de quotes alleen in gebruik om speciale characters (in dit geval spaties) niet de boel te laten verstieren.

[Zwerver]

Om hier even bij aan te sluiten:

De meeste oercommando's kenden de - en -- niet eens. Daar werden switches gewoon meegegeven (tar zxvf bestand.tar.gz bijv). Omdat het op een gegeven moment steeds meer in swang raakte om met - en -- te gaan werken hebben de meeste commando's dit nu geintegreerd. Dit houd echter niet in dat het een fout van bash is dat een bestand -rf gepakt wordt als switch Het probleem ligt hem puur in wat het commando er mee doet, immers als de oude manier van werken gewoon gebruikt zou worden was dit probleem er helemaal niet geweest

Even over het al dan niet voorzichtig moeten zijn/eigen schuld etc. Als je dit soort commando's uitvoert dan ga ik er van uit dat je weet wat je doet, als jij zo slim bent om een bestand -rf aan te maken in je homedir dan zit er wmb een steekje bij je lost, zelfde geld voor bestanden die je alleen een ~ als naam geeft. Laten we wel wezen, je maakt gebruik van een OS waar je de basis zaken oer zou moeten weten imho, als je dan toch bestanden gaat maken met niet standaard namen dan vraag je om problemen.

[Erkens]

Zwerver schreef op 28 oktober 2004 @ 11:59:
immers als de oude manier van werken gewoon gebruikt zou worden was dit probleem er helemaal niet geweest

niet geheel mee eens, als je een file hebt die "rf" heet heb je hetzelfde _probleem_

als jij zo slim bent om een bestand -rf aan te maken in je homedir dan zit er wmb een steekje bij je lost, zelfde geld voor bestanden die je alleen een ~ als naam geeft.

ooit bij nagedacht dat je niet dit soort dingen altijd zelf in de hand hebt? immers elk programma wat jij uitvoerd kan schrijven in je home dir, en dat kan in de toekomst wel eens misbruikt worden

[Anoniem: 27915]

Op zich is dit wel een probleem... Echter, het is niet zo erg als de topicstarter doet vermoeden, omdat je nog altijd met permissies zit. Even denken aan exploits: als ik hiervan misbruik wil maken, dan moet ik schrijftoegang hebben om een bestand "-rf" te plaatsen in de dir die ik recursief verwijderd wil zien. In /tmp heb je dat nog wel, maar in /usr of /root oid? Ik dacht 't niet. . Oftewel, de impact is zeer beperkt.

[dawuss]

Anoniem: 27915 schreef op 28 oktober 2004 @ 12:17:
Op zich is dit wel een probleem... Echter, het is niet zo erg als de topicstarter doet vermoeden, omdat je nog altijd met permissies zit. Even denken aan exploits: als ik hiervan misbruik wil maken, dan moet ik schrijftoegang hebben om een bestand "-rf" te plaatsen in de dir die ik recursief verwijderd wil zien. In /tmp heb je dat nog wel, maar in /usr of /root oid? Ik dacht 't niet. . Oftewel, de impact is zeer beperkt.

Dat ben ik niet met je eens. Ik raak niet graag mijn hele homedir kwijt op mijn workstation, maar al zeker niet op een server, waar meestal hele websites en dergelijke in de homedir worden bewaard.

[CyBeR]

Erkens schreef op 28 oktober 2004 @ 12:09:
[...]

niet geheel mee eens, als je een file hebt die "rf" heet heb je hetzelfde _probleem_

Er is geen probleem Je maakt er een probleem van.

[Anoniem: 27642]

dawuss schreef op 28 oktober 2004 @ 12:22:
[...]

Dat ben ik niet met je eens. Ik raak niet graag mijn hele homedir kwijt op mijn workstation, maar al zeker niet op een server, waar meestal hele websites en dergelijke in de homedir worden bewaard.

als dat gebeurt doe je het dus jezelf aan.
Immers enkel jij kan in jouw home directory schrijven.

andere mogelijkheid is dat het in jouw home directorie terecht komt omdat het ge-upload werd via je site.
maar gezien je niet vaak een rm op jouw site los zal dat probleem zich in de praktijk ook niet voordoen.

het "probleem" is al echt jaren bekend. En ook wel bij de makers van bash
het is echter geen probleem, maar een unforseen feature.
dat is iig mijn mening erover.

Immers, een parameter alleen kan geen kwaad.

[dawuss]

Anoniem: 27642 schreef op 28 oktober 2004 @ 12:50:
[...]

als dat gebeurt doe je het dus jezelf aan.
Immers enkel jij/me kan in jouw home directory schrijven.

/me En elk programma door jou uitgevoerd.

Verder is mijn mening nog altijd dat het verwacht gedrag is van een shell. Je weet gewoon dat wildcards worden uitgestrekt en meegegeven als parameters, en zodoende kun je er rekening mee houden

[Anoniem: 73593]

Ik heb niet alles uiterst aandachtig doorgelezen, maar is het geen oplossing als bash bij wildcards om elke naam quotes zet? Dus zoiets:

code:

$ ls -a
.    ..   -rf  hai
$ echo rm *
rm "-rf" "hai"

Dit is toch ook wat er (soms) gebeurt bij bestandsnamen met spaties (Of wordt daar _altijd_ de spatie escaped? Ik meende dat quotes ook werkten)? En wordt zo "-rf" niet gezien als bestandsnaam in plaats van een parameter?

Correct me if I'm wrong (heb nu geen tijd/shell om te testen).
_{he kut, dat heeft CyBeR dus al afgevinkt}

[ Voor 10% gewijzigd door Anoniem: 73593 op 28-10-2004 13:31 ]

[Zwerver]

dawuss schreef op 28 oktober 2004 @ 12:53:
[...]

/me En elk programma door jou uitgevoerd.

Verder is mijn mening nog altijd dat het verwacht gedrag is van een shell. Je weet gewoon dat wildcards worden uitgestrekt en meegegeven als parameters, en zodoende kun je er rekening mee houden

Inderdaad, daar zit hem de hele truc. En valt en staat dus alles met kennis van je systeem Wat betreft virussen e.d. als je die binnen haalt op een linux bak geld weer: ken je systeem Jij haalt dat ding binnen, dus heb jij iets verkeerd gedaan. Ik wou dat al die windows gebruikers eens zo dachten: Ik heb een virus, dat is MIJN schuld... Maar nee, direct wordt er gewezen naar een virusscanner die niet goed is, of dat die site spyware bevat etc. Mensen moeten gewoon hun hersens gebruiken.

[Erkens]

Zwerver schreef op 28 oktober 2004 @ 13:34:
Mensen moeten gewoon hun hersens gebruiken.

true, echter we zitten nu in een tijdperk waarbij iedereen een computer kan aaschaffen en iedereen daarmee denkt te kunnen werken en imo moet dat ook gewoon mogelijk zijn en moet de software daarop reageren. De software staat vaak te lang stil, en moet eigenlijk mee "groeien" met de gebruikers die het daadwerkelijk gebruiken. Nu is het natuurlijk zo dat deze newbies over het algemeen nooit een terminal open trekken en dan is er dus ook geen probleem.

[Steven]

Slightly offtopic.
Met behulp van Samba kan je wel behoorlijk nasty dingen doen:

Bijvoorbeeld:
- Maak een symlink naar iemand z'n homedir...
- Maak zo het volgende bestand aan:

code:

touch \*
    of
touch '\-rf \*' //Weet niet zeker of dat werkt

- En verwijder die bestanden dan via Windows.

[ Voor 6% gewijzigd door Steven op 28-10-2004 14:07 ]

[dawuss]

Steven schreef op 28 oktober 2004 @ 14:06:
Slightly offtopic.
Met behulp van Samba kan je wel behoorlijk nasty dingen doen:

Bijvoorbeeld:
- Maak een symlink naar iemand z'n homedir...
- Maak zo het volgende bestand aan:

code:

touch \*
    of
touch '\-rf \*' //Weet niet zeker of dat werkt

- En verwijder die bestanden dan via Windows.

Die tweede regel gaat sowieso niet werken, je escaped daar de spatie niet eens.
Verder denk ik niet dat samba zo dom is om op shell basis met (ba)sh wildcards te werken, het kan veel meer low-level access krijgen (weet niet hoe dit geimplementeerd is).
Vervolgens heeft Samba een ingebouwd security model: Je mag niet zo maar andermans homedir verwijderen onder samba. Sterker nog: Opties als het volgen van symlinks kun je helemaal uit zetten.
Tenslotte vergeet je het Unix permissiemodel: Je mag als user niet aan andermans files komen als je daar geen rechten voor hebt. Nu draait Samba wel als root, het respecteert deze permissies intern wel.

[Steven]

Die eerste was een jaar geleden nog wel zo; ik zie nu dat Samba ze renamed naar hele 'vreemde' namen en het geintje dus niet meer opgaat.

Ik kon mijn gesubmitte bug nooit meer terug vinden, zo te zien is het opgelost.

[sebas]

Zolang je een bestand niet '-rf /' kunt noemen, heb ik er vreden mee. :-)

[pierre-oord]

Even voor de linux/windows discussie:
Dit is dus echt zo'n probleem waarvan ik denk: FIX HET.
Mensen die zeggen "Tís een feature" of iets in die richting: Deze "feature" gebruik je nooit. En anders maak je mooi een eigen functie die hetzelfde doet oid, ik bedoel, als je het hard wil...

o.a. dit soort dingen zorgen voor een groot gat tussen unix systemen en windows.

Ik ben voor een meer windows achtigere oplossing, waarbij er gewoon "advanced" opties bestaan. Ik bedoel: Wie in windows werkt nou nog met de command prompt? Juist, de wat geavanceerdere mensen die een klein scriptje willen schrijven, wat bijna niets kan.

Maak Linux de sterkte opvolger van Windows, door een handige interface, en een handige shell.

Soms denken mensen hier weleens dat alles moeilijk moet. Misschien dat het jouw hobby is, maar een computer is er wel om het leven gemakkelijker en plezieriger te maken, en van een lege home directory een een gerecussive verwijderde root kan ik me weinig leuks voorstellen...

Ik weet niet waar je een poll kunt vinden, maar anders is dat misschien leuk om hier neer te zetten?

[Anoniem: 73593]

pierre-oord schreef op 29 oktober 2004 @ 09:38:

Ik ben het hier mee eens. Roepen dat je moet weten wat je doet en claimen dat Linux ook gebruiksvriendelijk is gaan niet samen Bash is toch bedoeld als 'n behoorlijk 'vriendelijke' shell, of misschien moeten we er nog een laagje bovenop leggen voor de minder bedeelden, met bescherming tegen dit soort dingen die als 'feature' maar ook als 'horrible security flaw' kunnen worden bestempeld

[Spider.007]

pierre-oord schreef op 29 oktober 2004 @ 09:38:
Even voor de linux/windows discussie:
Dit is dus echt zo'n probleem waarvan ik denk: FIX HET.
Mensen die zeggen "Tís een feature" of iets in die richting: Deze "feature" gebruik je nooit. En anders maak je mooi een eigen functie die hetzelfde doet oid, ik bedoel, als je het hard wil...

[...]

Net zoals in Windows eigenlijk de 'formatteer diskette' alleen voor systeembeheerders met certificaten beschikbaar moet zijn; het verwijderen van bestanden met omzeiling van de prullenbak onmogelijk moet zijn; en Windows System File Protection een erg handige feature is.

Bash is een krachtige shell; en gebruikersfouten zullen altijd kunnen blijven leiden tot ongewenste resultaten. Moet er soms ook een beveiliging komen tegen mensen die perongeluk

code:

rm -Rf /

inplaats van

code:

rm -Rf ./

intikken? Nee; een krachtige tool blijft altijd lastig te gebruiken voor mensen die niet begrijpen of nadenken bij wat ze doen.

[Anoniem: 73593]

Spider.007 schreef op 29 oktober 2004 @ 10:17:
[...]


Net zoals in Windows eigenlijk de 'formatteer diskette' alleen voor systeembeheerders met certificaten beschikbaar moet zijn; het verwijderen van bestanden met omzeiling van de prullenbak onmogelijk moet zijn; en Windows System File Protection een erg handige feature is.

Bash is een krachtige shell; en gebruikersfouten zullen altijd kunnen blijven leiden tot ongewenste resultaten. Moet er soms ook een beveiliging komen tegen mensen die perongeluk

code:

rm -Rf /

inplaats van

code:

rm -Rf ./

intikken? Nee; een krachtige tool blijft altijd lastig te gebruiken voor mensen die niet begrijpen of nadenken bij wat ze doen.

Waarom dan geen extra shell? Een shell die voor je oplet, een 'gebruiksvriendelijke' shell. Een shell die bijvoorbeeld bij SuSE, Mandrake en Fedora wordt meegeleverd. Zo hebben de mensen die overstappen vanuit windows een afstapje in plaats van dat ze zich meteen in het diepe storten. Met een mooie environment variabele die het niveau van oplettendheid aangeeft en dat er aan de hand daarvan waarschuwingen e.d. worden gegeven
En als je wel een krachtige shell wilt, kun je makkelijk overstappen op bash. What say you?

[dawuss]

Dat je met de shell _alles_ kunt is nu juist de kracht van het hele principe. Als je daar niet klaar voor bent, dan gebruik je toch mooie grafische frontends om bijvoorbeeld bestanden te verwijderen?
Niemand zal je tegenhouden om een filemanager als Nautilus of Konqueror op te starten in plaats van [i]rm -f /path/to/dir[i] in te typen.

[CyBeR]

pierre-oord schreef op 29 oktober 2004 @ 09:38:
Even voor de linux/windows discussie:
Dit is dus echt zo'n probleem waarvan ik denk: FIX HET.

NEE, het is GEEN PROBLEEEM. Jullie MAKEN er een probleem van. In Windows of ieder ander commandline OS waarbij de shell wildcards expand gebeurt dit NET ZO. De shell KAN NIET controleren of dit soort dingen voorkomen. En dat hoort ook niet. Zoals ik al zei: de shell moet doen wat je zegt, niet wat het denkt dat je zegt. Dan krijg je namelijk hele andere problemen.

Mensen die zeggen "Tís een feature" of iets in die richting: Deze "feature" gebruik je nooit. En anders maak je mooi een eigen functie die hetzelfde doet oid, ik bedoel, als je het hard wil...

Het is geen "feature", het is gewoon de manier waarop het hoort te werken. Klaar.

o.a. dit soort dingen zorgen voor een groot gat tussen unix systemen en windows.

Als de Windows shell fatsoenlijk werkt doet 'ie precies het zelfde.

Ik ben voor een meer windows achtigere oplossing, waarbij er gewoon "advanced" opties bestaan. Ik bedoel: Wie in windows werkt nou nog met de command prompt? Juist, de wat geavanceerdere mensen die een klein scriptje willen schrijven, wat bijna niets kan.

Maak Linux de sterkte opvolger van Windows, door een handige interface, en een handige shell.

Nogmaals, het kan niet. En het hoeft ook niet te kunnen. (Geldt ook voor de speciale shell van AapopfietS)

Soms denken mensen hier weleens dat alles moeilijk moet. Misschien dat het jouw hobby is, maar een computer is er wel om het leven gemakkelijker en plezieriger te maken, en van een lege home directory een een gerecussive verwijderde root kan ik me weinig leuks voorstellen...

Dan moet je dus niet gaan rommelen met dingen waar je geen verstand van hebt. Ik snap niet waarom iedereen wel z'n auto naar de dealer brengt als er iets mis is, maar bij de computer denkt dat ze het zelf wel kunnen.

Overigens meen ik (ik ga 't niet proberen ) dat 'rm -rf /' wel een waarschuwing oplevert omdat de kans dat je dat wilt wel bijzonder klein is.

[ Voor 4% gewijzigd door CyBeR op 29-10-2004 13:16 ]

[Anoniem: 73593]

CyBeR schreef op 29 oktober 2004 @ 13:14:
Overigens meen ik (ik ga 't niet proberen ) dat 'rm -rf /' wel een waarschuwing oplevert omdat de kans dat je dat wilt wel bijzonder klein is.

Been there, done that.. nee

[mocean]

stel iemand anders met weinig rechten maakt een file -rf aan, als je hem dan als root wilt wissen ben je alsnog de pineut.

Ik ben nu even aan het experimenteren met
> touch "\`date\`"

ik kan nu al files aanmaken met ` ` eromheen, eens kijken of ls of rm die commando's gaat uitvoeren bij rm * of zo...

[Spider.007]

CyBeR schreef op 29 oktober 2004 @ 13:14:
[...]


NEE, het is GEEN PROBLEEEM. Jullie MAKEN er een probleem van. In Windows of ieder ander commandline OS waarbij de shell wildcards expand gebeurt dit NET ZO. De shell KAN NIET controleren of dit soort dingen voorkomen. En dat hoort ook niet. Zoals ik al zei: de shell moet doen wat je zegt, niet wat het denkt dat je zegt. Dan krijg je namelijk hele andere problemen

[...]

naast mijn eerdere relaas blijf ik erbij dat het wel zo netjes is als de shell gewoon escaping zou toepassen op bestandsnamen. Niet alleen op spaties en slashes; maar ook op tildes en streepjes. Er vindt op dat moment geen enkele intepretatie door de shell plaats; maar slecht consistent doorgevoerd gedrag. Het kan niet intended zijn dat een bestand `-rf` als argument aan een commando wordt doorgegeven in plaats van als bestand. Het commando moet weten wat bestanden zijn; en wat command opties zijn. Escaping zou hier niet raar of fout of te belerend zijn.

[Buffy]

Spider.007 schreef op 29 oktober 2004 @ 14:26:
[...]

naast mijn eerdere relaas blijf ik erbij dat het wel zo netjes is als de shell gewoon escaping zou toepassen op bestandsnamen. Niet alleen op spaties en slashes; maar ook op tildes en streepjes. Er vindt op dat moment geen enkele intepretatie door de shell plaats; maar slecht consistent doorgevoerd gedrag. Het kan niet intended zijn dat een bestand `-rf` als argument aan een commando wordt doorgegeven in plaats van als bestand. Het commando moet weten wat bestanden zijn; en wat command opties zijn. Escaping zou hier niet raar of fout of te belerend zijn.

Hoe moet dat Escaping dan werken. Een programma bepaalt zelf hoe het zijn argumenten interpreteert. Daar heeft de shell niks mee te maken. Escaping gebruik je alleen om ervoor te zorgen dat de shell de argumenten met rust laat.

Het enige wat je kan doen is de shell automatisch het '--' argument mee te laten geven wanneer je een glob-expressie gebruikt. Maar dan moeten alle programma's hier wel rekening mee houden.

[blaataaps]

Spider.007 schreef op 29 oktober 2004 @ 14:26:
[...]

naast mijn eerdere relaas blijf ik erbij dat het wel zo netjes is als de shell gewoon escaping zou toepassen op bestandsnamen. Niet alleen op spaties en slashes; maar ook op tildes en streepjes. Er vindt op dat moment geen enkele intepretatie door de shell plaats; maar slecht consistent doorgevoerd gedrag. Het kan niet intended zijn dat een bestand `-rf` als argument aan een commando wordt doorgegeven in plaats van als bestand. Het commando moet weten wat bestanden zijn; en wat command opties zijn. Escaping zou hier niet raar of fout of te belerend zijn.

Dat is een amper realiseerbaar plan.
Het heeft dan ook weinig met escapen te maken, je kunt -rf escapen wat je wilt, er komt -rf bij het programma. Het probleem wat men maakt (ja, maakt, het is er niet, men maakt het) is dan ook geen escape-probleem. Wat je bedoelt is aangeven wat opties zijn en wat bestanden, geenszins een taak voor de shell, sterker nog, onmogelijk voor de shell, tenzij je alle programma's in de shell implementeert weet een shell niet wat mogelijke opties zijn voor een programma. Bestanden die -rf heten voorafgaan met een -- is ook geen optie, lang niet alle software accepteert dat.

[ Voor 6% gewijzigd door blaataaps op 29-10-2004 14:51 ]

[TrailBlazer]

ik liep vandaag tegen dit probleem aan. Iemand had een bestandje -confg aangemaakt in een tftp dir en mijn ls * ging de mist in. Overigens SUN Solaris

[Spider.007]

Dawns_sister schreef op 29 oktober 2004 @ 14:45:
[...]


Hoe moet dat Escaping dan werken. Een programma bepaalt zelf hoe het zijn argumenten interpreteert. Daar heeft de shell niks mee te maken. Escaping gebruik je alleen om ervoor te zorgen dat de shell de argumenten met rust laat.

Het enige wat je kan doen is de shell automatisch het '--' argument mee te laten geven wanneer je een glob-expressie gebruikt. Maar dan moeten alle programma's hier wel rekening mee houden.

Ik was eigenlijk in de veronderstelling dat de shell momenteel al `a\ b` door zou geven aan een programma in plaats van `a b`. Dit blijkt incorrect te zijn. Ik zou het echter logisch vinden als de shell wel netjes spaties ed ge-escaped aan de programma's zou doorgeven; dit zou toch geen problemen op moeten leveren? dus dat

code:

rm a\ b

netjes wordt uitgevoerd als de applicatie rm met de argumenten a\ b of zelfs 'a\ b' (maar die laatste is misschien al teveel bemoeienis.

[Zwerver]

pierre-oord schreef op 29 oktober 2004 @ 09:38:
Even voor de linux/windows discussie:
Dit is dus echt zo'n probleem waarvan ik denk: FIX HET.
Mensen die zeggen "Tís een feature" of iets in die richting: Deze "feature" gebruik je nooit. En anders maak je mooi een eigen functie die hetzelfde doet oid, ik bedoel, als je het hard wil...

o.a. dit soort dingen zorgen voor een groot gat tussen unix systemen en windows.

Ik ben voor een meer windows achtigere oplossing, waarbij er gewoon "advanced" opties bestaan. Ik bedoel: Wie in windows werkt nou nog met de command prompt? Juist, de wat geavanceerdere mensen die een klein scriptje willen schrijven, wat bijna niets kan.

Maak Linux de sterkte opvolger van Windows, door een handige interface, en een handige shell.

Soms denken mensen hier weleens dat alles moeilijk moet. Misschien dat het jouw hobby is, maar een computer is er wel om het leven gemakkelijker en plezieriger te maken, en van een lege home directory een een gerecussive verwijderde root kan ik me weinig leuks voorstellen...

Ik weet niet waar je een poll kunt vinden, maar anders is dat misschien leuk om hier neer te zetten?

Gebruik je onder Windows de command shell als standaard gebruiker? Nee. Laat KDE/Gnome what ever zijn filemanagers toe dat je een bestand maakt dat -rf heet? Vast wel... maar als je bestanden verwijderd interpreteerd Konquerer/galeon/whatever dan de optie -rf? Nee.
Maar nee, wij willen weer dat onze net vers van hun windows systeem afgesprongen gebruikers ineens met de shell gaan werken, terwijl ze niet weten wat ze doen. Wat is er voor verschil met windows? Geen imho, geef ze een standaard geinstalleerde gebruiksvriendelijke distro met een mooie window manager erop en ze hebben de hele cli niet nodig.

Kortom: dit is geen probleem, je weet wat je doet als je met de cli werkt, zo niet dan heb je er niks te zoeken.

[TrailBlazer]

grappig al die mensen die op hun teentjes zijn getrapt als iemand aan "hun" os durft te zitten. Ik vind het ok gewoon raar gedrag niet meer en niets minder. Ben ik nu iemand die niet op cli moet zijn te vinden.

Modbreak:

Ten eerst verpest je het topic door een flamewar uit te lokken en ten tweede is hier niemand een ander OS aan het aanvallen, er wordt alleen de vergelijking getrokken met Windows, waar je ook niet zomaar op CLI niveau gaat klooien als je niet weet wat je doet

[ Voor 98% gewijzigd door Zwerver op 29-10-2004 20:02 ]

[dawuss]

TrailBlazer schreef op 29 oktober 2004 @ 19:19:
grappig al die mensen die op hun teentjes zijn getrapt als iemand aan "hun" os durft te zitten. Ik vind het ok gewoon raar gedrag niet meer en niets minder. Ben ik nu iemand die niet op cli moet zijn te vinden.

Of jij je thuis zou voelen op de CLI weet ik niet, maar je mist in ieder geval wel 1 basis eigenschap om je thuis te voelen in een Unix omgeving: Goed lezen.
Dat het woord "Windows" in dit topic een aantal keer is genoemd, wil helemaal niet zeggen dat dit een discussie Windows vs. Unix is, laat staan een flamewar. Probeer dat er dan ook niet van te maken.
Wat mij betreft voelt niemand zich hier op z'n tenen getrapt omdat iemand aan "hun" OS durft te zitten: Het is een discussie van Unix gebruikers zelf over of shells met de huidige lading nieuwe gebruikers nog wel voldoende "fool-proof" zijn.
Mijn mening hierover is onveranderd: De Unix filosofie is dat er een heleboel kleine tooltjes zijn, met allemaal een kleine, maar welgedefinieerde functie. Je weet van alle kleine dingen, dus ook de shell, hoe ze werken, en kunt die functionaliteit combineren. Ga je echter met die simpele functionaliteit knoeien, door bijvoorbeeld je shell semi-intelligent te maken, dan ondermijn je daarmee het verwachtingspatroon van je gebruiker.
Heb je geen zin om zo'n verwachtingspatroon te ontwikkelen? Blijf dan gewoon lekker bij grafische frontends, die zijn er tenslotte voor ontwikkeld zich aan te passen aan jouw gedachtenpatroon
_{Voor meer over (grafische) gebruikersinterfaces, zijn je keywords "Human Media Interaction"}

[CyBeR]

TrailBlazer schreef op 29 oktober 2004 @ 19:19:
grappig al die mensen die op hun teentjes zijn getrapt als iemand aan "hun" os durft te zitten. Ik vind het ok gewoon raar gedrag niet meer en niets minder. Ben ik nu iemand die niet op cli moet zijn te vinden.

Het is niet 'raar'. Het is volkomen normaal en precies wat verwacht wordt. De shell expand globs naar een lijst met bestanden die de glob matchen. '*' matched alles. 'rm *' wordt dus geexpand naar 'rm <lijst met alle bestanden>'. Logisch, toch? Dat rm nu toevallig '-' gebruikt om opties aan te geven is niet iets waar de shell iets mee te maken heeft, die doet gewoon wat je vraagt: 'rm' uitvoeren en in de argv daarvan elk bestand afzonderlijk geven. De shell weet niet (en kan niet weten) wat de opties zijn voor elk commando.

Als je per see dit gemaakte probleem wilt ontwijken, leer jezelf dan aan altijd rm <evt. opties> -- <files of glob> te doen.

[TrailBlazer]

dawuss schreef op 29 oktober 2004 @ 19:57:
[...]

Of jij je thuis zou voelen op de CLI weet ik niet, maar je mist in ieder geval wel 1 basis eigenschap om je thuis te voelen in een Unix omgeving: Goed lezen.
Dat het woord "Windows" in dit topic een aantal keer is genoemd, wil helemaal niet zeggen dat dit een discussie Windows vs. Unix is, laat staan een flamewar. Probeer dat er dan ook niet van te maken.
[/sub]

ik heb anders ook nooit windows in de mond genomen. Ik probeer er ook geen flame-war van te maken ik constateer enkel dat *nix gebruikers veel feller zijn om de filosofie achter hun systeem te verdedigen. Ik denk ook dat niet windows gebruikers trotser zijn op wat ze met hun systeem kunnen. of dat wel of niet terechts is laat ik in het midden

CyBeR schreef op 29 oktober 2004 @ 20:01:
[...]


Het is niet 'raar'. Het is volkomen normaal en precies wat verwacht wordt. De shell

ok onverwachts dan. het is wel logisch alleen bijzonder onverwachts nu niet meer overigens

[ Voor 16% gewijzigd door TrailBlazer op 29-10-2004 20:08 ]

[Anoniem: 73593]

Zwerver schreef op 29 oktober 2004 @ 15:19:
[...]
Gebruik je onder Windows de command shell als standaard gebruiker? Nee.

Dat is imho eerder omdat dat onding zo beperkt is.

Het argument dat je moet weten wat je doet/dat het verwacht gedrag is vind ik niet opgaan, met als argument dat een heleboel mensen reageerden in de trant van 'dat wist ik nog niet'. Je weet dat de meeste progjes commandline opties aannemen (met wat voor prefix dan ook), en je weet dat de shell de commandline expand als je wildcards gebruikt (dat hebben we denk ik allemaal geleerd toen we tar -xvzf * wilden doen ). Maar om nou te zeggen dat het verwacht gedrag is dat die dingen ook als argumenten worden geaccepteerd vind ik wat ver gaan. Misschien als je een dir hebt met 'n stuk of 10 bestandjes en er staat iets als '-rf' tussen dat je dan wel verder gaat nadenken, maar als je 'n lijst hebt van 'n paarduizend bestanden die allemaal weg moeten, dan wordt je wel net wat meer in de verleiding gebracht om 'rm *' te doen..

[Zwerver]

Anoniem: 73593 schreef op 30 oktober 2004 @ 10:58:
[...]

Dat is imho eerder omdat dat onding zo beperkt is.

Dat is niet waar Ik kan zeker de helft van de scripts die ik in bash maak ook op de Windows CLI maken

Het argument dat je moet weten wat je doet/dat het verwacht gedrag is vind ik niet opgaan, met als argument dat een heleboel mensen reageerden in de trant van 'dat wist ik nog niet'. Je weet dat de meeste progjes commandline opties aannemen (met wat voor prefix dan ook), en je weet dat de shell de commandline expand als je wildcards gebruikt (dat hebben we denk ik allemaal geleerd toen we tar -xvzf * wilden doen ).

Kom op! Wat voor niveau gebruikers zitten hier? Juist, degene die tar zxvf gebruiken als commando (met of zonder streepje btw). Waar het om gaat is dat je moeder dat niet zal doen, je kleine zusje niet etc. En dat ik verwacht van mensen die het wel doen dat ze de shell kennen. Dit is gedrag wat al lang bekend is, daarom bestaat die -- ook.

Maar om nou te zeggen dat het verwacht gedrag is dat die dingen ook als argumenten worden geaccepteerd vind ik wat ver gaan. Misschien als je een dir hebt met 'n stuk of 10 bestandjes en er staat iets als '-rf' tussen dat je dan wel verder gaat nadenken, maar als je 'n lijst hebt van 'n paarduizend bestanden die allemaal weg moeten, dan wordt je wel net wat meer in de verleiding gebracht om 'rm *' te doen..

Mjah, I rest my case. Iedereen die zich niet verdiept in een CLI zou er vanaf moeten blijven, het zelfde risico liep je met windows/dos ook als je deltree C:\ deed, en dat was ook geen bug maar een keiharde feature. Je moet weten wat je doet als je op een CLI werkt, anders moet je gewoon in de UI blijven.

[Anoniem: 73593]

Zwerver schreef op 30 oktober 2004 @ 12:50:
[...]

Dat is niet waar Ik kan zeker de helft van de scripts die ik in bash maak ook op de Windows CLI maken

[...]

Kom op! Wat voor niveau gebruikers zitten hier? Juist, degene die tar zxvf gebruiken als commando (met of zonder streepje btw). Waar het om gaat is dat je moeder dat niet zal doen, je kleine zusje niet etc. En dat ik verwacht van mensen die het wel doen dat ze de shell kennen. Dit is gedrag wat al lang bekend is, daarom bestaat die -- ook.

[...]

Mjah, I rest my case. Iedereen die zich niet verdiept in een CLI zou er vanaf moeten blijven, het zelfde risico liep je met windows/dos ook als je deltree C:\ deed, en dat was ook geen bug maar een keiharde feature. Je moet weten wat je doet als je op een CLI werkt, anders moet je gewoon in de UI blijven.

Daar is verschil in. 'rm -rf /' is gewoon stom, net als 'deltree C:\'. Dat schreeuwt gewoon: "ik verwijder je root / C:!". Maar van 'rm *' zou je verwachten dat alle files in de betreffende directory zouden worden verwijderd. Dat er dan toevallig een '-rf' bij staat heeft imho niks met 'weten wat je doet' te maken. Maar daar kunnen we eeuwen over doorgaan

[CyBeR]

Anoniem: 73593 schreef op 30 oktober 2004 @ 13:11:
[...]

[...]

Daar is verschil in. 'rm -rf /' is gewoon stom, net als 'deltree C:\'. Dat schreeuwt gewoon: "ik verwijder je root / C:!". Maar van 'rm *' zou je verwachten dat alle files in de betreffende directory zouden worden verwijderd. Dat er dan toevallig een '-rf' bij staat heeft imho niks met 'weten wat je doet' te maken. Maar daar kunnen we eeuwen over doorgaan

Jawel Want die '-rf' is ook een file. De shell weet het verschil niet, en rm ziet ook het verschil niet tussen een glob en een argument dat je zelf in hebt gegeven. Er zijn meerdere manieren om dit (totaal logische) gedrag te ontwijken. De eerste heb ik al genoemd (-- voor een glob zetten) de tweede is eigenlijk netter: aangeven dat je alle files in deze directory weg wilt hebben: rm ./*

[benoni]

Ik denk dat het 'probleem' zo diep in de normale workflow van bash commandotaal zit ingebed dat je het niet met een paar patches kunt fixen. Er zullen altijd wel mogelijkheden zijn om commando's en parameters door elkaar te halen.

Wil je het echt oplossen, dan komt het erop neer dat de formattering van Unix commando's in zijn geheel op de schop moet. In plaats van het simpele buffersysteem waarin alles als één strook tekst wordt doorgespeeld, moet er dan een scriptingtaal komen met methods en objects, zoiets als Apple's Open Scripting Architecture.

[Anoniem: 44800]

Erkens schreef op 28 oktober 2004 @ 00:09:
[...]

mja, eik zou bash alle files moeten escapen die met een - beginnen, want rm is niet het enige commando wat vervelende dingen kan doen

Bash escaped geen dingen, hij haalt de escapes juist weg en interpreteert het volgende teken niet Een '-' escapen heeft dus geen enkele zin, want bash doet daar zowiezo al nix mee. Probeer maar eens rm \-i bestand, rm ziet geen verschil, want bash haalt de escape weg (en interpreteert '-' niet, maar dat doet 'ie zowiezo al niet). En als bash een bestand '-i' zou escapen, zou rm '\-i' zien, en geeft aan dat het bestand '\-i' niet bestaat.

frim schreef op 28 oktober 2004 @ 00:22:
mjs als rm controleert of het eerste argument bestaat als filename zou deze bug al verholpen zijn

Dit is geen bug, dit is een feature

De oplossing zou denk ik zijn om altijd voor een wildcard '--' te zetten, als je denkt dat dit een gevaar voor je is.

[dawuss]

frim schreef op 28 oktober 2004 @ 00:22:
mjs als rm controleert of het eerste argument bestaat als filename zou deze bug al verholpen zijn

Ja, grapjas, dan kun je door arbitrary filenames te maken, zorgen dat je bepaalde opties niet meer kunt uitvoeren
Think about it: Wat doet een (bewust bedoelde) rm -rf ./* als het bestand "-rf" bestaat?

[Anoniem: 27915]

dawuss schreef op 28 oktober 2004 @ 12:22:
Dat ben ik niet met je eens. Ik raak niet graag mijn hele homedir kwijt op mijn workstation, maar al zeker niet op een server, waar meestal hele websites en dergelijke in de homedir worden bewaard.

Hoe vaak voer jij rm ~/* uit?

Ik ook nooit. Daarom. .

[Anoniem: 27642]

sowieso als je alle bestanden uit een directorie wilt verwijderen zonder ook de directories te verwijderen, dan doe ik nogsteeds niet rm *

immers dat vertrouw je erop dat je niet het recursive commando hebt gegeven en dus dat rm je een foutmelding geeft op directories.
meestal verwijder ik dan bestanden of op extensie en/of op eerste aantal letters.
Omdat als je eengrote groep bestanden hebt, ze of allemaal dezelvde extensie hebben.
Of allemaaal aan elkaar gerelateerd zijn qua naam.

en wil je wel dat een complete directorie verwijderd word, dan gaat het ook niet uitmaken dat er een bestand tussen zit dat -rf heet.
Een bestand dat -i heet zou dan veel vervelender zijn.

[dawuss]

Anoniem: 27915 schreef op 31 oktober 2004 @ 01:18:
[...]


Hoe vaak voer jij rm ~/* uit?

Ik ook nooit. Daarom. .

Dat zeg ik ook niet.
Ik ging slechts in op de aanname dat het niet erg is als een gewone gebruiker perongeluk rm -rf / doet, omdat hij toch alleen maar schrijfrechten heeft in zijn eigen homedir.

[Wolfboy]

Ik zou zeggen dat zoiets het beste opgelost kan worden door er automatisch quotes omheen te laten zetten.
Voorbeeld, je hebt in een map het bestand -rf
als je dan "rm *" zou doen dan moet dat imho dus op deze manier aan rm gegeven worden:

code:

rm "-rf"

Dan zou het probleem direct weg zijn toch?

[ Voor 8% gewijzigd door Wolfboy op 31-10-2004 12:57 ]

[blaataaps]

Wolfboy schreef op 31 oktober 2004 @ 12:57:
Ik zou zeggen dat zoiets het beste opgelost kan worden door er automatisch quotes omheen te laten zetten.
Voorbeeld, je hebt in een map het bestand -rf
als je dan "rm *" zou doen dan moet dat imho dus op deze manier aan rm gegeven worden:

code:

rm "-rf"

Dan zou het probleem direct weg zijn toch?

Nee, zoals al eerder aangegeven in dit topic: het is geen escape-probleem. rm ziet geen verschil tussen "-rf" en -rf, de shell interpreteert de " " al, als je /echt/ een "-rf" aan rm geeft weet ie niet wat ie er mee moet, \"-rf\" dus, dan krijg je net jes een error dat "-rf" niet bestaat, wat ook zo is, nogmaals, er is geen sprake van een escape-probleem, en nogmaals, het zogenaamde probleem kan niet opgelost worden met shell-escapes.

[ Voor 3% gewijzigd door blaataaps op 31-10-2004 13:03 ]

[Wolfboy]

blaataaps schreef op 31 oktober 2004 @ 13:02:
[...]

Nee, zoals al eerder aangegeven in dit topic: het is geen escape-probleem. rm ziet geen verschil tussen "-rf" en -rf

Hmm dat wist ik niet, ik zou iig verwachten dat als je iets met quotes eromheen als input geeft dat hij het niet meer als commando ziet.
Maar dat heb ik dus verkeerd begrepen

ik zou tenminste verwachten dat als je bijvoorbeeld dit doet:

code:

#commando:
ls -l
# output:
-rw-r--r--  1 user  group  0 Jan 1 01:01 a
-rw-r--r--  1 user  group  0 Jan 1 01:01 b
-rw-r--r--  1 user  group  0 Jan 1 01:01 c

# En bij dit commando:
ls "-l"
# output:
ls: -l: No such file or directory

Maar daar zit idd geen verschil tussen

[ Voor 3% gewijzigd door Wolfboy op 31-10-2004 13:15 ]

[TrailBlazer]

dawuss schreef op 31 oktober 2004 @ 12:44:
[...]

Dat zeg ik ook niet.
Ik ging slechts in op de aanname dat het niet erg is als een gewone gebruiker perongeluk rm -rf / doet, omdat hij toch alleen maar schrijfrechten heeft in zijn eigen homedir.

hmm op mijn werk hebben we een tftpboot dir met 12000 routerconfigs erin. daar wordt je dan ook niet echt vrolijk van. Deze moet namelijk read write voor everybody zijn

[Spider.007]

TrailBlazer schreef op 31 oktober 2004 @ 18:33:
[...]

hmm op mijn werk hebben we een tftpboot dir met 12000 routerconfigs erin. daar wordt je dan ook niet echt vrolijk van. Deze moet namelijk read write voor everybody zijn

Errm.. en je hebt wel eens gehoord van usernames en wachtwoorden enzo? UNIX schijnt best goed te zijn in multi-user systemen.

Ik geloof iig niet dat een systeem niet kan draaien zonder write rechten voor world; dan doe je gewoon iets niet goed

[Olaf van der Spek]

CyBeR schreef op 30 oktober 2004 @ 13:19:
Jawel Want die '-rf' is ook een file. De shell weet het verschil niet, en rm ziet ook het verschil niet tussen een glob en een argument dat je zelf in hebt gegeven. Er zijn meerdere manieren om dit (totaal logische) gedrag te ontwijken. De eerste heb ik al genoemd (-- voor een glob zetten) de tweede is eigenlijk netter: aangeven dat je alle files in deze directory weg wilt hebben: rm ./*

En de derde is toch gewoon om wildcards niet te expanden naar strings die beginnen met een -?

[Anoniem: 73593]

OlafvdSpek schreef op 31 oktober 2004 @ 19:48:
[...]

En de derde is toch gewoon om wildcards niet te expanden naar strings die beginnen met een -?

Nee, want niet alle apps gebruiken '-' om opties aan te geven (ps & tar bijv. hebben geen '-' nodig).

[Olaf van der Spek]

Anoniem: 73593 schreef op 31 oktober 2004 @ 19:51:
Nee, want niet alle apps gebruiken '-' om opties aan te geven (ps & tar bijv. hebben geen '-' nodig).

Dus?

[blaataaps]

OlafvdSpek schreef op 31 oktober 2004 @ 19:48:
[...]

En de derde is toch gewoon om wildcards niet te expanden naar strings die beginnen met een -?

Das handig als je 1000000 files hebt die met - beginnen en je ze wilt deleten.
Alle geopperde "oplossingen" zijn nare hacks en workarounds die weer allerlei problemen en inconsequenties meebrengen waar je uiteindelijk veel meer bij moet nadenken dan nu het geval, en dat allemaal voor een feature (geen bug dus, en wmb ook geen probleem) die gewoon consequent zijn werk doet en zich nergens mee bemoeit.

[dawuss]

OlafvdSpek schreef op 31 oktober 2004 @ 19:48:
[...]

En de derde is toch gewoon om wildcards niet te expanden naar strings die beginnen met een -?

Probeer het uit zou ik zeggen

dawuss@bellerophon ~/test $ echo ./*
./-rf ./bla ./woei

edit:

Hmm, ik lees slecht vanavond

[ Voor 7% gewijzigd door dawuss op 31-10-2004 19:56 ]

[Olaf van der Spek]

blaataaps schreef op 31 oktober 2004 @ 19:54:
Das handig als je 1000000 files hebt die met - beginnen en je ze wilt deleten.

Iets als rm -* of rm -- -*?