“If a block is given, it is yielded with the path of the directory.
The directory and its contents are removed using
FileUtils.remove_entry_secure before ::mktmpdir returns. The value of
the block is returned.”
“If a block is not given, The path of the directory is returned. In
this case, ::mktmpdir doesn’t remove the directory.”
so in your opinion should it remove the “temp dir” at exit, or not?
You need both options. The block form gives you automatic cleanup (as
the
block form of many things do). The non-block form is nice if you want to
manage your own temporary directories
Many methods in Ruby which deal with external resources
(File.open/Socket.open anyone?) have both a block form (that cleans
itself
up automatically) and a non-block form that requires manual cleanup
(e.g.
close your file descriptors, although the GC will eventually do it for
you if you can’t be bothered to do that)
This is no different.
It also closes file descriptors “at_exit” for you, which is what I
expected here.
Really what I’d expect here is for it to remove the directory “if empty”
at exit, but maybe that is too hard in windows, which disallows removing
non-empty directories? A pity if that’s why the inconsistency was
introduced.
Hmmm. IMO, the behaviour should be consistent, and not depend on whether
a block form was used.
“A foolish consistency is the hobgoblin of little minds”
Many methods in Ruby which deal with external resources
(File.open/Socket.open anyone?) have both a block form (that cleans
itself
up automatically) and a non-block form that requires manual cleanup
(e.g.
close your file descriptors, although the GC will eventually do it for
you if you can’t be bothered to do that)
It also closes file descriptors “at_exit” for you, which is what I
expected here.
Really what I’d expect here is for it to remove the directory “if
empty”
at exit, but maybe that is too hard in windows, which disallows
removing
non-empty directories? A pity if that’s why the inconsistency was
introduced.
Unixen don’t allow removal of non-empty directories as well.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.