[unix] Veiligheid: bestanden beginnend met een -

[dawuss]

Verwijderd 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.

[Verwijderd]

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]

Verwijderd 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

[Verwijderd]

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 Verwijderd 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?

[Verwijderd]

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.

[Verwijderd]

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 ]

[Verwijderd]

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 ]

[Verwijderd]

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]

Verwijderd 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.

[Verwijderd]

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]

Verwijderd 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.

[Verwijderd]

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?

[Verwijderd]

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. .

[Verwijderd]

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]

Verwijderd 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 -?

[Verwijderd]

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]

Verwijderd 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 -- -*?

[blaataaps]

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

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

Je zegt net dat je wildcards met een - erin niet wilt expanden? Maar dus wel als je wildcard toevallig met een - begint? Zie? Het wordt er allemaal veel ingewikkelder op vind ik, en dat allemaal voor exact logisch en voorspelbaar gedrag waar je af en toe rekening mee moet houden, maar dat is met alles zo.

[Olaf van der Spek]

blaataaps schreef op 31 oktober 2004 @ 20:08:
Je zegt net dat je wildcards met een - erin niet wilt expanden? Maar dus wel als je wildcard toevallig met een - begint? Zie? Het wordt er allemaal veel ingewikkelder op vind ik, en dat allemaal voor exact logisch en voorspelbaar gedrag waar je af en toe rekening mee moet houden, maar dat is met alles zo.

* is een wildcard, -* is een string met een wildcard erin (IMO). De * mag dus niet matchen met een string die begint met -.

Zie? Het wordt er allemaal veel ingewikkelder op vind ik, en dat allemaal voor exact logisch en voorspelbaar gedrag waar je af en toe rekening mee moet houden, maar dat is met alles zo.

Ben jij toevallig ook voorstander van alleen werken onder root?
Dat is ook compleet voorspelbaar enzo.

[ Voor 22% gewijzigd door Olaf van der Spek op 31-10-2004 20:13 ]

[CyBeR]

OlafvdSpek schreef op 31 oktober 2004 @ 20:12:
[...]

* is een wildcard, -* is een string met een wildcard erin (IMO). De * mag dus niet matchen met een string die begint met -.

Fout. Het zijn allebei globs.

[Olaf van der Spek]

CyBeR schreef op 31 oktober 2004 @ 20:17:
Fout. Het zijn allebei globs.

Ik had het over wildcards, niet globs.

[blaataaps]

OlafvdSpek schreef op 31 oktober 2004 @ 20:12:
[...]

* is een wildcard, -* is een string met een wildcard erin (IMO). De * mag dus niet matchen met een string die begint met -.

* is technisch gezien ook een string met een wildcard, namelijk alleen die wildcard, maar ik zie je punt nu iets meer. Er zijn vast ook wel andere tekens die door bepaalde programmas geinterpreteerd worden als opties in plaats van bestanden, moeten we die ook allemaal gaan overslaan met globbing?

[...]

Ben jij toevallig ook voorstander van alleen werken onder root?
Dat is ook compleet voorspelbaar enzo.

Wat dat er mee te maken heeft ontgaat me helaas volledig.

[dawuss]

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

Als je nog een stukje terugleest, zie je ook dat ik zei dat het wel degelijk kwaad kan dat je als user alleen alle files kunt verwijderen waar je rechten voor hebt

[CyBeR]

OlafvdSpek schreef op 31 oktober 2004 @ 20:18:
[...]

Ik had het over wildcards, niet globs.

* is een glob. Net als [aAbB].

Je matched met 'foo*' alles wat met foo begint, met '[ab]*' alles met een of een b begint, en met '*' gewoon alles.

Nogmaals, er is geen probleem. Ik snap nog steeds niet waarom er een probleem gemaakt wordt hier. '*' doet gewoon precies wat je wilt: een lijst geven van alle files in de huidige directory. Als je daar './' voorzet ('./*') krijg je een lijst met alle files in de huidige directory met './' ervoor. Dat is ook precies de manier waarop je files beginnend met een '-' weghaalt: 'rm ./-file'.

[Olaf van der Spek]

blaataaps schreef op 31 oktober 2004 @ 20:19:
* is technisch gezien ook een string met een wildcard, namelijk alleen die wildcard, maar ik zie je punt nu iets meer.

Waar beweerde ik dat dat niet het geval was dan?

