winpty icon indicating copy to clipboard operation
winpty copied to clipboard

Document the undocumented -X switches

Open lmakarov opened this issue 7 years ago • 4 comments

I wish I knew this was possible much much earlier. Could have saved lots of hours of pain trying to get around the limitations on Windows.

Add undocumented -X switches to winpty.exe for testing -Xallow-non-tty: allow stdin/stdout to not be ttys -Xconerr: test the new CONERR mode (connect it to STDERR_FILENO) -Xplain: enter plain, unescaped, mode -Xcolor: force generation of color escapes, even with -Xplain

Also: with "winpty.exe --showkey", stop trying to put stdout into raw terminal mode, and ignore whether it is a tty.

In particular -Xallow-non-tty is a life saver! I understand it may not have been tested thoroughly yet, but it did solve all of my issues with using winpty with pipes (winpty ... | ...), subcommand evaluation (var=$(winpty ...)) and stream redirects (winpty ... > ).

lmakarov avatar Mar 09 '17 22:03 lmakarov

I'm hesitant to document the switches because I don't think the command-line interface is quite right.

For example: while using -Xallow-non-tty disables the tty check, allowing redirecting winpty output to a pipe or file, I don't think the behavior is usually what people want. i.e. The child program will still think it's writing to a console screen buffer rather than to a pipe or file. The program will think it's OK to output color, modify existing output, etc., and winpty will think it's OK to generate escape sequences. The output from the program must be text (in either the console code page or UCS-2), which winpty then converts to UTF-8. The redirection should probably propagate through instead, so the program sees the same pipe/file output as winpty.exe. If/when I make that change, the -Xallow-non-tty switch won't make any sense, but maybe it'd make sense to have some way to restore the current behavior with the switch.

rprichard avatar Mar 12 '17 23:03 rprichard

Life saver!!!yes,this switch is !! Can I just say that,when you work with some windows program (like windows version redis-cli,I do not have the choice to run redis-server on linux ) that you can not pipe or do redirection,you are so helpless to work for days to try to figure it out what's wrong with it. I wish I could read this days ago. In my opion,this is a good switch for some conditions.I wish it documented out,for some people who really need it. If you concern some problems,so documented your concern too. thanks for all you do the great job @rprichard

godhelpjun avatar Jun 04 '19 09:06 godhelpjun

... I don't think the behavior is usually what people want. i.e. The child program will still think it's writing to a console screen buffer rather than to a pipe or file. The program will think it's OK to output color, ...

For what it is worth, this was exactly what I wanted and finding it saved my day(s).

fredrikw avatar Sep 14 '20 12:09 fredrikw

@rprichard winpty is used by git-for-windows (aka git-bash) by default for a few commands ( node ipython php php5 psql python2.7 ) to notably allow the REPLs to work. Yet, by default, it prevents pipes | to work, so it is a tradeoff.

So far, -Xallow-non-tty has been able to solve all my issues (both REPLs and piping have been working as expected)

I believe that for integration of my PR into git-for-windows, the maintainers must believe this option, however imperfect and undocumented, is here to stay ( it's been here since 2016 ), could you confirm or infirm it ?

temsa avatar May 03 '22 08:05 temsa