On 27 March 2012 19:50, Gary Chambers <[email protected]> wrote: > Give filesystem disparities I'd personally be happy with > > file://Pharo/xyz.abc > > resolving to > > C:\Pharo\xyz.abc > > on Windows...
unless you meant D:\Pharo\xyz.abc :) No. I don't like such implicit cleverness. Things should be stupid. No magic. If it works it should work. If it doesn't , it should explain why. And let users solve the issue. But when system tries to play a wizard which can read people's mind, this is road to nowhere. > > Regards, Gary > > ----- Original Message ----- From: "Igor Stasenko" <[email protected]> > To: <[email protected]> > Sent: Tuesday, March 27, 2012 6:41 PM > > Subject: Re: [Pharo-project] FileURL don't works properly on windows > > > On 27 March 2012 18:18, Marcus Denker <[email protected]> wrote: >> >> >> On Mar 27, 2012, at 6:06 PM, Igor Stasenko wrote: >> >>> this part is closely related to command-line arguments handling.. >>> >>> on windows things, which expected to work, like: >>> >>> vm image.image <pathToScript>.st >>> >>> fails to find the script, because it messing up with back/forward >>> slashes in path >>> and at the end it transforms an input into escaped slashes, which is >>> of course cannot be found in file system... >> >> >> >> right now we use Urls there because it supports to add URL as a "file". >> >> vm imageimage http://myscript.com/phato.st >> >> I personally think we should remove that. If you want to load a file via >> the network, just >> write a local script that does that. >> >> If we remove the network support for script parameters, we will directly >> solve that problem. >> (and we simplify the whole startup logic, and we make the startup not >> depend on networking). >> >> http://code.google.com/p/pharo/issues/detail?id=4057 >> >> Marcus >> > agree.. this thing is a bit overengineeeeered. > but in overall it is cool to have, unless it breaks a most basic usage > : hey ... a stupid file name passed as an argument! > > we can remove it, of course, but it won't make a FileURL a bit less broken.. > since things like that: > > 'c:\myfile.txt' asURL retrieveContents still won't work. > we should cover it by tests btw, since now we have windows.. > but in order to run any test(s) we should fix this thing first :) > >> >> -- >> Marcus Denker -- http://marcusdenker.de >> > > > > -- > Best regards, > Igor Stasenko. > > -- Best regards, Igor Stasenko.
