Allow applications to opt out of shell-style backslash escaping

[h3zh1]

Thank you for creating and maintaining this project.

Problem

line.Parse parses and reprints the input with mvdan.cc/sh/v3/syntax, then calls shellquote.Split. As a result, unquoted backslashes are interpreted as shell escape characters.

For example:

ls C:\Windows\Temp

is passed to Cobra as:

[]string{"ls", "C:WindowsTemp"}

instead of:

[]string{"ls", `C:\Windows\Temp`}

With the current parser, users must instead quote the entire value, as in ls 'C:\Windows\Temp', or escape every backslash, as in ls C:\\Windows\\Temp. Both forms work, but they are cumbersome when arguments are intended to be passed to Cobra literally.

If the value ends in a backslash, such as ls C:\Windows\Temp\, AcceptMultiline also treats the input as incomplete and waits for another line.

Quoting the value or doubling every backslash works, but is inconvenient when the console is used as a general Cobra frontend rather than as a shell.

Request

Would you consider exposing a configurable execution parser, or providing a mode that preserves literal backslashes?

The current shell-compatible behavior could remain the default. Applications should be able to select matching parsing and line-completeness semantics so that a trailing literal backslash is not always treated as a continuation marker.

cmd/internal/quoted.Split could be one
implementation option for a literal-backslash mode, although it is an internal package and
multiline detection would still need to be handled separately.

[maxlandon]

Fixed in v0.5.0 via #89.

You can now opt out of shell-style backslash escaping console-wide:

app := console.New("myapp")
app.SetEscapeMode(console.EscapeLiteral)

In EscapeLiteral mode, backslashes are ordinary characters: quotes still group words, but C:\Windows\Temp is passed to your command verbatim (no quoting or doubling needed), and a trailing backslash no longer requests a continuation line. The default EscapeShell behavior is unchanged.

The mode is applied consistently across command execution, multiline-continuation detection, and completion/highlighting. Thanks for the clear, well-researched report — the pointer to the exact parsing stages made this straightforward to diagnose.

[h3zh1]

The new EscapeLiteral mode works very well. Thank you for adding it.

I have one follow-up question: could explicit multiline input be configured
independently from backslash escaping?

For long commands, it is often useful to split the input manually:

apt install \
  vim gcc -y

Ideally, both lines would be submitted as a single command:

[]string{"apt", "install", "vim", "gcc", "-y"}

In EscapeLiteral mode, a trailing backslash is intentionally preserved and no
longer starts a continuation line. This is correct for literal Windows paths, but
it also removes the familiar multiline syntax shown above.