Accessing external resources in a cross-platform way

> Let's say you want to resolve paths in a cross platform way
>
> Binaries @ 'MyExec'
> Libraries @ 'MyLib'
> SystemLibraries @ 'SystemLib'
> etc.
>
> then Binaries is
>
> In Windows: #( 'C:\Program Files\' 'C:\Archivos de Programa\' ...) "
> and all standard locations including translations "
> In UNIX: #('/usr/bin/' '/usr/local/bin' ....) " and all standard locations "
> etc
>
> Now you may say it is necessary to scan all directories to find
> MyExec, yes but you may then save that location
>
> myBinaryLocation := Binaries @ 'MyExec'.
>
> so you scan for it just once.
>
> What do you think? it is already implemented anywhere?
> If not what package do you think is more suitable or prepared for
> implementing it?

> On Fri, Jan 28, 2011 at 01:51:22PM +0100, Hern??n Morales Durand wrote:
>> Let's say you want to resolve paths in a cross platform way
>>
>> Binaries @ 'MyExec'
>> Libraries @ 'MyLib'
>> SystemLibraries @ 'SystemLib'
>> etc.
>>
>> then Binaries is
>>
>> In Windows: #( 'C:\Program Files\' 'C:\Archivos de Programa\' ...) "
>> and all standard locations including translations "
>> In UNIX: #('/usr/bin/' '/usr/local/bin' ....) " and all standard locations "
>> etc
>>
>> Now you may say it is necessary to scan all directories to find
>> MyExec, yes but you may then save that location
>>
>> myBinaryLocation := Binaries @ 'MyExec'.
>>
>> so you scan for it just once.
>>
>> What do you think? it is already implemented anywhere?
>> If not what package do you think is more suitable or prepared for
>> implementing it?
>
> Hern??n,
>
> This is of course very platform dependent, and it is more complex
> than you might expect due to differences in file systems, operating
> systems, volume names (windows), environment variables and search
> path conventions.
>
> Both Windows and Unix use various seach paths accessible through
> environment variables, and the conventions for this tend to change
> over time with different OS versions. So it would probably be best
> to rely directly on those environment variables for identifying
> search paths.
>
> Aside from the conventions for default locations and search paths,
> some of what you are looking for may also be implemented for Windows
> and Unix in SqS/CommandShell in class ShellSyntax:
>
>   My instances implement parsing of strings in a manner similar to
>   a simple Unix command shell. I provide path name expansion in the
>   context of an external file system, and support the syntax required
>   for IO redirection. All file name globbing and PATH searching are
>   implemented in Smalltalk rather than in C library functions or an
>   external command shell.
>
>   Most of my syntax is applicable for any operating system. Where
>   needed, platform specific methods are in my "platform dependent"
>   category. Currently, Unix and Windows are supported, and other
>   platforms have not been tested. The primary difference between
>   Unix and Windows support is that device names (such as 'C:') are
>   used in Windows path strings. Separate current working directory
>   strings are maintained for all Windows device names. For Unix,
>   a single current working directory path is used. On Windows,
>   this permits the CommandShell 'cd' command to support changing
>   directories to another device without losing track of the current
>   working directory for the previous device.
>
>   Command pipeline syntax is not supported here. See CommandShell
>   for the implementation of command pipelines.
>
> Dave
>
>
>

