Emitting CRLF through ANSI escape sequences

[mataha]

Rather than a feature, I have a question regarding both Terminal and conhost.exe:

Is there a way to make the terminal emit CRLF through ANSI escape sequences?

Use-case: we (in a thread here) are trying to create a customizable prompt for cmd.exe with the aid of virtual terminal sequences. What we have currently is emitting DA (\x1b[0c) and creating a DOSKEY alias for the response (which is always \x1b[?1;0c). However, for that to work the macro would need to be executed somehow, hence the requirement to inject an Enter there.

Example PoC should that be necessary:

@setlocal DisableDelayedExpansion & echo off

for /f "skip=1" %%e in ('"echo(prompt $E| "%ComSpec%" /d /q /k 2>nul"') do (
    set "\e=%%~e"
)

"%windir%\System32\doskey.exe" %\e%[?1;0c = echo ...

set PROMPT=$E[0c$P$G$S ...

[j4james]

Is there a way to make the terminal emit CRLF through ANSI escape sequences?

No. Modern terminals tend to avoid escape sequences that can be used to generate key presses because they are something of a security risk. For example, imagine you were trying to view a readme file in the console, and that file had an embedded escape sequence that injected the keystrokes for a command that would delete all of your files. You would not be happy.

Also, it's worth mentioning that the DA sequence won't always return \x1b[?1;0c. It's used to identify the terminal's capabilities, and we've progressed a lot since that document was written. Newer versions of the console will return something quite different, and it's likely to keep changing.

[lhecker]

Modern terminals tend to avoid escape sequences that can be used to generate key presses because they are something of a security risk.

Unrelated to this discussion, we do generate sequences if someone calls WriteConsoleInput on us. Should we avoid doing so? In other words, should we avoid calling TerminalInput entirely when WriteConsoleInput is called?

[j4james]

I don't think WiteConsoleInput is a problem. Any application that can call that would also be able to trash the system in a million other ways. That's why you don't install untrusted applications. The risk of escape sequences, though, is that they can be triggered by merely viewing a file - that should never be something that is able to initiate code execution.

[mataha]

No. Modern terminals tend to avoid escape sequences that can be used to generate key presses because they are something of a security risk. For example, imagine you were trying to view a readme file in the console, and that file had an embedded escape sequence that injected the keystrokes for a command that would delete all of your files. You would not be happy.

That's a valid concern; thanks for the clarification.

That said - is there anything else I can use to mask or hide the response from the terminal among the supported escape codes? Ideally something akin to \x1e[30;40m capturing DA reply only, followed by \x1e[0m.

Also, it's worth mentioning that the DA sequence won't always return \x1b[?1;0c. It's used to identify the terminal's capabilities, and we've progressed a lot since that document was written. Newer versions of the console will return something quite different, and it's likely to keep changing.

If that's the case I can fall back to \x1b[s\x1b[H\x1b[6n\x1b[u if necessary (as that will return \x1b[1,1R without fail).

On the other hand - I don't know about Windows Terminal, but conhost.exe keeps returning \x1b[?1;0c - and I believe, being sunset by this project, support for it has come to an end, therefore it's unlikely to receive any additional tweaks (e.g. hyperlink support).

[j4james]

That said - is there anything else I can use to mask or hide the response from the terminal among the supported escape codes?

No, I don't think so. There are plenty of ways to hide the text, but they all require that you have some way to reset the visibility after the response has been received. I can't think how you could do that.

If that's the case I can fall back to \x1b[s\x1b[H\x1b[6n\x1b[u if necessary (as that will return \x1b[1,1R without fail).

On more modern versions of Windows you could also use \x1b[5n, which should always return \x1b[0n, but I don't think that works on the current Windows 10 conhost. So if you need to support Windows 10, then your \x1b[6n approach is probably safest.

On the other hand - I don't know about Windows Terminal, but conhost.exe keeps returning \x1b[?1;0c - and I believe, being sunset by this project, support for it has come to an end, therefore it's unlikely to receive any additional tweaks (e.g. hyperlink support).

It's just Windows 10 that isn't getting conhost updates anymore (as far as I know), so the conhost in Windows 11 should eventually get most of features that you see in Window Terminal. When it comes to escape sequences, they share the same code base.

The hyperlink support is a little more complicated, because that involves UI. So while conhost is capable of parsing and storing hyperlinks, it doesn't have the UI to interact with them. But they may still be supported eventually - there is an open issue (#7564).