'open().each' doesn't close file

On Ruby 1.9.3 (win7(64))

Because code says more the thousand words:
##################
open(“test.txt”,“r”).each do end # doesn’t close file
FileUtils.rm “test.txt” # will fail: Permission denied
##################
(it doesn’t matter if the “do end” is filled or omitted)

Bug, ‘Feature’ or my mistake?

On Sun, Dec 4, 2011 at 1:47 PM, Mc Ben [email protected] wrote:

On Ruby 1.9.3 (win7(64))

Because code says more the thousand words:
##################
open(“test.txt”,“r”).each do end # doesn’t close file
FileUtils.rm “test.txt” # will fail: Permission denied
##################
(it doesn’t matter if the “do end” is filled or omitted)

Bug, ‘Feature’ or my mistake?

open will only close if you pass it a block directly.

open(‘test.txt’){|file| file.each{ … } }

On Sun, Dec 4, 2011 at 08:19, Michael F. [email protected]
wrote:

On Sun, Dec 4, 2011 at 1:47 PM, Mc Ben [email protected] wrote:

open(“test.txt”,“r”).each do end # doesn’t close file
FileUtils.rm “test.txt” # will fail: Permission denied

open will only close if you pass it a block directly.

open(‘test.txt’){|file| file.each{ … } }

So just “do end” doesn’t count as a block? Seems (at least to me)
like it should, albeit not usually a very useful one…

-Dave

Mc Ben wrote in post #1035008:
Bug, ‘Feature’ or my mistake?

It works fine for me. Check the permissions for the directory:
ls -ld /some/dir

Maybe there’s no x bit set on the directory. It seems weird to me
that you’d get a Permissions error for something else.

Let me know,

-Luke

On 12/04/2011 06:27 PM, Dave A. wrote:

So just “do end” doesn’t count as a block? Seems (at least to me)
like it should, albeit not usually a very useful one…

In your case, the “do end” block is passed to the #each call, not to the
#open call.

luke gruber wrote in post #1035101:

Mc Ben wrote in post #1035008:
Bug, ‘Feature’ or my mistake?

It works fine for me. Check the permissions for the directory:
ls -ld /some/dir

Maybe there’s no x bit set on the directory. It seems weird to me
that you’d get a Permissions error for something else.

The OP was using Windoze.

Hi

I was just going through various concepts fo Ruby and found one
interesting (but not so usefulin real world) concept of Ruby, i.e. catch
and throw

I tried on of the example in the book…

def dothings( aNum )
i = 0
while true
puts( “I’m doing things…” )
throw( :go_for_tea ) if (i == aNum )
end
end
catch( :go_for_tea ){ puts “caught here”}
dothings(0)

The above code gives meoutput as ::

caught here…
i’m doing things…
throw: uncaught throw ‘go_for_tea’ (Name Error)

I have 2 doubts here

1.Why is there an error at the end
2. Why “caught here” is printed before the method is called?

Thanks.

Regards

Ankush

On Sun, Dec 4, 2011 at 21:47, Joel VanderWerf [email protected]
wrote:

In your case, the “do end” block is passed to the #each call, not to the
#open call.

D’oh! You’re right, sorry, I glossed right over that. That must be
why the “directly” in the previous message, as opposed this being
indirect…

-Dave

On Mon, Dec 5, 2011 at 10:54 PM, Ankush Ganatra
[email protected]wrote:

while true
i’m doing things…
Thanks.

Regards

Ankush

You got this out of a book? I’d be hesitant to continue learning from it
(convention is 2 spaces for indentation, aNum should be a_num or
better
yet number or maybe even integer depending on intent, the i=0 does
nothing, and if aNum isn’t zero, it will get caught in an infinite loop)

Anyway, it works this way because the catch block is executed first. If
the
catch block had thrown the symbol, it would have been caught. But it
didn’t
throw the symbol, so it continued execution. Then, outside of the block,
when dothings(0) is called, it prints the statement then throws the
symbol. But this doesn’t happen in a catch block, so it goes uncaught
and
ultimately raises an error.

Run it with these three locations to see the difference:

catch :go_for_tea do
dothings 0
puts “caught here”
dothings 0
end
dothings 0

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs