Bugzilla – Bug 2024
Windows: Running from command line does not display messages
Last modified: 2019-01-21 13:47:00 UTC
On Windows, messages that should be printed back to the "terminal" do not appear. This applies to the Windows Command Prompt and Powershell. However, in Git Bash the messages appear as expected. The easiest way to demonstrate the issue is to launch Audacity with the --version switch. Tested on Windows 10 Home.
Mike Barker wrote on the devel email list: This is a MS Windows design issue. If you mark an executable as a “Windows” program rather than a “Console” program then the process is created without any STDOUT or STDERR handles - so printf output is discarded. Furthermore when the “Windows” marked program is started from a command line the console does not block and wait for return – it just spins off a separate process and carries on. For more details see:- https://blogs.msdn.microsoft.com/oldnewthing/20090101-00/?p=19643 There are various “workarounds” that people have used using “AttachConsole()” etc. but all are rather heavy for just outputting one version message! I would suggest that developers are probably using wxPrintf for debug/logging purposes when perhaps they should be using wxLogXXX etc. There are currently about 12 ‘live’ uses of wxPrintf in Audacity (Windows Build) other than those used for printing the version and most look to be used for logging purposes. Does this warrant a tidy up?
Steve wrote in summary in a lonsh email thread (agreeing with Henric) >I think this brings us back round to Mike's original observation that the >behaviour on Windows is largely down to design decisions by Microsoft >("windows" programs not having STDOUT or STDERR handles). If anyone has >time to look through the wxPrintf messages, then we could decide if Windows >users are "missing out" on anything, and if they are, then we could make >alternative arrangements, but from a fairly brief look myself, I don't see >anything particularly useful. > >One such message is the error that is returned if Audacity is started with an >invalid "-b" switch, but I don't think that we would consider that to be >something intended for users. > >Unless anyone wants to keep this bug open, I'm inclined to go with Henric's >suggestion and close is as "won't fix". I agree
In case anyone is reading this thread in the future, this "bug" could be seen as a "Windows design feature": From the @devel discussion: If an executable is marked as a “Windows” (GUI) program rather than a “Console” program, then the process is created without any STDOUT or STDERR handles - so printf output is discarded. Furthermore when the “Windows” marked program is started from a command line the console does not block and wait for return – it just spins off a separate process and carries on. An easy "solution" for anyone wanting a bash-like command-line experience on Windows is to use Git Bash which is currently included in Git for Windows: https://gitforwindows.org/
