-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
cmd/bug: does nothing if there is no windowing system #19131
Comments
Let's bug @josharian. |
/cc @shurcooL |
What was the exit code from |
Zero exit code.
…On Feb 16, 2017 3:26 PM, "Dmitri Shuralyov" ***@***.***> wrote:
$ go bug
$
What was the exit code from go bug (ala echo $?)?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#19131 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AABhls8qLX40yz78zSIthcTllu5Ufaqeks5rdNslgaJpZM4MDq2T>
.
|
Would you mind instrumenting the browser opening code and finding out what's happening there? See https://github.com/golang/go/blob/master/src/cmd/internal/browser/browser.go#L38. I'd be curious about which browser command is succeeding, and what happens if you run it manually. |
Can you share any more information about the headless system you are on? I cannot experience this neither when I am ssh'ing into Debian or Ubuntu. |
Able to reproduce on a headless system.
It is better to log the browser being used to open (in browser.go) and/or to provide a |
This will impact any command that opens a browser, including go trace, go tool pprof, etc. We don't check the exit code or wait for the command because some browser commands block. I don't want to log every time; that'd be ugly, and almost all invocations succeed. Let's start by fixing the specific problem on the specific system, even if it is not very portable. Sounds like maybe checking DISPLAY might work? |
In the last case, one can do like:
This should work on a headless systems with Xorg (which covers everything except windows). Tested with:
and
|
DISPLAY won't work on OS X, though. (at least, I assume our target audience is not XQuartz users) Will it even work on Wayland? Or do you also have to check WAYLAND_DISPLAY? |
For Wayland, yes, $WAYLAND_DISPLAY needs to be checked. Does the X server in OSX export any similar variable? |
macOS doesn't use an X server. |
Could we only use display if there is a DISPLAY envvar? Or hard code some OSes? And this code belongs in the browser-handling code, not go bug. |
Regarding browser.go, strictly speaking, there are browsers which work without X server, will be harder to impose with that constraint there. But, again, if we restrict to graphical browsers only, then one can fail early in https://github.com/golang/go/blob/master/src/cmd/internal/browser/browser.go#L20 depending on the platform (so fail only for known platforms in the beginning). |
More details on my setup:
Added some logs and can confirm xdg-open is the command being used. If I run Suggested fix: wait 5 seconds for the process to exit. If the exit code is nonzero or takes >5 seconds to return, print out the URL to stdout. That is, keep the current behavior if the command returns a nonzero exit code within 5 seconds. |
I've seen at least one reported case where where "xdg-open" seemed to block and not return until browser was closed. To help the issue, I had to run it in a background goroutine. See shurcooL/Go-Package-Store@a15fc56 and shurcooL/Go-Package-Store#26 (comment). However, this was 2 years ago, and it looked like an outdated, possibly misconfigured linux system. |
I think waiting 5s is reasonable. On most systems, the command exits almost immediately, so I doubt anyone will notice. But we shouldn't print the URL to stdout. As I keep saying, the fix should go in the browser-opening code, not in 'go bug', and each individual command can decide how to handle the browser not opening; 'go bug' already has handling for that case. |
Well, xdg-open does also complete within 5 seconds with a non-zero exit code. I hooked up stdin/stdout and get the following: stderr:
stdout:
Presumably it's opening up links (I don't have links2 installed) but exiting right away. I guess xdg-open is at fault here? It's opening up links without a tty. edit: So, I suppose we need to handle this. Do we need to inspect anything other than |
CL https://golang.org/cl/37390 mentions this issue. |
CL https://golang.org/cl/37391 mentions this issue. |
xdg-open's man page says: > xdg-open is for use inside a desktop session only. Use the DISPLAY environment variable to detect this. Updates #19131. Change-Id: I3926b3e1042393939b2ec6aacd9b63ac8192df3b Reviewed-on: https://go-review.googlesource.com/37390 Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Wait a short period between trying commands. Many commands will return a non-zero exit code if the browser couldn't be launched. For example, google-chrome returns quickly with a non-zero exit code in a headless environment. Updates #19131. Change-Id: I0ae5356dd4447969d9e216615449cead7a8fd5c9 Reviewed-on: https://go-review.googlesource.com/37391 Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
What version of Go are you using (
go version
)?go1.8
What operating system and processor architecture are you using (
go env
)?linux/amd64
What did you do?
Run
go bug
on a headless system.What did you expect to see?
Anything.
What did you see instead?
Nothing.
The text was updated successfully, but these errors were encountered: