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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K Sent: Wednesday, June 23, 2010 4:05 PM To: Pharo-project@lists.gforge.inria.fr 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 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