Er zijn vast ook wel andere tekens die door bepaalde programmas geinterpreteerd worden als opties in plaats van bestanden, moeten we die ook allemaal gaan overslaan met globbinng?

Dat hangt ervan af. Als die apps vaak gebruikt worden, misschien wel.
Patchen om gewoon - te gebruiken voor opties kan ook.

Wat dat er mee te maken heeft ontgaat me helaas volledig.

Veel mensen vinden gescheiden accounts ook veel ingewikkelder. ("Het wordt er allemaal veel ingewikkelder op vind ik")

[ Voor 8% gewijzigd door Olaf van der Spek op 31-10-2004 20:38 ]

[dawuss]

OlafvdSpek schreef op 31 oktober 2004 @ 20:23:
Wat dat er mee te maken heeft ontgaat me helaas volledig.
Veel mensen vinden gescheiden accounts ook veel ingewikkelder. ("Het wordt er allemaal veel ingewikkelder op vind ik")

Zullen we die discussie maar laten varen? Dat gaat nergens over, we hadden het over gewenst gedrag van een shell, niet van de gebruiker die daar gebruik van maakt.
Daarnaast is het ook nog eens ontzettende onzin
Ik ben allang blij dat je onder Windows XP niet allemaal meer standaard administrator bent, nu verschuiven de virussen tenminte van user-based naar exploit-based

[ Voor 23% gewijzigd door dawuss op 31-10-2004 20:26 ]

[blaataaps]

OlafvdSpek schreef op 31 oktober 2004 @ 20:23:
[...]

Veel mensen vinden gescheiden accounts ook veel ingewikkelder. ("Het wordt er allemaal veel ingewikkelder op vind ik")

Veel mensen vinden een computer gebruiken ook ingewikkelder dan een typmachine, dat is natuurlijk een non-argument en slaat nergens op. Voor de rest sluit ik me nogmaals aan bij cyber hierboven, er IS geen probleem, men maakt het een probleem, en als iemand het echt zo'n groot probleem vindt, bash en rm op de meeste linux-systemen zijn gereleased onder de GPL, en ik wil die mensen dan ook van harte aanmoedingen het naar eigen goeddunken te patchen.

[ Voor 18% gewijzigd door blaataaps op 31-10-2004 20:27 ]

[Olaf van der Spek]

en slaat nergens op.

Gebruik het ingewikkelder zijn van iets dan ook niet als (tegn)argument.

CyBeR schreef op 31 oktober 2004 @ 20:22:
* is een glob. Net als [aAbB].

Dat kan best zo zijn, maar ik had het niet over globs. Ik had het over de/het wildcard (karakter) zelf.
Maar dit is gewoon een implementiedetail. Het idee is om - en -- te voorkomen, tenzij de gebruiker er zelf om gevraagd heeft

Nogmaals, er is geen probleem.

Volgens jou niet, volgens anderen wel.
Waarom zou de situatie niet 'verbeterd' kunnen worden?

[ Voor 13% gewijzigd door Olaf van der Spek op 31-10-2004 20:42 ]

[CyBeR]

OlafvdSpek schreef op 31 oktober 2004 @ 20:41:

Volgens jou niet, volgens anderen wel.
Waarom zou de situatie niet 'verbeterd' kunnen worden?

Omdat dit gedrag exact is wat je er van verwacht. Of zou jij het logisch vinden dat software opeens iets anders gaat doen dan waar je om vraagt? Ik vraag door het gebruik van '*' in een glob om alle files die matchen. Dus ook files die beginnen met een -. Sommige tooltjes gebruiken ook + voor argumenten, moeten we die dan ook maar weglaten? Andere apps hebben helemaal geen prefix nodig. Bij nader inzien denk ik dat we globs maar beter helemaal af kunnen schaffen. Da's mischien 'makkelijker'.

[Olaf van der Spek]

CyBeR schreef op 31 oktober 2004 @ 20:45:
Omdat dit gedrag exact is wat je er van verwacht.

Nee, dit is wat jij ervan verwacht, niet wat iedereen ervan verwacht.
Ander matching gedrag kan toch als optie geimplementeerd worden?
Je doet nu net of dat niet mogelijk is.

Of zou jij het logisch vinden dat software opeens iets anders gaat doen dan waar je om vraagt? Ik vraag door het gebruik van '*' in een glob om alle files die matchen. Dus ook files die beginnen met een -.

