/u/31090/bla.png?f=community)
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.
/u/34216/avatar-60x60.png?f=community){kind=avatar}
/u/24089/evilbonzi-eye-dawuss-v2.png?f=community)
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
micheljansen.org
Fulltime Verslaafde Commandline Fetisjist ©
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 ]
micheljansen.org
Fulltime Verslaafde Commandline Fetisjist ©
Omdat een enkele topicstarter zich dit bedacht, en er een handjevol mensen hier over speculeert?
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:
:
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"
micheljansen.org
Fulltime Verslaafde Commandline Fetisjist ©
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
Hier keer je de bewijslast om
Kun jij een manier bedenken waarop het nog wel backwards compatible werkt? Ik niet namelijk
micheljansen.org
Fulltime Verslaafde Commandline Fetisjist ©
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.:
[...]
Hier keer je de bewijslast om
Kun jij een manier bedenken waarop het nog wel backwards compatible werkt? Ik niet namelijk
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
Jij claimt toch dat het niet kan?:
Hier keer je de bewijslast om
Kun jij een manier bedenken waarop het nog wel backwards compatible werkt? Ik niet namelijk
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 ]
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.
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.
:strip_icc():strip_exif()/u/22646/crop6531f78f6a5cb_cropped.jpg?f=community)
Woonachtig Down Under. Ik negeer je insults niet, maar tegen de tijd dat ik ze lees zijn ze meestal niet relevant meer
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.:
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.
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.
Woonachtig Down Under. Ik negeer je insults niet, maar tegen de tijd dat ik ze lees zijn ze meestal niet relevant meer
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 ]
Woonachtig Down Under. Ik negeer je insults niet, maar tegen de tijd dat ik ze lees zijn ze meestal niet relevant meer
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.
Welke bewering?
Volgens mij heb ik nergens gezegd dat ik zeker weet dat het wel backwards compatible kan.
Voor de handige gebruiker was het toch geen probleem?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 5% gewijzigd door Olaf van der Spek op 01-11-2004 00:23 ]
Verwijderd
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
ow.. 2 pagina's
[ Voor 9% gewijzigd door Verwijderd op 01-11-2004 07:47 ]
Woonachtig Down Under. Ik negeer je insults niet, maar tegen de tijd dat ik ze lees zijn ze meestal niet relevant meer
:strip_icc():strip_exif()/u/43473/crop5e12eeae6a054_cropped.jpeg?f=community)
Verwijderd
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 ]
Woonachtig Down Under. Ik negeer je insults niet, maar tegen de tijd dat ik ze lees zijn ze meestal niet relevant meer