I get the following results for the new `fossil test-prompt-password' command, run in the standard CMD.EXE console on Windows, typing "INPUT[ENTER]" on the keyboard if possible:
---- > echo PASSWORD | fossil test-prompt-password PROMPT: 0 PROMPT:***** [INPUT] 1. The default case. ---- > echo PASSWORD | fossil test-prompt-password PROMPT: 0 2>nul [INPUT] 2. No prompt, but ability to type, no * placeholders while typing. Not sure if this is expected, but "nul" is considered to be a console(!), so input is read from the keyboard, and not from the piped `echo' command. ---- > echo PASSWORD | fossil test-prompt-password PROMPT: 0 2>error.log [PASSWORD ] > type error.log PROMPT: 3. Prompt goes to redirected file instead of console (expected), no possibility to type, but password from redirected standard input (the piped `echo') is accepted (that is, "error.log" is not considered to be a console, so `getc(stdin)' is used instead of `_getch()'). ---- I agree that my examples are all quite stupid, and I can't think of any serious harm to be caused like this. But my point was that testing whether STDERR is a console handle does not automatically imply that STDIN is also a console handle. Moreover, _isatty() (UCRT 10.0.14393.0 in this case) yields different results for the "2>nul" and "2>error.log" redirects, but neither is a console. That's why I think _isatty() is not reliable, and GetConsoleMode() should be preferred. --Florian _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