Dan zet je zo'n veiligheidsoptie toch niet aan?

[CyBeR]

OlafvdSpek schreef op 31 oktober 2004 @ 20:50:
[...]

Nee, dit is wat jij ervan verwacht, niet wat iedereen ervan verwacht.
Ander matching gedrag kan toch als optie geimplementeerd worden?
Je doet nu net of dat niet mogelijk is.

Dus als jij vraagt om een lijst met alle files, dan verwacht je slechts een deel daarvan te krijgen?

Vreemd.

[dawuss]

OlafvdSpek schreef op 31 oktober 2004 @ 20:50:
[...]

Nee, dit is wat jij ervan verwacht, niet wat iedereen ervan verwacht.
Ander matching gedrag kan toch als optie geimplementeerd worden?
Je doet nu net of dat niet mogelijk is.

Jawel, het is wel wat iedereen ervan verwacht: Zo is het al 20 jaar.

Dan zet je zo'n veiligheidsoptie toch niet aan?

En dan? Dan weet je vantevoren, als je je scripts schrijft, nooit meer of je gebruiker het aan of uit heeft staan. Lekker ambiguun wordt het dan, dan zaag je de hele logiscje basis onder de bash shell uit.

[Olaf van der Spek]

CyBeR schreef op 31 oktober 2004 @ 20:54:
Dus als jij vraagt om een lijst met alle files, dan verwacht je slechts een deel daarvan te krijgen?

Vreemd.

Hoezo alle bestanden?
Bestanden die beginnen met een punt worden toch ook niet gematched?
Bovendien gaat het dus vooral om de combinatie met rm en andere utilities.

[Olaf van der Spek]

dawuss schreef op 31 oktober 2004 @ 20:57:
Jawel, het is wel wat iedereen ervan verwacht: Zo is het al 20 jaar.

Waarom is er dan een topic met 100+ posts over?

En dan? Dan weet je vantevoren, als je je scripts schrijft, nooit meer of je gebruiker het aan of uit heeft staan. Lekker ambiguun wordt het dan, dan zaag je de hele logiscje basis onder de bash shell uit.

Je gaat me toch niet vertellen dat je denkt dat zo'n implementatie detail niet opgelost kan worden?

[CyBeR]

OlafvdSpek schreef op 31 oktober 2004 @ 20:57:
[...]

Hoezo alle bestanden?
Bestanden die beginnen met een punt worden toch ook niet gematched?

Dat is dan ook de reden dat ze met een punt beginnen: zodat ze niet gematched worden.

OlafvdSpek schreef op 31 oktober 2004 @ 20:59:
[...]

Waarom is er dan een topic met 100+ posts over?

Omdat sommige mensen hier een probleem zien waar dat er niet is.

[ Voor 29% gewijzigd door CyBeR op 31-10-2004 21:02 ]

[dawuss]

OlafvdSpek schreef op 31 oktober 2004 @ 20:59:
[...]

Waarom is er dan een topic met 100+ posts over?

Omdat een enkele topicstarter zich dit bedacht, en er een handjevol mensen hier over speculeert?

Je gaat me toch niet vertellen dat je denkt dat zo'n implementatie detail niet opgelost kan worden?

Het kan niet worden opgelost zonder backwards compatibility te verliezen, en ook al implementeer je het op deze manier, dan is de functionaliteit van de shell niet meer "eenvoudig en eenduidig".
Ik haal even een quote van mezelf aan:

dawuss schreef op 29 oktober 2004 @ 19:57:
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"}

[Olaf van der Spek]

CyBeR schreef op 31 oktober 2004 @ 21:01:
Dat is dan ook de reden dat ze met een punt beginnen: zodat ze niet gematched worden.

Eh, sinds wanneer betekent alle, alle, behalve als de naam begint met een punt?

dawuss schreef op 31 oktober 2004 @ 21:03:
Het kan niet worden opgelost zonder backwards compatibility te verliezen.

Waaorm niet?

[ Voor 26% gewijzigd door Olaf van der Spek op 31-10-2004 21:07 ]

[CyBeR]

OlafvdSpek schreef op 31 oktober 2004 @ 21:05:
[...]

Eh, sinds wanneer betekent alle, alle, behalve als de naam begint met een punt?

