path package should use \ on Windows?

[gopherbot]

by paulo.jpinto:

What steps will reproduce the problem?
package main

package main

import (
  "path"
  "fmt"
)

func main() {
    fmt.Println(path.Join("directory", "file"))
}

What is the expected output?

directory\file

What do you see instead?

directory/file

Which compiler are you using (5g, 6g, 8g, gccgo)?

8g

Which operating system are you using?

Windows XP SP3

Which revision are you using?  (hg identify)
The gowin32_2011-01-12 release.

Please provide any additional information below.

Looking at the path.go source file it is clear that forward slashes are being used
directly in the code, instead of making references to path.DirSeps.

[bsiegert]

Comment 1:

directory/file is a valid path on Windows. This is not a bug.

[gopherbot]

Comment 2 by paulo.jpinto:

This breaks expectations, as referred on my submission, even though Win32 supports
forward slashes, no one expects to use them.
This breaks compatibility with all the tools that might need to interoperate with Go
based applications.
All other languages play nice with Windows:
Python:
>>> import os.path
>>> os.path.join("directory","file")
'directory\\file'
JVM using Groovy
groovy> println new File("directory", "file").getPath();
directory\file
.Net using C#
class Demo {
  public static void Main() {
    System.Console.WriteLine (System.IO.Path.Combine("directory", "file"));
  }
}
Output: directory\file

[bsiegert]

Comment 3:

If other applications do not accept paths with forward slashes, they are broken and
should be fixed. All the ones that I tested do accept them.

[gopherbot]

Comment 4 by paulo.jpinto:

So the Go language designers know better than the Windows developers what we are
supposed to write when targeting Windows?!
Please take time to read Microsoft documentation before saying that the applications are
broken, http://msdn.microsoft.com/en-us/library/aa365247%28v=VS.85%29.aspx
Take also time to read that UNC paths do not accept forward slashes.
If Go is to be used by Windows developers, then please take time to follow the right
conventions.
When I created this issue, I was planning to provide the patch myself, but on the light
of the current discussion, I fear my work won't be appreciated at all.

[alexbrainman]

Comment 5:

I agree that directory\file form is used on Windows most of the time, but all APIs I've
used do work with directory/file as well. Perhaps you would like to tell us why you have
to have your path '\' delimited, so we can understand what your problem is and try to
help you.
Having single form that can be used on both Unix and Windows simplify things a bit. If
you would like to offer a change to have '\' as path separator on Windows, please go
ahead, but it would have to be simple enough.

[rsc]

Comment 6:

I am not happy about making this change.
It means anyone using path to manipulate /-separated things
like URL paths will have their code break on Windows.
I don't want Go programs generating things like 
http://www.google.com\codesearch.  Yuck.

Owner changed to r...@golang.org.

Status changed to Thinking.

[rsc]

Comment 7:

Issue #1422 has been merged into this issue.

[gopherbot]

Comment 8 by paulo.jpinto:

That is exactly the reason why, usually Windows developers don't use path APIs to deal
with URLs. They are not handled the same way as file systems paths.
The reason I want to use '\' is because, *again*, even though the Win32 API supports
them, they are not handled correctly by most applications.
If I need to generate pathnames that are given to other Windows applications I need to
code them by hand, losing the benefit to use the path package.
Plus if I need to handle UNC paths, I am also required to generate the paths without
help from the path package.
I really don't understand why Go does not follow what every programming language on
WIndows offers and what Microsoft's own documentation suggests.
But maybe Windows is not that important anyhow...

[rsc]

Comment 9:

from godoc path:
The path package implements utility routines for manipulating
slash-separated filename paths.

[rsc]

Comment 10:

also note that the package is called path, not os.path.

[gopherbot]

Comment 11 by paulo.jpinto:

Please feel free to close the ticket, this discussion is not going anywhere.
With all negative feedback I rather spend my time elsewhere.

[rsc]

Comment 12:

Even if you're not interested in participating in the discussion
I will leave the ticket open.  I think we do need to figure out
whether package path is going to be OS-specific paths or
slash-separated paths.  There are reasonable arguments on both sides.

[kardianos]

Comment 13:

I strongly suggest breaking out the path into a URL path handler that knows about
protocols, and a file path handler that knows about rooting and normal OS slashes.
Reasons:
A) not all APIs accept '/', example:
http://msdn.microsoft.com/en-us/library/aa365247(v=vs.85).aspx
Note  File I/O functions in the Windows API convert "/" to "\" as part of converting the
name to an NT-style name, except when using the "\\?\" prefix as detailed in the
following sections.
In modern file system/apps on windows, \\?\ is becoming more common.
B) I can state from experience, when I was in high school and open source programs were
first being ported to windows, many such programs used '/' slashes for a dir sep.  This
confused me.  I've now gone to college, graduated and work with many different clients
(I'm a contractor) and although I now use Linux as my primary workstation and understand
why it technically works in most cases, as a contractor if a feature bothers a client
(and this would), I fix it even when it's a pain to do given the existing framework.
So this is really a selfish request, I want to work with a library, not around it.

[gopherbot]

Comment 14 by daveroundy:

I recall with darcs having to work around programs (putty?) that require backslashes in
their file path arguments, and it definitely seems worth having a package to do this. 
Also, windows has a horrid mash of other path types (e.g. relative to the working
directory on a different drive) and it'd be nice to have functionality to handle those
paths as well.
Perhaps we could gain an os.path, which would be mostly reexporting path on unixy
machines, but would handle windows paths natively?

[alexbrainman]

Comment 15:

Now, that we have path/filepath, if we rewrite above mentioned program as:
package main
import (
    "path/filepath"
    "fmt"
)
func main() {
    fmt.Println(filepath.Join("directory", "file"))
}
it prints
directory\file
Should we close this issue?

Status changed to WaitingForReply.

[gopherbot]

Comment 16 by paulo.jpinto:

From my point of view it is ok to close it.

[rsc]

Comment 17:

Status changed to Fixed.