Unexpected behaviour in Pathname?

Ruby
1

I’m writing a quick script to selectively process some files, and I
found a bit of odd behaviour using Pathname#each and #each_entry,
which is best illustrated, rather than explained:

irb(main):001:0> require ‘pathname’
=> true
irb(main):002:0> p = Pathname.new("/home/matt/test")
=> #Pathname:/home/matt/test
irb(main):003:0> p.entries.each{ |q|
irb(main):004:1* puts “operating on: #{q.dirname}/#{q.basename}”
irb(main):005:1> }
operating on: ./.
operating on: ./…
operating on: ./a
operating on: ./b
operating on: ./c

Now, the problem that results is that in the block, I can’t do q.read
reliably (or indeed q.anything), because it’s looking for q relative
to the current directory, when surely it should be looking relative
to p.

Apart from files not being found if you’re not in the correct
directory, this could lead to more difficult-to-detect problems if
you have a structure like the following and run the script in a
directory which has identically-named files to the intended target,
for instance:

/home/matt/project/training/{1, 2, 3, 4, etc}
/home/matt/project/test/{1, 2, 3, 4, etc}

Since even when the directory to be processed is given as an absolute
pathname, its subdirectories are treated as relative pathnames.

I realise that I can solve this by doing (p + q).read inside the
block, but surely this isn’t the desired behaviour of Pathname#each?

thanks,
matthew smillie.

2

I’m writing a quick script to selectively process some files, and I
found a bit of odd behaviour using Pathname#each and #each_entry,
which is best illustrated, rather than explained:

Quick clarification: I do mean Pathname#entries rather than
Pathname#each.

Whoops.

3

In article [email protected],
Matthew S. [email protected] writes:

I realise that I can solve this by doing (p + q).read inside the
block, but surely this isn’t the desired behaviour of Pathname#each?

It is intended for consistency to Dir.entries.

Use Pathname#children instead.

Note that Pathname#children doesn’t generates “.” and “…”.
I hope you don’t need them.

4

hey everybody…

i need to get off this list. i will have limited access to this
account
for some time and i need tot turn off my lists. i tried “unsubscribe my
name” and send it to the list but it neither unsubscribed me nor showed
up
in the list. on the website i cant really see how to unsubscribe only
how to
subscribe!

\n

5

Tanaka A. wrote:

Note that Pathname#children doesn’t generates “.” and “…”.
I hope you don’t need them.

Another - possibly simpler - approach would be to use
Dir[’/home/matt/test/*’].

Kind regards

robert
6

Selon niels wolf [email protected]:

hey everybody…

i need to get off this list. i will have limited access to this account
for some time and i need tot turn off my lists. i tried “unsubscribe my
name” and send it to the list but it neither unsubscribed me nor showed up
in the list. on the website i cant really see how to unsubscribe only how to
subscribe!

You need to send the unsubscribe command to
mailto:[email protected],
as indicated in the e-mail you automatically received when you first
joined the
list :slight_smile: .

Christophe G…

http://rainbow.conlang.free.fr

It takes a straight mind to create a twisted conlang.

7

Hi,

In message “Re: unsubscribe… please…”
on Tue, 15 Nov 2005 23:15:52 +0900, “niels wolf” [email protected]
writes:

| i need to get off this list. i will have limited access to this account
|for some time and i need tot turn off my lists. i tried “unsubscribe my
|name” and send it to the list but it neither unsubscribed me nor showed up
|in the list. on the website i cant really see how to unsubscribe only how to
|subscribe!

You should have sent a command mail to ruby-talk-ctl. But I will remove
you manually.

						matz.