De naam begint met een punt om niet onder 'alle' te vallen. Daar verwacht je dus dat ze niet matchen. Net zoals je ze niet ziet in 'ls'. Files die beginnen met een - zie ik wel in ls, dus verwacht ik dat ze matchen.

[Olaf van der Spek]

CyBeR schreef op 31 oktober 2004 @ 21:09:
De naam begint met een punt om niet onder 'alle' te vallen. Daar verwacht je dus dat ze niet matchen. Net zoals je ze niet ziet in 'ls'. Files die beginnen met een - zie ik wel in ls, dus verwacht ik dat ze matchen.

Volgens mij matched * dus niet alle files, maar alle normale files. En normale files zijn dan files waarvan de naam niet met een punt begint.

Maar waarom zou zo'n zelfde 'afspraak' niet (als optie) voor - gemaakt kunnen worden?

[CyBeR]

OlafvdSpek schreef op 31 oktober 2004 @ 21:13:
[...]

Volgens mij matched * dus niet alle files, maar alle normale files. En normale files zijn dan files waarvan de naam niet met een punt begint.

Maar waarom zou zo'n zelfde 'afspraak' niet (als optie) voor - gemaakt kunnen worden?

De enige uitzondering die er is, is de punt. We kunnen (en willen) niet meer uitzonderingen maken omdat dat a) bestaande programma's en scripts die afhankelijk zijn van het bestaande, normale gedrag breekt en b) we dan net zo goed alles wat begint met een 'p' kunnen hiden zodat we niet perongeluk /etc/passwd weggooien. Anders gezegd: dan is het hek van de dam.


Eigenlijk komt het op het volgende neer: If you can't stand the heat, get out of the kitchen. Of anders gezegd: Als je niet weet hoe je met een shell om moet gaan, blijf er dan met je poten van af.

Realiseer je je, dat een dergelijke verandering met terugwerkende kracht in alle UNIXen en UNIX-achtigen geimplementeerd zou moeten worden? En dat als dat gebeurd is, alle programma's en alle scripts gecontroleerd en in sommige gevallen aangepast zouden moeten worden? Wil jij het dan voor ons doen?

[blaataaps]

OlafvdSpek schreef op 31 oktober 2004 @ 21:13:
[...]

Volgens mij matched * dus niet alle files, maar alle normale files. En normale files zijn dan files waarvan de naam niet met een punt begint.

Maar waarom zou zo'n zelfde 'afspraak' niet (als optie) voor - gemaakt kunnen worden?

Dat kan prima, maar om nu een afspraak te maken die een scriptingstandaard en een verwachting die al 30 jaar bestaan en voldoen schendt omdat sommige programmas een - interpreteren als optie, lijkt me op grote schaal kansloos en zinloos. Niks staat je echter in de weg de OvdSsh te maken

[Olaf van der Spek]

CyBeR schreef op 31 oktober 2004 @ 21:19:
De enige uitzondering die er is, is de punt. We kunnen (en willen) niet meer uitzonderingen maken omdat dat a) bestaande programma's en scripts die afhankelijk zijn van het bestaande, normale gedrag breekt en b) we dan net zo goed alles wat begint met een 'p' kunnen hiden zodat we niet perongeluk /etc/passwd weggooien. Anders gezegd: dan is het hek van de dam.

Ik heb het aan dawuss ook al gevraagd, maar waarom zou zo'n optie niet in een backwards compatibel manier geimplementeerd kunnen worden?

[CyBeR]

OlafvdSpek schreef op 31 oktober 2004 @ 21:23:
[...]

Ik heb het aan dawuss ook al gevraagd, maar waarom zou zo'n optie niet in een backwards compatibel manier geimplementeerd kunnen worden?

Omdat 't hele zooitje dan een grote ononderhoudbare klucht wordt.

[Olaf van der Spek]

Welk zooitje?

[dawuss]

OlafvdSpek schreef op 31 oktober 2004 @ 21:23:
[...]

Ik heb het aan dawuss ook al gevraagd, maar waarom zou zo'n optie niet in een backwards compatibel manier geimplementeerd kunnen worden?

Hier keer je de bewijslast om
Kun jij een manier bedenken waarop het nog wel backwards compatible werkt? Ik niet namelijk

[blaataaps]

dawuss schreef op 31 oktober 2004 @ 21:27:
[...]

Hier keer je de bewijslast om
Kun jij een manier bedenken waarop het nog wel backwards compatible werkt? Ik niet namelijk