> I've just implemented an initial release on top of FileSystem and
> ProcessWrapper (it uses some bit of Grease too). This is how it works
> in Windows:
>
> ( FSLocator sysEnvBinaries / 'notepad.exe' ) resolve "
> C:\WINDOWS\system32\notepad.exe "
> ( FSLocator sysEnvBinaries / 'X264VFW.DLL' ) resolve "
> C:\WINDOWS\system32\X264VFW.DLL "
> ( FSLocator userBinaries / 'excel.exe' ) resolve " C:\Archivos de
> programa\Microsoft Office\OFFICE11\EXCEL.EXE "
> ( FSLocator userBinaries / 'firefox.exe' ) resolve " C:\Archivos de
> programa\Mozilla Firefox\firefox.exe"
>
> So #sysEnvBinaries search in the OS PATH environment variable
> locations (which is usually pretty fast) and #userBinaries in the
> "program files" locations (it could be slow depending the amount of
> entries). It's only tested under Windows, IIRC user binaries in Unix
> are inside "/usr/local/bin" but you may tweak it to other locations, I
> have no access to a Unix or MacOS. Feel free to suggest or add any
> enhacements you like.
> Cheers,
>
> Hernán
>
> 2011/1/28 Colin Putney <[hidden email]>:
>> On Fri, Jan 28, 2011 at 9:17 AM, Hernán Morales Durand
>> <[hidden email]> wrote:
>>> Thanks David,
>>>
>>> I've seen FileSystem package http://www.wiresong.ca/filesystem/
>>> it seems related in some way too
>>
>> Yes, FileSystem does attempt to provide a cross-platform way to
>> resolve paths that are system-dependent. It doesn't include a way to
>> search for executables, although that's a good feature idea. As David,
>> mentioned you probably want to get the value of the PATH environment
>> variable, and use that for your search. That will handle cross-host
>> differences as well as cross-platform issues.
>>
>> Colin
>>
>>
> <Fsextensions-hfm.2.mcz>

> Hernan
>
> I'm documenting and reorganizing and writing more tests for FS.
> I contacted colin several times but got no feedback. The version that we will integrate in Pharo is
> available at:
>        PharoTaskForces
>        if you want to integrate/publish your code there, then you are welcomed.
> We will do several rounds, probably integrate dale gemstone fixes, deprecate and change some api
> like workingDirectory returning a path and calling it workingDirectoryPath
> and push FS in Pharo. Of course, people may probably complain but we will do it.
>

> Stef
>
> On Feb 3, 2011, at 1:01 AM, Hernán Morales Durand wrote:
>
>> I've just implemented an initial release on top of FileSystem and
>> ProcessWrapper (it uses some bit of Grease too). This is how it works
>> in Windows:
>>
>> ( FSLocator sysEnvBinaries / 'notepad.exe' ) resolve  "
>> C:\WINDOWS\system32\notepad.exe "
>> ( FSLocator sysEnvBinaries / 'X264VFW.DLL' ) resolve  "
>> C:\WINDOWS\system32\X264VFW.DLL "
>> ( FSLocator userBinaries / 'excel.exe' ) resolve              " C:\Archivos de
>> programa\Microsoft Office\OFFICE11\EXCEL.EXE "
>> ( FSLocator userBinaries / 'firefox.exe' ) resolve            " C:\Archivos de
>> programa\Mozilla Firefox\firefox.exe"
>>
>> So #sysEnvBinaries search in the OS PATH environment variable
>> locations (which is usually pretty fast) and #userBinaries in the
>> "program files" locations (it could be slow depending the amount of
>> entries). It's only tested under Windows, IIRC user binaries in Unix
>> are inside "/usr/local/bin" but you may tweak it to other locations, I
>> have no access to a Unix or MacOS. Feel free to suggest or add any
>> enhacements you like.
>> Cheers,
>>
>> Hernán
>>
>> 2011/1/28 Colin Putney <[hidden email]>:
>>> On Fri, Jan 28, 2011 at 9:17 AM, Hernán Morales Durand
>>> <[hidden email]> wrote:
>>>> Thanks David,
>>>>
>>>> I've seen FileSystem package http://www.wiresong.ca/filesystem/
>>>> it seems related in some way too
>>>
>>> Yes, FileSystem does attempt to provide a cross-platform way to
>>> resolve paths that are system-dependent. It doesn't include a way to
>>> search for executables, although that's a good feature idea. As David,
>>> mentioned you probably want to get the value of the PATH environment
>>> variable, and use that for your search. That will handle cross-host
>>> differences as well as cross-platform issues.
>>>
>>> Colin
>>>
>>>
>> <Fsextensions-hfm.2.mcz>
>
>
>

