Shouldn't Dir.mkdir support something akin to unix's mkdir -p ? i.e.,
Dir.mkdir("a/b/c") should make a, then a/b, then a/b/c if the right
option is passed in.
martin
Martin DeMello wrote:
Shouldn't Dir.mkdir support something akin to unix's mkdir -p ? i.e.,
Dir.mkdir("a/b/c") should make a, then a/b, then a/b/c if the right
option is passed in.
This is in FileUtils or something. I forget exactly where.
Hal
Hi,
···
In message "mkdir -p" on 04/06/14, Martin DeMello <martindemello@yahoo.com> writes:
Shouldn't Dir.mkdir support something akin to unix's mkdir -p ? i.e.,
Dir.mkdir("a/b/c") should make a, then a/b, then a/b/c if the right
option is passed in.
FileUtils.mkdir_p(path)
matz.
FileUtils#mkdir_p(path)
HTH
···
* Hal Fulton <hal9000@hypermetrics.com> wrote:
Shouldn't Dir.mkdir support something akin to unix's mkdir -p ? i.e.,
Dir.mkdir("a/b/c") should make a, then a/b, then a/b/c if the right
option is passed in.This is in FileUtils or something. I forget exactly where.
Thanks. Why doesn't FileUtils mix this into Dir?
martin
···
Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
Hi,
In message "mkdir -p" > on 04/06/14, Martin DeMello <martindemello@yahoo.com> writes:
>Shouldn't Dir.mkdir support something akin to unix's mkdir -p ? i.e.,
>Dir.mkdir("a/b/c") should make a, then a/b, then a/b/c if the right
>option is passed in.FileUtils.mkdir_p(path)
Merci.
martin
···
Hynek Schlawack <hynek+usenet@hys.in-berlin.de> wrote:
* Hal Fulton <hal9000@hypermetrics.com> wrote:
>> Shouldn't Dir.mkdir support something akin to unix's mkdir -p ? i.e.,
>> Dir.mkdir("a/b/c") should make a, then a/b, then a/b/c if the right
>> option is passed in.
> This is in FileUtils or something. I forget exactly where.FileUtils#mkdir_p(path)
Hi,
···
In message "Re: mkdir -p" on 04/06/14, Martin DeMello <martindemello@yahoo.com> writes:
FileUtils.mkdir_p(path)
Thanks. Why doesn't FileUtils mix this into Dir?
Dir methods are one to one relationship to the system calls.
FileUtils are more abstract/higher level/uniformed way to operate on
files/directories.
matz.
This feels wrong to me - it goes back to the "closed classes" paradigm
of adding a module simply to store a bunch of high level functions. I
don't know if it's just me, but I'm *always* taken aback when something
I'm looking for turns up in FileUtils rather than attached to the object
it acts upon.
On the other hand, perhaps mkdir doesn't belong as part of Dir - perhaps
we should consider renaming FileUtils to FileSystem and aliasing it so
as not to break old code - FileSystem.mkdir just reads more rubyishly to
me.
martin
···
Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
Hi,
In message "Re: mkdir -p" > on 04/06/14, Martin DeMello <martindemello@yahoo.com> writes:
>> FileUtils.mkdir_p(path)
>
>Thanks. Why doesn't FileUtils mix this into Dir?Dir methods are one to one relationship to the system calls.
FileUtils are more abstract/higher level/uniformed way to operate on
files/directories.
>Thanks. Why doesn't FileUtils mix this into Dir?
Dir methods are one to one relationship to the system calls.
FileUtils are more abstract/higher level/uniformed way to operate on
files/directories.
This is a technical explanation, but not a reason...
I don't see a reason why this technical detail should not be hidden from a Ruby user.
Martin
Hi,
···
In message "Re: mkdir -p" on 04/06/15, martinankerl at eml dot cc <asdf@asdf.com> writes:
Dir methods are one to one relationship to the system calls.
FileUtils are more abstract/higher level/uniformed way to operate on
files/directories.This is a technical explanation, but not a reason...
It's a technical explanation and a design policy.
matz.
Hi,
In mail "Re: mkdir -p"
> >> FileUtils.mkdir_p(path)
> >
>
> >Thanks. Why doesn't FileUtils mix this into Dir?
One reason is that FileUtils's methods have different
characteristics from File/Dir.
* FileUtils methods accepts a path or a list of pathes.
* FileUtils methods accepts options.
Dir.mkdir_p accepts a list of pathes, but Dir.mkdir does not
accept a list... it's inconsistent.
On the other hand, perhaps mkdir doesn't belong as part of Dir - perhaps
we should consider renaming FileUtils to FileSystem and aliasing it so
as not to break old code - FileSystem.mkdir just reads more rubyishly to
me.
I don't think so, FileUtils is just a module.
FileSystem object is different beast.
Regards,
Minero Aoki
···
Martin DeMello <martindemello@yahoo.com> wrote:
It is important to keep high-level libraries high-level, and
low-level libraries low-level. When the two mix you get
a sort of pollution.
For example, OpenGL doesn't specify a windowing system, and
from the other side, applications generally don't manipulate
kernel space. These are extreme examples, but the concept
applies equally to Dir/FileUtils.
···
--- Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
Hi,
In message "Re: mkdir -p" > on 04/06/15, martinankerl at eml dot cc <asdf@asdf.com> writes:
>> Dir methods are one to one relationship to the system calls.
>> FileUtils are more abstract/higher level/uniformed way to operate on
>> files/directories.
>
>This is a technical explanation, but not a reason...It's a technical explanation and a design policy.
matz.
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/