Meegeven als een optie (en dan hopelijk een die begint met een -, anders werkt de optie niet op zichzelf), zodat je heerlijk unportable schell-scripts kun schrijven, #!/bin/sh --do-silly-stuff.

Ik begin nu de indruk te krijgen dat iedereen tegen beter weten in op elkaar inlult zonder een steek verder te komen. Hoewel het allemaal in principe wel on-topic is, wil ik toch verzoeken er geen simpele "welles-nietus"-wedstrijd van te maken

[Olaf van der Spek]

dawuss schreef op 31 oktober 2004 @ 21:27:
Hier keer je de bewijslast om
Kun jij een manier bedenken waarop het nog wel backwards compatible werkt? Ik niet namelijk

Jij claimt toch dat het niet kan?
Ik vraag je om die claim te onderbouwen, maar dat kan blijkbaar niet.

Maar een manier lijkt mij om de optie via een environment variabele in te schakelen en alleen toe te passen op interactive terminals.

[ Voor 9% gewijzigd door Olaf van der Spek op 31-10-2004 21:38 ]

[pierre-oord]

Ik denk dat de shell aanpassen niet erg handig is.

Er zijn 2 mogelijkheden
1) Unix aanpassen, en zorgen dat de shell meegeeft aan een programma wat opties zijn en wat bestanden, en dat allemaal op een heel standaard manier, voor alle bestanden gelijk.
2) Makers van tools als rm vertellen dat ze bij hun schakelopties eerst kijken of het ook om een bestand kan gaan, en zo ja, een vraag stellen, of dat bestand verwijderen, eventueel nog met een optie als "altijd bestand verwijderen" "altijd commando uitvoeren".

Dit is gewoon iets waar programmeurs rekening mee moeten houden, het is gewoon een bug.

Ik bedoel, je kunt iedere bug wel een feature gaan noemen.

Een veiligheidslek in Apache? Nee jo, da's remote access tot m'n machine.

[Zwerver]

OlafvdSpek wil je ajb ophouden met het wellus nietus spelletje wat je hier speelt? Kom jij maar met eens stuk code waar jij in aantoont dat het MET behoud van de huidige scripts die er zijn aangepast kan worden en dan praten we verder. Doe je dat niet dan heb je je punt nu wel gemaakt, gezien dat er mensen het niet met je eens zijn juist omwille van die backwards compatible-heid en zul jij dus moeten aantonen dat het wel kan. Daarmee sluit ik dus ook die discussie en geef ik je 1 tip, begin er niet weer over zonder met bewijs te komen want je zit hier verschrikkelijk te irriteren zonder met feiten te komen.

[Zwerver]

pierre-oord schreef op 31 oktober 2004 @ 23:00:
Ik denk dat de shell aanpassen niet erg handig is.

Er zijn 2 mogelijkheden
1) Unix aanpassen, en zorgen dat de shell meegeeft aan een programma wat opties zijn en wat bestanden, en dat allemaal op een heel standaard manier, voor alle bestanden gelijk.
2) Makers van tools als rm vertellen dat ze bij hun schakelopties eerst kijken of het ook om een bestand kan gaan, en zo ja, een vraag stellen, of dat bestand verwijderen, eventueel nog met een optie als "altijd bestand verwijderen" "altijd commando uitvoeren".

Dit is gewoon iets waar programmeurs rekening mee moeten houden, het is gewoon een bug.

Ik bedoel, je kunt iedere bug wel een feature gaan noemen.

Een veiligheidslek in Apache? Nee jo, da's remote access tot m'n machine.

De vraag is of het een bug in bash is, en daarop is het antwoord gewoon nee. Je weet hoe de shell werkt, je weet hoe je er mee om moet gaan of niet. Je weet hoe globbing werkt of niet.
Dan kan je wel alles wat jij niet als gewenst gedrag ziet als bug aanmerken, maar alle shells doen het al 30 jaar op deze manier en denk je nou werkelijk dat al die mensen voor ons er niet over nagedacht hebben? Die wisten gelukkig hoe ze met een shell om moesten gaan en vonden dit dus gewenst/verwacht gedrag.

[Olaf van der Spek]

Zwerver schreef op 31 oktober 2004 @ 23:05:
OlafvdSpek wil je ajb ophouden met het wellus nietus spelletje wat je hier speelt? Kom jij maar met eens stuk code waar jij in aantoont dat het MET behoud van de huidige scripts die er zijn aangepast kan worden en dan praten we verder.