>> Hernan
>>
>> I'm documenting and reorganizing and writing more tests for FS.
>> I contacted colin several times but got no feedback. The version that we will integrate in Pharo is
>> available at:
>>        PharoTaskForces
>>        if you want to integrate/publish your code there, then you are welcomed.
>> We will do several rounds, probably integrate dale gemstone fixes, deprecate and change some api
>> like workingDirectory returning a path and calling it workingDirectoryPath
>> and push FS in Pharo. Of course, people may probably complain but we will do it.
>>
>
>
> How about using open repo.. not pharo-specific?
>
> MCHttpRepository
>    location: 'http://www.squeaksource.com/fs'
>    user: ''
>    password: ''
>
> I see that FS is quite easy to port over forks/dialects.
> So, with some effort we can make it easily available across many
> smalltalk platforms.
> It will benefit not only Pharo (yes, Pharo could be a testbed for new
> filesystem),
> but then if people will want to port it on another platform, they will
> have to just get in and start hacking there,
> without using controversial repository (PharoTaskForces) , because it
> means that this stuff is only for Pharo.
>
>> Stef
>>
>> On Feb 3, 2011, at 1:01 AM, Hernán Morales Durand wrote:
>>
>>> I've just implemented an initial release on top of FileSystem and
>>> ProcessWrapper (it uses some bit of Grease too). This is how it works
>>> in Windows:
>>>
>>> ( FSLocator sysEnvBinaries / 'notepad.exe' ) resolve  "
>>> C:\WINDOWS\system32\notepad.exe "
>>> ( FSLocator sysEnvBinaries / 'X264VFW.DLL' ) resolve  "
>>> C:\WINDOWS\system32\X264VFW.DLL "
>>> ( FSLocator userBinaries / 'excel.exe' ) resolve              " C:\Archivos de
>>> programa\Microsoft Office\OFFICE11\EXCEL.EXE "
>>> ( FSLocator userBinaries / 'firefox.exe' ) resolve            " C:\Archivos de
>>> programa\Mozilla Firefox\firefox.exe"
>>>
>>> So #sysEnvBinaries search in the OS PATH environment variable
>>> locations (which is usually pretty fast) and #userBinaries in the
>>> "program files" locations (it could be slow depending the amount of
>>> entries). It's only tested under Windows, IIRC user binaries in Unix
>>> are inside "/usr/local/bin" but you may tweak it to other locations, I
>>> have no access to a Unix or MacOS. Feel free to suggest or add any
>>> enhacements you like.
>>> Cheers,
>>>
>>> Hernán
>>>
>>> 2011/1/28 Colin Putney <[hidden email]>:
>>>> On Fri, Jan 28, 2011 at 9:17 AM, Hernán Morales Durand
>>>> <[hidden email]> wrote:
>>>>> Thanks David,
>>>>>
>>>>> I've seen FileSystem package http://www.wiresong.ca/filesystem/
>>>>> it seems related in some way too
>>>>
>>>> Yes, FileSystem does attempt to provide a cross-platform way to
>>>> resolve paths that are system-dependent. It doesn't include a way to
>>>> search for executables, although that's a good feature idea. As David,
>>>> mentioned you probably want to get the value of the PATH environment
>>>> variable, and use that for your search. That will handle cross-host
>>>> differences as well as cross-platform issues.
>>>>
>>>> Colin
>>>>
>>>>
>>> <Fsextensions-hfm.2.mcz>
>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

