Make structure of Cmd more obvious in printing

[Keno]

Cmds behave as an array of strings, but for most new users the mental
model they start with is that Cmds are essentially strings. As a result,
people can get easily confused by the interpolation rules around Cmds.
They are quite intuitive when one thinks of them as arrays of strings
(e.g. arrays get expanded, strings get inserted as is), but less so
when thinking of a Cmd as a single string. It seems possible to make
it clearer in printing that there is an underlying structure to the
Cmd by adjusting the way it prints. This one attempt at doing so by
underlining each separate part of the array. Some advantages:

• The underlining makes it clear that there is something going on
  beyong being a regular string
• The underlining gets dropped when copying out from a terminal, so
  there's no trouble with pasting it back into a REPL.
• The underlying structure of clearly visible (each contiguous underline
  is one of the elements of the array of strings).

Examples:

[tkelman]

One thing that's persistently annoyed me about the way they print is that the quoting is posix-centric. If you copy-paste the printed output of these into a Windows shell it almost never works as-is.

[TotalVerb]

Would probably be better to only do this for show(io::IO, ::MIME"text/plain", cmd::Cmd), so as not to affect repr.

[tkelman]

this didn't get addressed, did it?

#22142

[StefanKarpinski]

One thing that's persistently annoyed me about the way they print is that the quoting is posix-centric. If you copy-paste the printed output of these into a Windows shell it almost never works as-is.

We have to pick some shell standard to emulate and POSIX and Windows CMD are mutually incompatible, so I don't know what you could possibly want here. Only use the intersection of POSIX and CMD features? Everyone seems to agree that CMD is pretty unusable, so doing this seems like an poor idea.

[tkelman]

No, but at least display things differently on windows so that the output is moderately useful - right now it is not, at all.

[StefanKarpinski]

If we display commands differently on Windows do we then a) print in a different format than we accept input, or b) change cmd syntax so it's platform-dependent? Both are bad choices – worse than what we do now. If someone wants a usable shell on Windows, they should install a POSIX shell.

[tkelman]

We wouldn't print anything we don't accept. But changing the way we normalize the displayed output would make it much more useful without forcing users to install anything extra. Cygwin has been around and done its job for decades, and yet people still don't like using it for whatever reason. Julia isn't a posix-dependent application.

[StefanKarpinski]

So you're arguing for system-dependent backtick syntax and printing? I.e. on Windows we accept one syntax inside of backticks while on other systems we accept a different, incompatible syntax?

[tkelman]

Not system dependent syntax in what we accept, but system dependent output in how we print things so people can copy paste commands from error messages without needing to manually reformat the whole thing.

[StefanKarpinski]

So you're saying that the output should be system-dependent and we should print Cmd objects in a way that cannot always be pasted back into the REPL to get an equal Cmd object?

[tkelman]

So you're saying that the output should be system-dependent

yes

we should print Cmd objects in a way that cannot always be pasted back into the REPL to get an equal Cmd object?

Did not say that. The main change that would get things fairly useful for windows users (who make up a plurality of downloads, remember) would be not using single quotes in how we display Cmd objects on windows, instead escaping any nested double quotes. Implementing totally compatible windows cmd semantics isn't worth doing, but a small tweak to the way these display would be.

Windows does come with a thoroughly usable non-posix shell, but very few people use powershell or even know it's there.

[StefanKarpinski]

I'm not sure why I had to play a game of 20 questions to get that straightforward answer on what you think we should do. How about making a PR that implements it?

[KristofferC]

No test = this is now broken. sprint probably needs to grab the context from the input IO.

[vtjnash]

Ironically, I think the commit that made it possible to test this (adding :color to the IO context), is what broke it :)

[KristofferC]

Testing was always possible with the good ol'

old_have_color = Base.have_color
@eval Base have_color = true
try
     # ....
finally
    @eval Base hascolor = $old_have_color
end