Zoals ik al zei:

Maar een manier lijkt mij om de optie via een environment variabele in te schakelen en alleen toe te passen op interactive terminals (en dus niet in scripts).

Waarom zou dit idee omgezet moeten worden in (concept) code om te laten zien dat het kan werken?
Bovendien heb ik hierboven net aangegeven waarom ik vind dat ik niet de bewijslast omdraai en heb ik volgens mij niet een keer wellus gezegd.

[ Voor 24% gewijzigd door Olaf van der Spek op 31-10-2004 23:28 ]

[Zwerver]

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

Zoals ik al zei:

[...]

Waarom zou dit idee omgezet moeten worden in (concept) code om te laten zien dat het kan werken?
Bovendien heb ik hierboven net aangegeven waarom ik vind dat ik niet de bewijslast omdraai en heb ik volgens mij niet een keer wellus gezegd.

Omdat jij beweert dat je op die manier backwards compatible bent en mensen met kennis van de shell (blaataaps, CyBeR, dawuss e.d.) heel duidelijk aangeven dat dit niet waar is. Sowieso is het nou eenmaal zo dat je een bewering dient te staven.
Nee je hebt geen wellus gezegt, maar je probeerd wel uit alle macht je zin te krijgen en dus vragen we nu om een proof of concept. Kan je die niet geven dan slaat je bewering dus nergens op. Net zo goed dat als bijv. ik moet aantonen dat mijn buurman idd zijn eigen tv gejat heeft om de verzekering te liften.

Nog even over die env vars. Dat houd dus in dat je een script kan hebben wat je hele dir leeggooit en je het dus alleen voor de onhandige gebruiker aanpast. Niet werkbaar dus

[ Voor 9% gewijzigd door Zwerver op 31-10-2004 23:55 ]

[Olaf van der Spek]

Zwerver schreef op 31 oktober 2004 @ 23:54:
Omdat jij beweert dat je op die manier backwards compatible bent en mensen met kennis van de shell (blaataaps, CyBeR, dawuss e.d.) heel duidelijk aangeven dat dit niet waar is. Sowieso is het nou eenmaal zo dat je een bewering dient te staven.

Ik heb na mijn post van zondag 31 oktober 2004 21:36 waarin ik het heb over een idee voor een concrete implementatie nog geen post van een van hen gezien.

Nee je hebt geen wellus gezegt, maar je probeerd wel uit alle macht je zin te krijgen en dus vragen we nu om een proof of concept. Kan je die niet geven dan slaat je bewering dus nergens op.

Welke bewering?
Volgens mij heb ik nergens gezegd dat ik zeker weet dat het wel backwards compatible kan.

Nog even over die env vars. Dat houd dus in dat je een script kan hebben wat je hele dir leeggooit en je het dus alleen voor de onhandige gebruiker aanpast. Niet werkbaar dus

Voor de handige gebruiker was het toch geen probleem?

[ Voor 5% gewijzigd door Olaf van der Spek op 01-11-2004 00:23 ]

[Verwijderd]

@OlafvdSpek:

Waarom zou je in de naam der unix goden er voor willen zorgen dat de Shell anders reageert op een script dan op de input van de gebruiker.
Nou ik weet wel waarom niet.

Het idee van een script is dat het de taak van een admin/gebruiker over neemt. In essentie is het dus het idee dat het om de directe commando's gaat die de admin ook in zou typen.
Geen wonder dan ook dat veel scripts geboren worden via het commando history > blaat.sh
Dit omdat je wilt dat het script "precies" doet wat jij ook zou doen.
Elke en daarmee bedoel ik ELKE verandering tussen het uitvoeren van commando's van een admin in sequentie of een script, is dodelijk.
En dan mogelijk nog niet zozeer vanuit practiese reden als wel de gedachte die erachter zit.

Immers het script IS de gebruiker/admin, echter de admin/gebruiker is een goede admin/gebruike en dus te lui om zich met zulke zaken te bemoeien.

[Verwijderd]

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

Dus?

Dus dan heb je het misschien voor rm opgelost, maar zijn andere progs (die geen '-' als prefix gebruiken) nog steeds vatbaar voor dit soort spul. Of het moet zijn dat je een standaard wilt stellen dat alle progs '-' gebruiken..