> Stef
>
>>> Hernan
>>>
>>> I'm documenting and reorganizing and writing more tests for FS.
>>> I contacted colin several times but got no feedback. The version that we will integrate in Pharo is
>>> available at:
>>>        PharoTaskForces
>>>        if you want to integrate/publish your code there, then you are welcomed.
>>> We will do several rounds, probably integrate dale gemstone fixes, deprecate and change some api
>>> like workingDirectory returning a path and calling it workingDirectoryPath
>>> and push FS in Pharo. Of course, people may probably complain but we will do it.
>>>
>>
>>
>> How about using open repo.. not pharo-specific?
>>
>> MCHttpRepository
>>    location: 'http://www.squeaksource.com/fs'
>>    user: ''
>>    password: ''
>>
>> I see that FS is quite easy to port over forks/dialects.
>> So, with some effort we can make it easily available across many
>> smalltalk platforms.
>> It will benefit not only Pharo (yes, Pharo could be a testbed for new
>> filesystem),
>> but then if people will want to port it on another platform, they will
>> have to just get in and start hacking there,
>> without using controversial repository (PharoTaskForces) , because it
>> means that this stuff is only for Pharo.
>>
>>> Stef
>>>
>>> On Feb 3, 2011, at 1:01 AM, Hernán Morales Durand wrote:
>>>
>>>> I've just implemented an initial release on top of FileSystem and
>>>> ProcessWrapper (it uses some bit of Grease too). This is how it works
>>>> in Windows:
>>>>
>>>> ( FSLocator sysEnvBinaries / 'notepad.exe' ) resolve  "
>>>> C:\WINDOWS\system32\notepad.exe "
>>>> ( FSLocator sysEnvBinaries / 'X264VFW.DLL' ) resolve  "
>>>> C:\WINDOWS\system32\X264VFW.DLL "
>>>> ( FSLocator userBinaries / 'excel.exe' ) resolve              " C:\Archivos de
>>>> programa\Microsoft Office\OFFICE11\EXCEL.EXE "
>>>> ( FSLocator userBinaries / 'firefox.exe' ) resolve            " C:\Archivos de
>>>> programa\Mozilla Firefox\firefox.exe"
>>>>
>>>> So #sysEnvBinaries search in the OS PATH environment variable
>>>> locations (which is usually pretty fast) and #userBinaries in the
>>>> "program files" locations (it could be slow depending the amount of
>>>> entries). It's only tested under Windows, IIRC user binaries in Unix
>>>> are inside "/usr/local/bin" but you may tweak it to other locations, I
>>>> have no access to a Unix or MacOS. Feel free to suggest or add any
>>>> enhacements you like.
>>>> Cheers,
>>>>
>>>> Hernán
>>>>
>>>> 2011/1/28 Colin Putney <[hidden email]>:
>>>>> On Fri, Jan 28, 2011 at 9:17 AM, Hernán Morales Durand
>>>>> <[hidden email]> wrote:
>>>>>> Thanks David,
>>>>>>
>>>>>> I've seen FileSystem package http://www.wiresong.ca/filesystem/
>>>>>> it seems related in some way too
>>>>>
>>>>> Yes, FileSystem does attempt to provide a cross-platform way to
>>>>> resolve paths that are system-dependent. It doesn't include a way to
>>>>> search for executables, although that's a good feature idea. As David,
>>>>> mentioned you probably want to get the value of the PATH environment
>>>>> variable, and use that for your search. That will handle cross-host
>>>>> differences as well as cross-platform issues.
>>>>>
>>>>> Colin
>>>>>
>>>>>
>>>> <Fsextensions-hfm.2.mcz>
>>>
>>>
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
>
>

