Re: [Pharo-project] FileURL don't works properly on windows
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 -- Marcus Denker -- http://marcusdenker.de
On 27 March 2012 18:18, Marcus Denker <marcus.denker@inria.fr> 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.
Give filesystem disparities I'd personally be happy with file://Pharo/xyz.abc resolving to C:\Pharo\xyz.abc on Windows... Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> 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 <marcus.denker@inria.fr> 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.
On 27 March 2012 19:50, Gary Chambers <gazzaguru2@btinternet.com> 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" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> 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 <marcus.denker@inria.fr> 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.
Then again... if you want cleverness you do a link on archaic filesystems that can't do a proper root... Personally I'd like a URI/URL to work crossly on multiple platforms in a reasonable manner. Otherwise it is a pain to work with Linux/Windows transparently. Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Tuesday, March 27, 2012 6:55 PM Subject: Re: [Pharo-project] FileURL don't works properly on windows
On 27 March 2012 19:50, Gary Chambers <gazzaguru2@btinternet.com> 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" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> 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 <marcus.denker@inria.fr> 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.
On 27 March 2012 20:28, Gary Chambers <gazzaguru2@btinternet.com> wrote:
Then again... if you want cleverness you do a link on archaic filesystems that can't do a proper root...
Personally I'd like a URI/URL to work crossly on multiple platforms in a reasonable manner. Otherwise it is a pain to work with Linux/Windows transparently.
i am not opposed to have uniform url(s). just dont like ambiguous stuff.
Regards, Gary
----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Tuesday, March 27, 2012 6:55 PM
Subject: Re: [Pharo-project] FileURL don't works properly on windows
On 27 March 2012 19:50, Gary Chambers <gazzaguru2@btinternet.com> 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" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> 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 <marcus.denker@inria.fr> 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.
-- Best regards, Igor Stasenko.
Maybe an extra / there... else relative etc. Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> 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 <marcus.denker@inria.fr> 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.
participants (3)
-
Gary Chambers -
Igor Stasenko -
Marcus Denker