Wireshark-bugs: [Wireshark-bugs] [Bug 7755] A console window is never opened.
Comment # 8
on bug 7755
from Guy Harris
(In reply to comment #7)
> (In reply to comment #6)
> > Well, people might think "Display debugging information" being set to
> > "Never" would prevent debugging information from showing up even if you run
> > Wireshark from a console - and, given that, on Windows, Windows-subsystems
> > applications, which Wireshark is on Windows, will be run "in the background"
> > when run from cmd.exe, so the output could show up while something else is
> > running, maybe it *should* mean that.
>
> I've still been compiling Wireshark with epan/packet.c's
> dissector_add_uint_sanity_check() running. With "Open a console window" set
> to either "Automatic" or "Always", when I run Wireshark from cmd.exe, I get:
>
> 16:26:50 Warn tcp.port: http registering using pattern 3689 already
> reg
> istered by http
> 16:26:50 Warn sctp.port: ssl registering using pattern 443 already
> regi
> stered by ssl
> 16:26:50 Warn tcp.port: uma registering using pattern 14001 already
> reg
> istered by uma
>
> ... but when it's set to "Never", then no output is generated.
That's because "Never" means "neither connect to the parent's console window
nor pop up a new window if that fails".
However, it won't have any effect if you run it on UN*X, so, if we want an
option to suppress diagnostic output, it should be an option that turns off the
valve at the point at which the diagnostic messages are issued, or an option
that explicitly sends the standard output or error to {/dev/null, NUL:}, not an
option that fails to *create* a path for them.
For example, exposing prefs.console_log_level through the GUI.
Then an *additional* option might be to have Wireshark pop up a window in which
to display those messages, *both on UN*X and on Windows*, and *regardless of
whether its standard output and error are terminals on UN*X and regardless of
whether it can connect to the parent process's console on Windows*. That
window might just be a text window, not a full-blown console.
> Results differ when run from cygwin though. With cygwin, lots more output is
> generated regardless of the setting.
With Cygwin, the terminal emulator program appears to set the standard input,
output, and error to be pipes that are connected to the terminal emulator
program, so stuff written to the standard output or error always goes to the
terminal emulator and gets written to the screen. In addition, they appear to
wait for the program to finish, even if it's a Windows-subsystem program.
You are receiving this mail because:
- You are watching all bug changes.