> On 3 February 2011 10:45, Stéphane Ducasse <[hidden email]> wrote:
>> Ok I published everything to Filesystem which BTW was dead since 2004!
>>
>> Let us see what it will change.
>>
>
> Good.
> So let encourage people to use it as an OFFICIAL repository for
> Filesystem package.
>
>
>> Stef
>>
>>>> Hernan
>>>>
>>>> I'm documenting and reorganizing and writing more tests for FS.
>>>> I contacted colin several times but got no feedback. The version that we will integrate in Pharo is
>>>> available at:
>>>>        PharoTaskForces
>>>>        if you want to integrate/publish your code there, then you are welcomed.
>>>> We will do several rounds, probably integrate dale gemstone fixes, deprecate and change some api
>>>> like workingDirectory returning a path and calling it workingDirectoryPath
>>>> and push FS in Pharo. Of course, people may probably complain but we will do it.
>>>>
>>>
>>>
>>> How about using open repo.. not pharo-specific?
>>>
>>> MCHttpRepository
>>>    location: 'http://www.squeaksource.com/fs'
>>>    user: ''
>>>    password: ''
>>>
>>> I see that FS is quite easy to port over forks/dialects.
>>> So, with some effort we can make it easily available across many
>>> smalltalk platforms.
>>> It will benefit not only Pharo (yes, Pharo could be a testbed for new
>>> filesystem),
>>> but then if people will want to port it on another platform, they will
>>> have to just get in and start hacking there,
>>> without using controversial repository (PharoTaskForces) , because it
>>> means that this stuff is only for Pharo.
>>>
>>>> Stef
>>>>
>>>> On Feb 3, 2011, at 1:01 AM, Hernán Morales Durand wrote:
>>>>
>>>>> I've just implemented an initial release on top of FileSystem and
>>>>> ProcessWrapper (it uses some bit of Grease too). This is how it works
>>>>> in Windows:
>>>>>
>>>>> ( FSLocator sysEnvBinaries / 'notepad.exe' ) resolve  "
>>>>> C:\WINDOWS\system32\notepad.exe "
>>>>> ( FSLocator sysEnvBinaries / 'X264VFW.DLL' ) resolve  "
>>>>> C:\WINDOWS\system32\X264VFW.DLL "
>>>>> ( FSLocator userBinaries / 'excel.exe' ) resolve              " C:\Archivos de
>>>>> programa\Microsoft Office\OFFICE11\EXCEL.EXE "
>>>>> ( FSLocator userBinaries / 'firefox.exe' ) resolve            " C:\Archivos de
>>>>> programa\Mozilla Firefox\firefox.exe"
>>>>>
>>>>> So #sysEnvBinaries search in the OS PATH environment variable
>>>>> locations (which is usually pretty fast) and #userBinaries in the
>>>>> "program files" locations (it could be slow depending the amount of
>>>>> entries). It's only tested under Windows, IIRC user binaries in Unix
>>>>> are inside "/usr/local/bin" but you may tweak it to other locations, I
>>>>> have no access to a Unix or MacOS. Feel free to suggest or add any
>>>>> enhacements you like.
>>>>> Cheers,
>>>>>
>>>>> Hernán
>>>>>
>>>>> 2011/1/28 Colin Putney <[hidden email]>:
>>>>>> On Fri, Jan 28, 2011 at 9:17 AM, Hernán Morales Durand
>>>>>> <[hidden email]> wrote:
>>>>>>> Thanks David,
>>>>>>>
>>>>>>> I've seen FileSystem package http://www.wiresong.ca/filesystem/
>>>>>>> it seems related in some way too
>>>>>>
>>>>>> Yes, FileSystem does attempt to provide a cross-platform way to
>>>>>> resolve paths that are system-dependent. It doesn't include a way to
>>>>>> search for executables, although that's a good feature idea. As David,
>>>>>> mentioned you probably want to get the value of the PATH environment
>>>>>> variable, and use that for your search. That will handle cross-host
>>>>>> differences as well as cross-platform issues.
>>>>>>
>>>>>> Colin
>>>>>>
>>>>>>
>>>>> <Fsextensions-hfm.2.mcz>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>>
>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>

