x/tools/go/analysis/singlechecker: flag "-V" is messed up

[MikeSpreitzer]

What version of Go are you using (go version)?

$ go version
go version go1.19.4 darwin/amd64

Does this issue reproduce with the latest release?

Yes, I am using the latest version.

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/mspreitz/Library/Caches/go-build"
GOENV="/Users/mspreitz/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/mspreitz/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/mspreitz/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.19.4/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.19.4/libexec/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.19.4"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/vs/qkb72z0s57s_yr0ttjfzh8h40000gn/T/go-build1814034291=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I built and installed https://github.com/kubernetes-sigs/logtools, then asked it to report its version. First I consulted logcheck -h to find out how to make it report its version. That said "-V print version and exit". So then I tried it as follows.

(base) mspreitz@mjs12 ~ % logcheck -V
logcheck: unsupported flag value: -V=true

I reported this to the logtools repo, see kubernetes-sigs/logtools#9 . The response there is that the problem is in the go tooling.

Also:

(base) mspreitz@mjs12 ~ % logcheck -V=full
logcheck: open logcheck: no such file or directory

What did you expect to see?

I expected the -h flag to provoke an accurate description of how to use the -V flag.

I expected -V, when used as recommended, to report on the program's version is some way.

What did you see instead?

The error messages shown above.

[timothy-king]

logcheck: unsupported flag value: -V=true

Seems like a not very helpful error message.

logcheck: open logcheck: no such file or directory

I suspect this is just not finding a file in your path. Can you mind including the relevant results of which logcheck and echo $PATH? Which directory did you run this from?

[gopherbot]

Change https://go.dev/cl/461496 mentions this issue: go/analysis/internal/analysisflags: lookup program in PATH

[MikeSpreitzer]

(base) mspreitz@mjs12 logtools % pwd
/Users/mspreitz/go/src/github.com/kubernetes-sigs/logtools

(base) mspreitz@mjs12 logtools % go install ./logcheck 

(base) mspreitz@mjs12 logtools % which logcheck
/Users/mspreitz/go/bin/logcheck

(base) mspreitz@mjs12 logtools % logcheck -V
logcheck: unsupported flag value: -V=true

(base) mspreitz@mjs12 logtools % logcheck -V=full
logcheck: read logcheck: is a directory

(base) mspreitz@mjs12 logtools % cd

(base) mspreitz@mjs12 ~ % logcheck -V=full
logcheck: open logcheck: no such file or directory

(base) mspreitz@mjs12 ~ % printenv PATH | tr : "\n"
/Users/mspreitz/.krew/bin
/Users/mspreitz/google-cloud-sdk/bin
/Users/mspreitz/opt/anaconda3/bin
/Users/mspreitz/opt/anaconda3/condabin
/usr/local/bin
/usr/bin
/bin
/usr/sbin
/sbin
/Library/TeX/texbin
/usr/local/go/bin
/Applications/Wireshark.app/Contents/MacOS
/Users/mspreitz/go/bin
/Users/mspreitz/local/bin

[pohly]

The solution for unsupported flag value: -V=true seems backwards to me: instead of accepting what's intuitive and documented in the help text, users still need to figure out that -V=full is expected. Also commented on the MR.

[timothy-king]

After the CL is submitted there is now enough context to use -V=full without looking at the source code (in 2 iterations instead of 1), and to look in the right place for the binary. This could be improved, but it seems good enough to me. If you think more action should be taken, you can open a new issue or create a new CL to be reviewed.