That's interesting, though personally I'd rather just have something in
the core. I mean, we have Dir.tmpdir (in the tmpdir package). Why not
Dir.bitbucket?
Regards,
Dan
This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful. If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.
···
-----Original Message-----
From: Luke Kanies [mailto:luke@madstop.com]
Sent: Saturday, August 19, 2006 11:11 PM
To: ruby-talk ML
Subject: Re: Dir.bitbucket?
On Aug 19, 2006, at 11:34 PM, Daniel Berger wrote:
> Hi all,
>
> Occasionally I have to do something like this:
>
> bitbucket = RUBY_PLATFORM.match('mswin') ? 'NUL' : '/dev/null'
>
> How about a Dir.bitbucket method? Or Dir.null, or whatever you want
> to call it.
it's not quite the same thing, since it's not a part of the Ruby
core, but I've got a library, Facter[1], specifically meant to help
handle this kind of platform variety. This kind of simple
code would
look like this:
Facter.add :bitbucket do
setcode do
case Facter.operatingsystem
when /mswin/i: 'NUL'
when /amiga/i: 'NIL'
when /openvms/i: 'NL:'
else
'/dev/null'
end
end
end
And, since we're effectively looking for a write-only file, it seems
that it would be better to make the implementation pure Ruby and
platform independent, sort of like a StringIO without a string,
instead of on platform specific blackholes like /dev/null or the
others. Then it wouldn't need to change if and when a new platform
was to be supported.
And it would probably throw those bytes away even faster than if it
needed to talk to the OS!
···
On 8/21/06, Berger, Daniel <Daniel.Berger@qwest.com> wrote:
> -----Original Message-----
> From: Luke Kanies [mailto:luke@madstop.com]
> Sent: Saturday, August 19, 2006 11:11 PM
> To: ruby-talk ML
> Subject: Re: Dir.bitbucket?
>
> On Aug 19, 2006, at 11:34 PM, Daniel Berger wrote:
>
> > Hi all,
> >
> > Occasionally I have to do something like this:
> >
> > bitbucket = RUBY_PLATFORM.match('mswin') ? 'NUL' : '/dev/null'
> >
> > How about a Dir.bitbucket method? Or Dir.null, or whatever you want
> > to call it.
>
> it's not quite the same thing, since it's not a part of the Ruby
> core, but I've got a library, Facter[1], specifically meant to help
> handle this kind of platform variety. This kind of simple
> code would
> look like this:
>
> Facter.add :bitbucket do
> setcode do
> case Facter.operatingsystem
> when /mswin/i: 'NUL'
> when /amiga/i: 'NIL'
> when /openvms/i: 'NL:'
> else
> '/dev/null'
> end
> end
> end
<snip>
That's interesting, though personally I'd rather just have something in
the core. I mean, we have Dir.tmpdir (in the tmpdir package). Why not
Dir.bitbucket?
At Tue, 22 Aug 2006 02:21:05 +0900,
Rick DeNatale wrote in [ruby-talk:209686]:
And, since we're effectively looking for a write-only file, it seems
that it would be better to make the implementation pure Ruby and
platform independent, sort of like a StringIO without a string,
instead of on platform specific blackholes like /dev/null or the
others. Then it wouldn't need to change if and when a new platform
was to be supported.
It doesn't work with child processes, which would be expected
in many cases.
At Tue, 22 Aug 2006 02:21:05 +0900,
Rick DeNatale wrote in [ruby-talk:209686]:
And, since we're effectively looking for a write-only file, it seems
that it would be better to make the implementation pure Ruby and
platform independent, sort of like a StringIO without a string,
instead of on platform specific blackholes like /dev/null or the
others. Then it wouldn't need to change if and when a new platform
was to be supported.
It doesn't work with child processes, which would be expected
in many cases.
I guess I'm leaning towards Dir.null_device in terms of most technically descriptive. It doesn't quite roll off the tongue as nicely as "bitbucket", though.
At Tue, 22 Aug 2006 02:21:05 +0900,
Rick DeNatale wrote in [ruby-talk:209686]:
And, since we're effectively looking for a write-only file, it seems
that it would be better to make the implementation pure Ruby and
platform independent, sort of like a StringIO without a string,
instead of on platform specific blackholes like /dev/null or the
others. Then it wouldn't need to change if and when a new platform
was to be supported.
It doesn't work with child processes, which would be expected
in many cases.
I guess I'm leaning towards Dir.null_device in terms of most technically descriptive. It doesn't quite roll off the tongue as nicely as "bitbucket", though.
Regards,
Dan
--
to foster inner awareness, introspection, and reasoning is more efficient than
meditation and prayer.
- h.h. the 14th dali lama
I guess I'm leaning towards Dir.null_device in terms of most technically descriptive. It doesn't quite roll off the tongue as nicely as "bitbucket", though.
Agreed. File would be a better location for the it.
···
On 8/22/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
On Tue, 22 Aug 2006, Daniel Berger wrote:
> nobu@ruby-lang.org wrote:
>> Hi,
>>
>> At Tue, 22 Aug 2006 02:21:05 +0900,
>> Rick DeNatale wrote in [ruby-talk:209686]:
>>
>>> And, since we're effectively looking for a write-only file, it seems
>>> that it would be better to make the implementation pure Ruby and
>>> platform independent, sort of like a StringIO without a string,
>>> instead of on platform specific blackholes like /dev/null or the
>>> others. Then it wouldn't need to change if and when a new platform
>>> was to be supported.
>>>
>>
>> It doesn't work with child processes, which would be expected
>> in many cases.
>>
>> I wonder if the name bitbucket is nice.
>>
> Dir.bitbucket
> Dir.devnull
> Dir.null_device
> Dir.null
> Dir.black_hole
>
> I guess I'm leaning towards Dir.null_device in terms of most technically
> descriptive. It doesn't quite roll off the tongue as nicely as "bitbucket",
> though.
>
> Regards,
>
> Dan
why 'Dir' though? why not File?
-a
--
to foster inner awareness, introspection, and reasoning is more efficient than
meditation and prayer.
- h.h. the 14th dali lama
I guess I'm leaning towards Dir.null_device in terms of most technically descriptive. It doesn't quite roll off the tongue as nicely as "bitbucket", though.
How about:
oblivion = File.open(nil, 'w')
Seems intuitive.
For what definition of intuitive? nil is not a path, it's not even a string that could represent a path.
···
On Aug 22, 2006, at 1:36 PM, John Johnson wrote:
On Tue, 22 Aug 2006 01:56:17 -0400, Daniel Berger > <djberg96@gmail.com> wrote:
For what definition of intuitive? nil is not a path, it's not even a string that could represent a path.
Exactly.
What happens when you write to a nil file? Nothing.
You get an exception when you write to a nil file in ruby.
>> file = nil
=> nil
>> file.write "Whee"
NoMethodError: undefined method `write' for nil:NilClass
from (irb):2
Which is as it should be.
Where does the stuff go? Nowhere.
nil is not a file. It is also not "nowhere". (If it was nowhere, it would probably behave a bit more like Objective-C's nil). Even if it was nowhere, we would have all sorts of fun tracking down bugs where we meant to open a file ( a real file ) and forgot to check for nil earlier in the code. Our output would unintentionally disappear never to be seen again. Also the docs would be especially fun, "File.open takes a path to file and a mode, well sometimes it takes nil, which means open the platform specific 'bitbucket'".
Repurposing nil for this is not a good idea IMO. It reminds me of perl where writing to unopened file handles silently throws data away.
Oh yeah, it also doesn't have to be translated into 150 languages like 'bit bucket' would.
"bit bucket" is not the only possible name for this.
···
On Aug 22, 2006, at 10:37 PM, John Johnson wrote:
On Tue, 22 Aug 2006 17:44:42 -0400, Logan Capaldo > <logancapaldo@gmail.com> wrote:
