[#11073] segfault printing instruction sequence for iterator — <noreply@...>
Bugs item #10527, was opened at 2007-05-02 14:42
Hi,
On Thu, May 10, 2007 at 04:51:18PM +0900, Nobuyoshi Nakada wrote:
Hi,
Hi,
This seems to make valgrind much happier.
On Thu, May 17, 2007 at 11:14:35PM +0900, Paul Brannan wrote:
Hi,
Now 'a' shows up twice in the local table:
Hi,
[#11082] Understanding code: Kernel#require and blocks. — Hugh Sasse <hgs@...>
I'm trying to debug a Rails application which complains about an
On 5/4/07, Hugh Sasse <hgs@dmu.ac.uk> wrote:
On Fri, 4 May 2007, George wrote:
On Fri, May 04, 2007 at 06:18:19PM +0900, Hugh Sasse wrote:
[#11108] pattern for implementation-private constants? — David Flanagan <david@...>
Hi,
I believe there isn't a way, but I don't think it's really necessary. Just
[#11127] Bugs that can be closed — "Jano Svitok" <jan.svitok@...>
I propose closing these bugs as invalid:
[#11145] Rational comparison to 0 fails when denominator is != 1 — <noreply@...>
Bugs item #10739, was opened at 2007-05-10 22:06
Hi,
[#11169] Allow back reference with nest level in Oniguruma for Ruby again — =?ISO-8859-15?Q?Wolfgang_N=E1dasi-Donner?= <wonado@...>
Remark: I posted this text in comp.lang.ruby first, but Matz told me,
Does it make sense or is it required to write this as a RCR?
[#11176] FileUtils.rm_rf misfeature? — johan556@...
Hi!
[#11210] Pathname ascend and descend inclusive parameter — TRANS <transfire@...>
I would like to suggest that Pathname#ascend and Pathname#descend
[#11234] Planning to release 1.8.6 errata — Urabe Shyouhei <shyouhei@...>
Hi all.
On 25/05/07, Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:
[#11252] Init_stack and ruby_init_stack fail to reinit stack (threads problem?) — <noreply@...>
Bugs item #11134, was opened at 2007-05-25 12:14
Hi,
Nobuyoshi Nakada wrote:
[#11255] ruby_1_8_6 build problem (make install-doc) — johan556@...
Hi!
[#11271] providing better support through rubyforge tracker categories — Ryan Davis <ryand-ruby@...>
I'm going to make more categories for the trackers (bugs and patches)
[#11367] BUG: next in lambda: 1.8.6 differs from 1.8.4 and 1.9.0 — David Flanagan <david@...>
A toplevel next statement in a lambda does not return a value in 1.8.6,
[#11368] $2000 USD Reward for help fixing Segmentation Fault in GC — Brent Roman <brent@...>
Hi Brent,
Re: [ ruby-Bugs-8676 ] File.basename fails on Windows root paths
On 13/05/07, Nobuyoshi Nakada <nobu@ruby-lang.org> wrote:
> Hi,
>
> At Sun, 13 May 2007 02:07:13 +0900,
> Austin Ziegler wrote in [ruby-core:11161]:
> > On 5/12/07, Nobuyoshi Nakada <nobu@ruby-lang.org> wrote:
> > > At Fri, 16 Feb 2007 02:09:08 +0900,
> > > Daniel Berger wrote in [ruby-core:10321]:
> > > > The File.basename method does not work properly on Windows
> > > > root paths. IMO, calling File.basename on a root path should
> > > > return itself. However, on MS Windows it appears to be
> > > > dropping the volume name and it doesn't handle UNC root paths
> > > > correctly:
> > > Drive letter is part of base name? It feels very strange to me.
> >
> > It's right, though.
> >
> > File.basename("C:/") should return "C:/"
> > File.dirname("C:/") should return "C:/"
> > File.basename("//server/share/") must return "//server/share/"
> > File.dirname("//server/share/") must return "//server/share/"
>
> What's the reason? Do you consider a drive letter to be a part
> of basename?
>
> And if they were work so, then File.join(*File.split("C:/"))
> should return "C:/C:/", but it is incorrect on Windows. Is it
> what you want?
>
> > This would be true for any filesystem environment that allows multiple roots.
>
> Really? Do you know other such environments?
>
When you include some sort of networking into file path you usually
get multiple roots. In some cases this can be abstracted as single
root that includes the hostname but you would usually also get some
sort of shortcut for local files. Sure, systems that include such
things are either obscure or Windows.
I would the basename and dirname to preserve two invariants:
given
class String
def basename
File.basename self
end
def dirname
FIle.dirname self
end
end
I)
(s.dirname + File::SEPARATOR + s.basename) should refer to the same
file as (s) as long as neither s.dirname nor s.basename is empty. This
breaks with the concept of "current directory" in Windows.
II)
(s + File::SEPARATOR).dirname == s.dirname
(s + File::SEPARATOR).basename == s.basename
However, this cannot be preserved in cases when adding the separator
changes path designation as understood by the OS ( "C:" is not the
same as "C:/" but "C:/a" and "C:/a/" hopefully is).
III)
s.dirname should be "" only if s does not contain directory specification.
On unix directory specification is only File::SEPARATOR but on Windows
"C:" alone is also a directory specification but does not contain any
separator.
s.basename should not be empty nor the separator. But "C:" is a
directory specification which cannot be split. "C:".dirname must be
"C:" to specify the directory, and "C:".basename must be "", "." would
not work ( "C:" + "/" + ".") is something else.
The same goes for "C:/" and unix "/" except "." or "/" would be
probably an acceptable basename as well. We might specify that
basename for roots is "" which would solve all cases in POSIX and
Windows.
Still the windows programmer must be careful and check for empty
basename while the unix programmer does not have to.
Also there is the case "C:file" which refers to file in the current
directory on C. This cannot be reasonably split so that adding the
separator would yield the same result. It might work if "C:." and
"C:./file" are valid and do the expected thing.
Thanks
Michal