wstart /mnt/c/windows does not work about cbwin HOT 7 OPEN

Write a bash function may work:

wstart_new() {
        dir_name="$(dirname "$1")"
        base_name="$(basename "$1")"

        shift
        cd "$dir_name" && wstart "$base_name" "$@"
}

from cbwin.

I think to define the exact behavior we must consider #8, #25, and #27.

@marcosdiez: as you can see in #25 there is no consensus for some details for wcmd between @goreliu and I. I don't think one approach is strongly superior to the other though, and I'm still open to any suggestion.

However for wstart and wrun the situation should be simpler (but still slightly different for each), so it is a good idea to start there.

There are several things to handle: path translation, quoting&escaping per MSVC/CommandLineToArgvW rules, and quoting&escaping per the (several different, context dependent) cmd rules. I think minimizing the amount to quoting&escaping is also necessary.

About #8, I actually think some of the MinGW rules are insane, but they preexists. One thing that could be in favor of not caring much about them is that they seem centered on build-sys. Also it's a shame that they are not individually motivated, because for ex. I'm not sure of what to think about /c:\foo\bar -> c:/foo/bar ...

from cbwin.

I read #8, #25, and #27 and I think it's all too confusing.

How about the following:

• wcmd, wstart and wrun should all have the same behavour
• they should all expect only parameters and valid unix filenames
• the way they detect if a parameter is a file or not is to check if it's a valid path.
• in case it is a valid path, it converts the filename to a windows filenames

that solves the problems with quoting, escaping and everything else
that makes all the commands consistent
but it fails when one tries to create a new file.
which is a cheap price for the consistency it provides.
one can always touch the file first to use it.

@Artoria2e5 @PutoML @goreliu

you are all welcome to participate in the discussion

I can write the code once we get into an agreement.

from cbwin.

I like the idea, except the file shall already exists part. If it is absolute, it'll be /mnt/[/[something]], and, even if it starts with an /, that's unlikely to be a Windows option and easy to understand that if it's a single Unix param it will be considered a filename.

If it's relative, it'll be filename or directory/filename and it could be confusing, because of ' ', &, (, etc... But I would not like the behavior of a command line to radically change just depending on if a file with a funny name exists; e.g. "dir & pause". There would be no workaround to get a consistent behavior when files with arbitrary names can exist; isolating delimited parts of the command won't work - ex: "$ wcmd dir '&' pause" fails again as soon as a "&" file exists in the current directory.

Can we find a reasonable heuristic to decide if a param is considered a relative filename or not, without stat'ing it? That heuristic should let funny filenames be used (even if they are not converted); ex with wcmd, '^&' could designate the file named "&"

wcmd is intrinsically special, because it lets arbitrary cmd command lines be used, so I would not be shocked if some details are not the same when using it and when using wrun.

Technically, the start command of cmd can also take an arbitrary cmd command line (with an additional level of escaping), but I don't think that's important to support that. We should rather think of the fact it wstart is using start as an implementation detail, and concentrate on use case scenarios working properly like wstart "copied_url" and wstart program params, and wstart foobar.cpp, with a single program, file or url.

from cbwin.

I'm envisaging the following rules to consider that a param is filename:

abs path: starts with /mnt/<letter>[/[...]]

relative path => param do not start with a /
    components are delimited with a / (or multiple)
    multiple consecutive / are allowed
    each will be translated to a \ (if a translation is decided)

    win32 & win user interface related:
        components do not contain < > : " / \ | ? *
        components do not begin or end with a space
        components do not end with a . (but specials . and .. are allowed)
        components do not contain ascii 1 -> 31

    misc heuristic rules:
        param do not start with a - (because many win programs also use - as an option marker)

    cmd related:
        param do not start with a ^ & | ( ) %
        (note: no support for delayed expansion)

from cbwin.

Translating relative paths may be a hindrance rather than help: most modern Windows applications understand forward slashes in relative paths just fine (even built-in ones such as Notepad), and passing one rendered that way might be intentional.

EDIT: Gah, of course I had to forget the one major app that DOESN'T understand forward slashes: Explorer.

from cbwin.

The problem is not only about / -> , but more interestingly about filenames with spaces where quoting is needed, or special characters that need to be escaped. I would prefer to have the result of an interactive filename expansion work most of the time rather than fail as soon as a filename is non-trivial. (Or a bash construct like for each in *; do wcmd something "$each" ; done)

Now there are some compromises to do (for example it won't work with a file just named "&" with the rules I am considering); I'm trying to take into account the multiple scenario that have been reported in various issues, and choose sensible heuristics.

from cbwin.