File::expand_path amok

ruby-talk
1

$ pwd
/

$ ruby -e ‘p File.expand_path(*ARGV)’ a/… b
\000\000 …
…
… so on so on… \000
…
\000\000

$ ruby -e ‘p File.expand_path(*ARGV).size’ a/… b
3680

$ ruby -v
ruby 1.8.0 (2003-04-11) [i386-freebsd4]

2

Hi,

···

At Mon, 14 Apr 2003 15:54:28 +0900, Ariff Abdullah wrote:

$ pwd
/

$ ruby -e ‘p File.expand_path(*ARGV)’ a/… b
\000\000 …
…
… so on so on… \000
…
\000\000

I couldn’t reproduce it on Linux. Does this gives same result?

$ ruby -e ‘p File.expand_path(*ARGV)’ b

–
Nobu Nakada

3

“Ariff Abdullah” skywizard@time.net.my wrote in message news:23a4e28989.2898923a4e@time.net.my…

$ pwd
/

$ ruby -e ‘p File.expand_path(*ARGV)’ a/… b
\000\000 …
…
… so on so on… \000
…
\000\000

$ ruby -e ‘p File.expand_path(*ARGV).size’ a/… b
3680

$ ruby -v
ruby 1.8.0 (2003-04-11) [i386-freebsd4]

Strange. This runs fine on my system, both on 1.6.8 and 1.8.0p2.
That said, I’ve looked at the code for File.expand_path, and wondered
why it didn’t make use of the C-library function ‘realpath’, when
available.

Cheers,

Han Holl

4

Hi,

···

At Mon, 14 Apr 2003 15:54:28 +0900, Ariff Abdullah wrote:

$ ruby -e ‘p File.expand_path(*ARGV)’ a/… b
\000\000 …
…
… so on so on… \000
…
\000\000

I hope this is fixed now.

–
Nobu Nakada

5

Strange. This runs fine on my system, both on 1.6.8 and 1.8.0p2.
That said, I've looked at the code for File.expand_path, and wondered
why it didn't make use of the C-library function 'realpath', when
available.

Well I don't know : perhaps because realpath() don't give the same result
on different systems. For example, BSD 4.4 always return an absolute path,
Solaris can return a relative path

Guy Decoux

6

Hi,

···

At Mon, 14 Apr 2003 19:57:50 +0900, Han Holl wrote:

That said, I’ve looked at the code for File.expand_path, and wondered
why it didn’t make use of the C-library function ‘realpath’, when
available.

File.expand_path doesn’t follow symbolic links, while
realpath() does.

–
Nobu Nakada

7

In that case, wouldn’t a wrapper around realpath be really
useful ? If you need to prevent double loading of resources,
realpath can be of value to hash on.

Han Holl

···

nobu.nokada@softhome.net wrote:

File.expand_path doesn’t follow symbolic links, while
realpath() does.

8

Hi,

···

At Tue, 15 Apr 2003 03:38:09 +0900, Han Holl wrote:

File.expand_path doesn’t follow symbolic links, while
realpath() does.

In that case, wouldn’t a wrapper around realpath be really
useful ? If you need to prevent double loading of resources,
realpath can be of value to hash on.

Sorry, but I can’t imagine how to preserve symlink names. And
realpath() returns an error at non-exist path, whereas
expand_path doesn’t. Wouldn’t a wrapper be bigger than the
current code?

And portability issue, of course.

–
Nobu Nakada