OK, maybe I am going about things wrong.

But, it does seem strange that you can take a
perfectly valid pathname specification and expand
it and get the wrong answer!

I mean expanding a pathname starting with "~name"
should never give an error like "name" not found
when the dir contains a "~name" directory?

Chuck T.


Matthew Boeh wrote:
> On Sat, Jul 19, 2008 at 08:58:42AM +0900, C.E. Thornton wrote:
>   
>> Matthew,
>>
>>   Well something is inconsistent  somewhere.
>>
>>   However, the reason this came up was I
>> wrote a class to perform a tree scan.  It recursively
>> stepped through to directory tree.  It failed when
>> it ran across a directory that had a number of directories
>> prefixed with a  tilde '~'. 
>>
>> When you have a dir containing this
>>  dir1:
>>    ~dira  ~dirb  ~dirc
>>
>>  Then you list the 'files' in a dir and
>> then recursively call expand_path on each
>> dir you find and agin list the files--
>> this failure stops the scan.
>>     
>
> Why are you calling File.expand_path on these? The two uses of expand_path I'm 
> familiar with are to expand ~ and to resolve .. and ., neither of which seem 
> to apply in this case.
>
>   
>> I want to make it consistent with the way the
>> Bash Shell works.
>>
>> mkdir ~dir1   produces "./~dir" NOT "/home/dir"
>>     
>
> Only if there's no user named ~dir1. 
>
>   
>> Am I wrong here?
>>     
>
> No, but your patch removes the ~user -> /home/user behavior. A better fix to 
> match the Bourne shell behavior would be to get rid of the "user %s doesn't 
> exist" exception entirely and leave the string unchanged.
>
>   


-- 
Competency and chastity have much in common,
they both encompass their own punishment! 
 
-- C.E. Thornton -- Hawthorne Press --