Backslashes in paths to open command (ctrl+o) are ignored

[grable0]

Description of the problem or steps to reproduce

After version 1.3.2 the open command (ctrl+o) seems to strip \ characters. All releases after 1.3.2 have this problem, even the nightly.

Specifications

Version: micro-1.3.3-64-bit ++ OS: Windows 10 64-bit Terminal: ConEmu

[supbish]

Backslashes are treated as escape characters, except for in single-quoted strings. Does doubling the backslashes up or single-quoting the path fix it for you?

[grable0]

I just tried in 1.4.1 and the problem persists. Doubling backslashes only work inside single quoted strings, and are ignored in all other cases.

examples: open \dump\types.txt -> dumptypes.txt open "\dump\types.txt" -> dumptypes.txt open "\\dump\\types.txt" -> dumptypes.txt open '\dump\types.txt' -> dumptypes.txt open '\\dump\\types.txt' -> \dump\types.txt <-- correct, but not expected.

Il just have to get used to using forward slashes, less typing ;)

[supbish]

Interesting, haven't looked at open command yet but it sounds like backslash escapes are being processed twice, once before command runs and once in open command.

I'm guessing this will also work: open \\\\dump\\\\types.txt

If so, sounds like a bug with open command.

[supbish]

So, currently Open in command.go looks like this:

// Open opens a new buffer with a given filename
func Open(args []string) {
	if len(args) > 0 {
		filename := args[0]
		// the filename might or might not be quoted, so unquote first then join the strings.
		args, err := shellwords.Split(filename)
		if err != nil {
			messenger.Error("Error parsing args ", err)
			return
		}
		filename = strings.Join(args, " ")

		CurView().Open(filename)
	} else {
		messenger.Error("No filename")
	}
}

The shellwords.Split is what strips the backslashes. Seems to me you could just change it to this:

// Open opens a new buffer with a given filename
func Open(args []string) {
	if len(args) > 0 {
		CurView().Open(args[0])
	} else {
		messenger.Error("No filename")
	}
}

...but it has apparently been like this for a long time, and that comment might be there for a good reason that I don't understand. Maybe you could try this change out in your local copy and see how it goes (esp. try loading some files with spaces in the names)?

[Kein]

Same issue.

The code above could if some #ifdefs for the platform specific code. According to docs:

This module manipulates strings according to the word parsing rules of the UNIX Bourne shell.

Not relevant for Windows.