>
> 2011/2/3 Igor Stasenko <[hidden email]>:
>> On 3 February 2011 10:45, Stéphane Ducasse <[hidden email]> wrote:
>>> Ok I published everything to Filesystem which BTW was dead since 2004!
>>>
>>> Let us see what it will change.
>>>
>>
>> Good.
>> So let encourage people to use it as an OFFICIAL repository for
>> Filesystem package.
>>
>>
>>> Stef
>>>
>>>>> Hernan
>>>>>
>>>>> I'm documenting and reorganizing and writing more tests for FS.
>>>>> I contacted colin several times but got no feedback. The version that we will integrate in Pharo is
>>>>> available at:
>>>>>        PharoTaskForces
>>>>>        if you want to integrate/publish your code there, then you are welcomed.
>>>>> We will do several rounds, probably integrate dale gemstone fixes, deprecate and change some api
>>>>> like workingDirectory returning a path and calling it workingDirectoryPath
>>>>> and push FS in Pharo. Of course, people may probably complain but we will do it.
>>>>>
>>>>
>>>>
>>>> How about using open repo.. not pharo-specific?
>>>>
>>>> MCHttpRepository
>>>>    location: 'http://www.squeaksource.com/fs'
>>>>    user: ''
>>>>    password: ''
>>>>
>>>> I see that FS is quite easy to port over forks/dialects.
>>>> So, with some effort we can make it easily available across many
>>>> smalltalk platforms.
>>>> It will benefit not only Pharo (yes, Pharo could be a testbed for new
>>>> filesystem),
>>>> but then if people will want to port it on another platform, they will
>>>> have to just get in and start hacking there,
>>>> without using controversial repository (PharoTaskForces) , because it
>>>> means that this stuff is only for Pharo.
>>>>
>>>>> Stef
>>>>>
>>>>> On Feb 3, 2011, at 1:01 AM, Hernán Morales Durand wrote:
>>>>>
>>>>>> I've just implemented an initial release on top of FileSystem and
>>>>>> ProcessWrapper (it uses some bit of Grease too). This is how it works
>>>>>> in Windows:
>>>>>>
>>>>>> ( FSLocator sysEnvBinaries / 'notepad.exe' ) resolve  "
>>>>>> C:\WINDOWS\system32\notepad.exe "
>>>>>> ( FSLocator sysEnvBinaries / 'X264VFW.DLL' ) resolve  "
>>>>>> C:\WINDOWS\system32\X264VFW.DLL "
>>>>>> ( FSLocator userBinaries / 'excel.exe' ) resolve              " C:\Archivos de
>>>>>> programa\Microsoft Office\OFFICE11\EXCEL.EXE "
>>>>>> ( FSLocator userBinaries / 'firefox.exe' ) resolve            " C:\Archivos de
>>>>>> programa\Mozilla Firefox\firefox.exe"
>>>>>>
>>>>>> So #sysEnvBinaries search in the OS PATH environment variable
>>>>>> locations (which is usually pretty fast) and #userBinaries in the
>>>>>> "program files" locations (it could be slow depending the amount of
>>>>>> entries). It's only tested under Windows, IIRC user binaries in Unix
>>>>>> are inside "/usr/local/bin" but you may tweak it to other locations, I
>>>>>> have no access to a Unix or MacOS. Feel free to suggest or add any
>>>>>> enhacements you like.
>>>>>> Cheers,
>>>>>>
>>>>>> Hernán
>>>>>>
>>>>>> 2011/1/28 Colin Putney <[hidden email]>:
>>>>>>> On Fri, Jan 28, 2011 at 9:17 AM, Hernán Morales Durand
>>>>>>> <[hidden email]> wrote:
>>>>>>>> Thanks David,
>>>>>>>>
>>>>>>>> I've seen FileSystem package http://www.wiresong.ca/filesystem/
>>>>>>>> it seems related in some way too
>>>>>>>
>>>>>>> Yes, FileSystem does attempt to provide a cross-platform way to
>>>>>>> resolve paths that are system-dependent. It doesn't include a way to
>>>>>>> search for executables, although that's a good feature idea. As David,
>>>>>>> mentioned you probably want to get the value of the PATH environment
>>>>>>> variable, and use that for your search. That will handle cross-host
>>>>>>> differences as well as cross-platform issues.
>>>>>>>
>>>>>>> Colin
>>>>>>>
>>>>>>>
>>>>>> <Fsextensions-hfm.2.mcz>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Igor Stasenko AKA sig.
>>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>>
>
>