edit:
ow.. 2 pagina's

[ Voor 9% gewijzigd door Verwijderd op 01-11-2004 07:47 ]

[Zwerver]

OlafvdSpek schreef op 01 november 2004 @ 00:19:
[...]

Ik heb na mijn post van zondag 31 oktober 2004 21:36 waarin ik het heb over een idee voor een concrete implementatie nog geen post van een van hen gezien.

Waarom denk je dat ze niet reageren? Omdat jij ubermachtig en alwetend bent? Of omdat ze zien dat jij toch je ongelijk niet zal willen toegeven... Soms hebben mensen wel de sociale vaardigheden om zich te ontrekken aan een discussie als ze zien dat de "tegenpartij" niet bereid is te luisteren naar argumenten.

[...]

Welke bewering?
Volgens mij heb ik nergens gezegd dat ik zeker weet dat het wel backwards compatible kan.


[...]

Dit geeft imho alleen maar aan dat je niet weet wat je zelf beweerd.

Voor de handige gebruiker was het toch geen probleem?

Zie wat Aapopfiets hierboven zegt. Je wil scripts geen andere env geven dan de user omdat scripts eigenlijk gewoon de taken overnemen van een user.

[Olaf van der Spek]

Verwijderd schreef op 01 november 2004 @ 01:01:
@OlafvdSpek:
Waarom zou je in de naam der unix goden er voor willen zorgen dat de Shell anders reageert op een script dan op de input van de gebruiker.
Nou ik weet wel waarom niet.

Het idee van een script is dat het de taak van een admin/gebruiker over neemt. In essentie is het dus het idee dat het om de directe commando's gaat die de admin ook in zou typen.
Geen wonder dan ook dat veel scripts geboren worden via het commando history > blaat.sh
Dit omdat je wilt dat het script "precies" doet wat jij ook zou doen.

Volgens mij werkt ~ ook niet in scripts, dus dat scripts en de command line equivalent zijn is nu al niet waar.
En als scripts last zouden hebben van deze bug/feature, zijn ze dan wel safe?

Zwerver schreef op 01 november 2004 @ 10:11:
Waarom denk je dat ze niet reageren? Omdat jij ubermachtig en alwetend bent? Of omdat ze zien dat jij toch je ongelijk niet zal willen toegeven... Soms hebben mensen wel de sociale vaardigheden om zich te ontrekken aan een discussie als ze zien dat de "tegenpartij" niet bereid is te luisteren naar argumenten.

Dat was de vraag niet.
Bovendien ben ik dus nog steeds op zoek naar argumenten waarom het (mijn idee met env en alleen interactive terminals) niet zou kunnen werken.

[ Voor 32% gewijzigd door Olaf van der Spek op 01-11-2004 10:19 ]

[blaataaps]

OlafvdSpek schreef op 01 november 2004 @ 10:14:
[...]

Volgens mij werkt ~ ook niet in scripts

Volgens mij wel, sterker nog, dat weet ik wel zeker, of de /bin/sh op freebsd heeft een "bug" dat het wel werkt.

dus dat scripts en de command line equivalent zijn is nu al niet waar.

er zijn inderdaad verschillen, die zijn er al jaren en die zijn bekend, het voorbeeld dat jij gaf is daar echter niet een van.

En als scripts last zouden hebben van deze bug/feature, zijn ze dan wel safe?

als ze zijn gemaakt door iemand die weet wat ie doet wel, sowieso moet je goed nadenken voor je een rm * of iets dergelijks in een script wil plakken.

[Olaf van der Spek]

blaataaps schreef op 01 november 2004 @ 10:20:
Volgens mij wel, sterker nog, dat weet ik wel zeker, of de /bin/sh op freebsd heeft een "bug" dat het wel werkt.

Hmm, daar zal ik nog eens naar kijken dan.

er zijn inderdaad verschillen, die zijn er al jaren en die zijn bekend, het voorbeeld dat jij gaf is daar echter niet een van.

Maar als je zelf een environment variabele zet om dit verschil aan te zetten, dan weet je dat toch ook?

als ze zijn gemaakt door iemand die weet wat ie doet wel, sowieso moet je goed nadenken voor je een rm * of iets dergelijks in een script wil plakken.

