ConfigurationOfOSProcessCommandShell

> To get going again, I hacked FileDirectory>>fileExists: to answer true when passed '/bin/sh' and suddenly I can pipe again, so there has been some kind of change in testing for files.
>
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Schwab,Wilhelm K
> Sent: Wednesday, June 23, 2010 4:05 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] ConfigurationOfOSProcessCommandShell
>
> PipeableOSProcess is broken on Linux.  It appears to be because
>
>    FileDirectory default fileExists:'/bin/sh'
>
> is returning false in 1.1.  Any ideas?
>
> Bill

>  On 23.06.2010 23:13, Schwab,Wilhelm K wrote:
>> To get going again, I hacked FileDirectory>>fileExists: to answer
>> true when passed '/bin/sh' and suddenly I can pipe again, so there
>> has been some kind of change in testing for files.
>>
>>
>>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of
>> Schwab,Wilhelm K
>> Sent: Wednesday, June 23, 2010 4:05 PM
>> To: [hidden email]
>> Subject: Re: [Pharo-project] ConfigurationOfOSProcessCommandShell
>>
>> PipeableOSProcess is broken on Linux.  It appears to be because
>>
>>    FileDirectory default fileExists:'/bin/sh'
>>
>> is returning false in 1.1.  Any ideas?
>>
>> Bill
> Yes, it was changed to use the open file primitive instead of
> iterating over the entire directory contents, and making assumptions
> about filesystem case sensitivity which may or may not be correct.
> There's something funky going on with the sh link in Ubuntu 10.04...
> fileExists: '/bin/dash' (what sh links to) evaluates true
> I tested first with links on the desktops, worked just fine.
> Created another link to a file in /bin/, worked just fine.
> Created another link in /bin/, to another executable in /bin/,
> fileExists still returned true.
> Checked the permissions, they were the same.
> Deleted sh, created a new link to dash also called sh, that evaluated
> to true as well...
> I'm no expert on the Unix file system, really not sure what/if there
> is a wrong assumption in the modified method is...
>
> Reason it was changed in the first place, is documented at
> http://code.google.com/p/pharo/issues/detail?id=516
>
> Cheers,
> Henry

> On 24.06.2010 02:41, Henrik Sperre Johansen wrote:
>> On 23.06.2010 23:13, Schwab,Wilhelm K wrote:
>>> To get going again, I hacked FileDirectory>>fileExists: to answer true when passed '/bin/sh' and suddenly I can pipe again, so there has been some kind of change in testing for files.
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: [hidden email] [mailto:[hidden email]] On Behalf Of Schwab,Wilhelm K
>>> Sent: Wednesday, June 23, 2010 4:05 PM
>>> To: [hidden email]
>>> Subject: Re: [Pharo-project] ConfigurationOfOSProcessCommandShell
>>>
>>> PipeableOSProcess is broken on Linux.  It appears to be because
>>>
>>>   FileDirectory default fileExists:'/bin/sh'
>>>
>>> is returning false in 1.1.  Any ideas?
>>>
>>> Bill
>>
> Difference between the links was sh was relative (sh -> dash), while my replacement was absolute (sh -> /bin/dash).
> FilePlugin primitiveFileOpen opens the latter, but returns nil with the first, thus fileExists fails...
> I wrote a small c program simply opening sh with fopen, and that worked as expected, so there's probably an error in the wrapping plugin code somewhere :/
>
> Cheers,
> Henry

> On 24.06.2010 02:41, Henrik Sperre Johansen wrote:
>> On 23.06.2010 23:13, Schwab,Wilhelm K wrote:
>>> To get going again, I hacked FileDirectory>>fileExists: to answer true when passed '/bin/sh' and suddenly I can pipe again, so there has been some kind of change in testing for files.
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: [hidden email]
>>> [mailto:[hidden email]] On Behalf Of
>>> Schwab,Wilhelm K
>>> Sent: Wednesday, June 23, 2010 4:05 PM
>>> To: [hidden email]
>>> Subject: Re: [Pharo-project] ConfigurationOfOSProcessCommandShell
>>>
>>> PipeableOSProcess is broken on Linux.  It appears to be because
>>>
>>>   FileDirectory default fileExists:'/bin/sh'
>>>
>>> is returning false in 1.1.  Any ideas?
>>>
>>> Bill
>>
> Difference between the links was sh was relative (sh -> dash), while my replacement was absolute (sh -> /bin/dash).
> FilePlugin primitiveFileOpen opens the latter, but returns nil with the first, thus fileExists fails...
> I wrote a small c program simply opening sh with fopen, and that
> worked as expected, so there's probably an error in the wrapping
> plugin code somewhere :/
>
> Cheers,
> Henry