API question: slashes and backslashes

Steve Borho steve at borho.org
Fri Jun 11 15:36:30 CDT 2010


On Fri, Jun 11, 2010 at 3:32 PM, Greg Ward <greg at gerg.ca> wrote:
> I'm hard at work trying to get bfiles working on Windows.  I think my
> biggest problem is that I just plain ignored the whole os.path.sep
> issue -- I take filenames from dirstate or manifest and pass them to
> the OS, and I naively expected filenames from the command line to make
> sense in dirstate tests.  The latter caused actual bugs, which I have
> crudely fixed with
>
>  filename.replace(os.path.sep, '/')
>
> in a few places, but that feels wrong.
>
> The other thing that feels wrong is passing paths like
>
>  c:\src\myproject/.hgbfiles/bigfile
>
> to the OS.  Lucky for me Windows handles those paths, but I feel like
> I'm skating on thin ice.  I generally get those sort of paths from
> repo.wjoin().
>
> What's the right way?  I've stumbled across util.pathto(), but it
> doesn't feel like a general solution -- e.g. it's fine for taking a
> path from the dirstate and generating an OS path, in certain
> circumstances.  Consider this code, a simplified excerpt from the
> 'bfremove' command (remove a big file as long as it's not modified):
>
>  modified1 = [...status of big files...]
>  modified2 = repo.status(...)
>  for standin in dirstate.walk(matcher):         # e.g. ".hgbfiles/foo/bar"
>    filename = _split_standin(filename)         # return "foo/bar"
>    if not (filename in modified1 or standin in modified2):
>      os.unlink(repo.wjoin(filename))
>
> modified1, modified2, standin, and filename all use Unix slash,
> because they are all based on dirstate.  But then I need an actual
> concrete filename that I can pass to os.unlink(), hence the
> repo.wjoin() call.  But that will return something like
>
>  c:\src\myproject\foo/bar
>
> which is where I feel like I'm skating on thin ice.  So what *should*
> I pass to repo.wjoin(), if not a filename from dirstate?

You should be aware of util.localpath() and util.pconvert()

-- 
Steve Borho


More information about the Mercurial-devel mailing list