Cyber gaf als veilige versie rm ./*
Die versie heeft dus geen last van dit verschil.
Wat voor soort commando zou er wel last van hebben, maar toch veilig zijn?

[blaataaps]

OlafvdSpek schreef op 01 november 2004 @ 10:29:

Maar als je zelf een environment variabele zet om dit verschil aan te zetten, dan weet je dat toch ook?

mijn zin met "jouw voorbeeld" sloeg op het ~-verhaal, de discussie over het hele "-r"- verhaal heb ik niks meer aan bij te dragen en heb ik mijn mening over gegeven: wat mij betreft is het geen bug, is het logisch, gedocumenteerd en voorspelbaar, moet je extra voorzichtig zijn of het niet gebruiken als je bang bent voor dit soort problemen, en van bijna alles shells met deze feature is de source bekend, en ik houd niemand tegen het te patchen.

[Verwijderd]

find . -name '-*' | xargs rm -r

Is ook een optie !

[Erkens]

Verwijderd schreef op 01 november 2004 @ 12:32:
find . -name '-*' | xargs rm -r

Is ook een optie !

bedankt voor het lezen van het topic

[_JGC_]

OlafvdSpek schreef op 31 oktober 2004 @ 21:05:
[...]

Eh, sinds wanneer betekent alle, alle, behalve als de naam begint met een punt?

[...]

Waaorm niet?

Je hebt ook nog de directories "." en "..". Heel erg leuk:

code:

cd /tmp
rm -rf *

Vervolgens kan je zwaaien naar je systeem omdat ".." matcht op je wildcard, waardoor rm een dir hoger gaat en leuk je hele filesystem meeneemt. Is dat verwacht gedrag? Tuurlijk niet! Of het niet includen van bestanden die beginnen met een punt te maken heeft met bovenstaande, of dat bovenstaande op die manier is geimplementeerd vanwege het niet includen van dotfiles in een wildcard weet ik niet, maar ik zie er enige logica in.

[Olaf van der Spek]

_JGC_ schreef op 01 november 2004 @ 12:51:
Je hebt ook nog de directories "." en "..". Heel erg leuk:

code:

cd /tmp
rm -rf *

Vervolgens kan je zwaaien naar je systeem omdat ".." matcht op je wildcard, waardoor rm een dir hoger gaat en leuk je hele filesystem meeneemt. Is dat verwacht gedrag? Tuurlijk niet! Of het niet includen van bestanden die beginnen met een punt te maken heeft met bovenstaande, of dat bovenstaande op die manier is geimplementeerd vanwege het niet includen van dotfiles in een wildcard weet ik niet, maar ik zie er enige logica in.

Natuurlijk, ik ook. Ik wilde alleen maar duidelijk maken dat * dus niet alle betekent.

[Verwijderd]

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.

Oh, zo. Nee, maar kijk, dan is het (vind ik dan) een theoretisch probleem met een niet al-te-grote praktische impact. De door jou en mij aangehaalde probleemgevallen zijn grotendeels theoretisch van aard, als in: dat zal in de praktijk niet snel gebeuren. In de door anderen aangehaalde gevallen is er sowieso al iets mis met de beveiliging (bv. r/w-for-all), en dan is dit niet meer dan een grappig geintje, een soort bonus voor als je toch al te ver in het systeem bent doorgedrongen.

Niet dat ik dit gedrag zo geweldig vind, er kan vast wel 't een en ander aan verbeterd worden... .

[edit]
Trouwens, nog even aan olafvdspek. Vergeet je niet dat het gedrag van rm en dergelijke tools grotendeels is beschreven in standaarden als UNIX en POSIX? als iedereen maar wat aanklooide met die utilities, was compatibility binnen UNIX-like varianten een grote teringzooi.

[ Voor 14% gewijzigd door Verwijderd op 01-11-2004 14:42 ]

[Olaf van der Spek]

Verwijderd schreef op 01 november 2004 @ 14:39:
Trouwens, nog even aan olafvdspek. Vergeet je niet dat het gedrag van rm en dergelijke tools grotendeels is beschreven in standaarden als UNIX en POSIX? als iedereen maar wat aanklooide met die utilities, was compatibility binnen UNIX-like varianten een grote teringzooi.

Dat was ik inderdaad vergeten, maar ik stelde een optionele verandering van de shell voor. Aan utilities hoeft dus niks veranderd te worden.

[Zwerver]

De shell zit ook al jaren met dat gedrag. Dus ook de shell veranderen is het veranderen van de UNIX en POSIX standaarden