Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document the undocumented -X switches #103

Open
lmakarov opened this issue Mar 9, 2017 · 4 comments
Open

Document the undocumented -X switches #103

lmakarov opened this issue Mar 9, 2017 · 4 comments

Comments

@lmakarov
Copy link

lmakarov commented Mar 9, 2017

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 ... > ).

@rprichard
Copy link
Owner

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.

@godhelpjun
Copy link

godhelpjun commented Jun 4, 2019

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

@fredrikw
Copy link

... 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).

@temsa
Copy link

temsa commented May 3, 2022

@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 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants