Where does using / in paths rather than \ not work in Windows? Sorry to pick on your example, but from what I can see, they've already done that.

If you are using / in paths your are limited to max 260 characters paths.

If you want paths up to 32k you need to use back-slashes.

I think this is the reason they are not switching e.g. Visual Studio over to max 32k paths.

It clashes with command line switches. dir /w does not list the contents of the directory called w.

On Windows, you've really got to be quoting your paths everywhere anyway, since spaces abound, and if you do that, then dir "/w" works as expected.

Considering that most file systems these days allow spaces in paths, I'd guess you can safely remove the »On Windows« there. The amount of shell and build scripts on Unix-likes that die horrible deaths when encountering spaces is not funny. And well, yes, in a way that probably means that spaces in paths are not »supported« there, but you could then say the same about Windows. As well as using non-ASCII in paths.

> The amount of shell and build scripts on Unix-likes that die horrible deaths when encountering spaces is not funny.

That's so accurate. I used to write shell scripts with

    command $1

until I got a few too many nasty surprises with dashes in filenames.

Always use "$@"

    foo() {
        for arg in "$@" ; do
            echo "arg is \"${arg}\""
        done
    }

    foo 'bar baz' 'spaces in filename.txt'

> dashes in filenames.

When writing shell scripts it's a good idea to use the -- option whenever possible

    stupid_backup() {
        cp -a -- "$@" /stupid/backup/dir/
    }
 
    # copies 2 files
    stupid_backup --files '-with -leading -dashes'

What does the -- option do? I haven't encountered that before.

It means "everything past here should not be parsed as a - or -- flag". If you have a file named "-l", then ls -- -l will show you that file, instead of doing a long listing.

It should be noted that not all flag parsers support it. But most people use getopt so it's not a big deal.

Thanks- that's really useful.

Not everything's a script though. I avoid using spaces, so I'm in the habit of (outside of a script) not quoting; if I bump into a space within a path then by that point it's just quicker to escape it.

I've been able to successfully use / in the Win32 API with the exception of CreateProcess. I think the reason is that when you start an executable you may pass command line arguments starting with /

Respecting legacy decisions is very important. Often in software design there are many ways to do the same thing. Unless there is an important reason to favor one of the possibilities, the correct answer is almost always to pick the legacy version.

Comparability is important, and not just for existing tools. Choosing something different has a learning cost, and if you have to care about both versions you have ongoing mental effort costs as well.

There may be better names for "/etc", but it's not worth the effort.