garble/testdata/scripts/help.txt

! garble
stderr 'Garble obfuscates Go code'
stderr 'garble \[garble flags\] command'
! stderr 'usage: go build'
! stdout .

! garble -h
stderr 'Garble obfuscates Go code'
stderr 'garble \[garble flags\] command'
! stdout .

! garble help
stderr 'Garble obfuscates Go code'
stderr 'garble \[garble flags\] command'
! stdout .

! garble help foo bar
stderr 'usage: garble help'
! stderr 'Garble obfuscates Go code'
! stdout .

! garble help -h
stderr 'usage: garble help'
! stdout .

! garble build -h
stderr 'garble \[garble flags\] build'
stderr 'This command wraps "go build"'
stderr 'usage: go build'
stderr 'Run .go help build.'
! stderr 'Garble obfuscates Go code'
! stdout .

! garble test -h
stderr 'garble \[garble flags\] test'
stderr 'This command wraps "go test"'
stderr 'usage: go test'
stderr 'Run .go help test.'
! stderr 'Garble obfuscates Go code'
! stdout .

! garble reverse -h
stderr 'garble \[garble flags\] reverse \[build flags\] package \[files\]'
! stderr 'usage: go '
! stdout .

! garble help reverse
stderr 'garble \[garble flags\] reverse \[build flags\] package \[files\]'
! stderr 'usage: go '
! stdout .

! garble -badflag
stderr 'flag provided but not defined'
stderr 'garble \[garble flags\] command'
! stdout .

! garble badcmd
stderr 'unknown command'

! garble build -badflag
stderr 'usage: go build' # TODO: is this confusing?
! stdout .

! garble build -tiny
stderr 'must precede command, like: garble -tiny build \./pkg'
! stdout .

! garble build -literals
stderr 'must precede command, like: garble -literals build \./pkg'
! stdout .

! garble build -seed=random
stderr 'must precede command, like: garble -seed=random build \./pkg'
! stdout .

[!windows] ! garble /does/not/exist/compile
[windows] ! garble C:\does\not\exist\compile
stderr 'not running "garble \[command\]"'

garble version
stdout 'devel|^v0'

! garble version -flag
stderr 'usage: garble version'

! garble version arg
stderr 'usage: garble version'

# We need a dummy module for "garble build -badflag".
-- go.mod --
module dummy
-- dummy.go --
package dummy
initial commit 5 years ago			`! garble`
make "garble command -h" give command-specific help Before, "garble build -h" would print the same as "garble -h", which is too much and confusing, as it doesn't tell us much about "build". Now it's far better, and includes the output of "go build -h": $ garble build -h usage: garble [garble flags] build [arguments] This command wraps "go build". Below is its help: usage: go build [-o output] [build flags] [packages] Run 'go help build' for details. We do the same for "garble reverse -h", since it doesn't wrap a Go tool command. 4 years ago			`stderr 'Garble obfuscates Go code'`
make "help" refuse arguments for now Since they are otherwise silently ignored. 4 years ago			`stderr 'garble \[garble flags\] command'`
clarify usage text, add help flags Also remove the -toolexec equivalent, as it's becoming longer now that we have GARBLE_DIR, and it might become out of date in the future again. We don't want users to assume it will work forever. 5 years ago			`! stderr 'usage: go build'`
initial commit 5 years ago			`! stdout .`

			`! garble -h`
make "garble command -h" give command-specific help Before, "garble build -h" would print the same as "garble -h", which is too much and confusing, as it doesn't tell us much about "build". Now it's far better, and includes the output of "go build -h": $ garble build -h usage: garble [garble flags] build [arguments] This command wraps "go build". Below is its help: usage: go build [-o output] [build flags] [packages] Run 'go help build' for details. We do the same for "garble reverse -h", since it doesn't wrap a Go tool command. 4 years ago			`stderr 'Garble obfuscates Go code'`
make "help" refuse arguments for now Since they are otherwise silently ignored. 4 years ago			`stderr 'garble \[garble flags\] command'`
clarify usage text, add help flags Also remove the -toolexec equivalent, as it's becoming longer now that we have GARBLE_DIR, and it might become out of date in the future again. We don't want users to assume it will work forever. 5 years ago			`! stdout .`

			`! garble help`
make "garble command -h" give command-specific help Before, "garble build -h" would print the same as "garble -h", which is too much and confusing, as it doesn't tell us much about "build". Now it's far better, and includes the output of "go build -h": $ garble build -h usage: garble [garble flags] build [arguments] This command wraps "go build". Below is its help: usage: go build [-o output] [build flags] [packages] Run 'go help build' for details. We do the same for "garble reverse -h", since it doesn't wrap a Go tool command. 4 years ago			`stderr 'Garble obfuscates Go code'`
make "help" refuse arguments for now Since they are otherwise silently ignored. 4 years ago			`stderr 'garble \[garble flags\] command'`
			`! stdout .`

			`! garble help foo bar`
always require one argument for "reverse" The "reverse" command had many levels of optional arguments: garble [garble flags] reverse [build flags] [package] [files] This was pretty confusing, and could easily lead to people running the command incorrectly: # note that output.txt isn't a Go package! garble reverse output.txt Moreover, it made the handling of Go build flags pretty confusing. Should the command below work? garble reverse -tags=mytag It also made it easy to not notice that one must supply the main package to properly reverse some text that it produced, like a panic message. With the package path being implicit, one could mistakenly provide the wrong package by running garble in a directory containing a different package. See #394. 4 years ago			`stderr 'usage: garble help'`
			`! stderr 'Garble obfuscates Go code'`
			`! stdout .`

			`! garble help -h`
			`stderr 'usage: garble help'`
clarify usage text, add help flags Also remove the -toolexec equivalent, as it's becoming longer now that we have GARBLE_DIR, and it might become out of date in the future again. We don't want users to assume it will work forever. 5 years ago			`! stdout .`

			`! garble build -h`
make "garble command -h" give command-specific help Before, "garble build -h" would print the same as "garble -h", which is too much and confusing, as it doesn't tell us much about "build". Now it's far better, and includes the output of "go build -h": $ garble build -h usage: garble [garble flags] build [arguments] This command wraps "go build". Below is its help: usage: go build [-o output] [build flags] [packages] Run 'go help build' for details. We do the same for "garble reverse -h", since it doesn't wrap a Go tool command. 4 years ago			`stderr 'garble \[garble flags\] build'`
			`stderr 'This command wraps "go build"'`
			`stderr 'usage: go build'`
			`stderr 'Run .go help build.'`
			`! stderr 'Garble obfuscates Go code'`
			`! stdout .`

			`! garble test -h`
			`stderr 'garble \[garble flags\] test'`
			`stderr 'This command wraps "go test"'`
			`stderr 'usage: go test'`
			`stderr 'Run .go help test.'`
			`! stderr 'Garble obfuscates Go code'`
			`! stdout .`

			`! garble reverse -h`
always require one argument for "reverse" The "reverse" command had many levels of optional arguments: garble [garble flags] reverse [build flags] [package] [files] This was pretty confusing, and could easily lead to people running the command incorrectly: # note that output.txt isn't a Go package! garble reverse output.txt Moreover, it made the handling of Go build flags pretty confusing. Should the command below work? garble reverse -tags=mytag It also made it easy to not notice that one must supply the main package to properly reverse some text that it produced, like a panic message. With the package path being implicit, one could mistakenly provide the wrong package by running garble in a directory containing a different package. See #394. 4 years ago			`stderr 'garble \[garble flags\] reverse \[build flags\] package \[files\]'`
			`! stderr 'usage: go '`
			`! stdout .`

			`! garble help reverse`
			`stderr 'garble \[garble flags\] reverse \[build flags\] package \[files\]'`
make "garble command -h" give command-specific help Before, "garble build -h" would print the same as "garble -h", which is too much and confusing, as it doesn't tell us much about "build". Now it's far better, and includes the output of "go build -h": $ garble build -h usage: garble [garble flags] build [arguments] This command wraps "go build". Below is its help: usage: go build [-o output] [build flags] [packages] Run 'go help build' for details. We do the same for "garble reverse -h", since it doesn't wrap a Go tool command. 4 years ago			`! stderr 'usage: go '`
initial commit 5 years ago			`! stdout .`

			`! garble -badflag`
handle unknown flags in reverse (#290) While at it, expand the tests for build and test too. 4 years ago			`stderr 'flag provided but not defined'`
make "help" refuse arguments for now Since they are otherwise silently ignored. 4 years ago			`stderr 'garble \[garble flags\] command'`
initial commit 5 years ago			`! stdout .`
make "no such file" test pass on Windows 5 years ago
			`! garble badcmd`
			`stderr 'unknown command'`

handle unknown flags in reverse (#290) While at it, expand the tests for build and test too. 4 years ago			`! garble build -badflag`
			`stderr 'usage: go build' # TODO: is this confusing?`
			`! stdout .`

give a useful error for "garble build -tiny" We've had confused users a handful of times by now. And it's reasonable to expect flags to be after the command, as that's how flags work for cmd/go itself. I don't think we want to mix our flags with Go's, or start accepting flags in either place. Both seem like worse solutions long-term, as they can add confusion. However, we can quickly give a useful hint when a flag is misplaced. That should get new users unblocked without asking for help. We use a regular expression for this purpose, because it doesn't seem like a FlagSet supports what we need; to detect whether an argument is one of our flags, without actually applying its value to the flagset. Our flagset would also error on Go's flags, which we don't want. 3 years ago			`! garble build -tiny`
			`stderr 'must precede command, like: garble -tiny build \./pkg'`
			`! stdout .`

			`! garble build -literals`
			`stderr 'must precede command, like: garble -literals build \./pkg'`
			`! stdout .`

			`! garble build -seed=random`
			`stderr 'must precede command, like: garble -seed=random build \./pkg'`
			`! stdout .`

make "no such file" test pass on Windows 5 years ago			`[!windows] ! garble /does/not/exist/compile`
			`[windows] ! garble C:\does\not\exist\compile`
Share data between processes via a shared file. (#192) Previously garble heavily used env vars to share data between processes. This also makes it easy to share complex data between processes. The complexity of main.go is considerably reduced. 4 years ago			`stderr 'not running "garble \[command\]"'`
include a "garble version" test (#221) Not sure why the last commit came with none. While at it, I noticed that the version command would ignore arguments. Error instead. 4 years ago
			`garble version`
			`stdout 'devel\|^v0'`

			`! garble version -flag`
always require one argument for "reverse" The "reverse" command had many levels of optional arguments: garble [garble flags] reverse [build flags] [package] [files] This was pretty confusing, and could easily lead to people running the command incorrectly: # note that output.txt isn't a Go package! garble reverse output.txt Moreover, it made the handling of Go build flags pretty confusing. Should the command below work? garble reverse -tags=mytag It also made it easy to not notice that one must supply the main package to properly reverse some text that it produced, like a panic message. With the package path being implicit, one could mistakenly provide the wrong package by running garble in a directory containing a different package. See #394. 4 years ago			`stderr 'usage: garble version'`
include a "garble version" test (#221) Not sure why the last commit came with none. While at it, I noticed that the version command would ignore arguments. Error instead. 4 years ago
			`! garble version arg`
always require one argument for "reverse" The "reverse" command had many levels of optional arguments: garble [garble flags] reverse [build flags] [package] [files] This was pretty confusing, and could easily lead to people running the command incorrectly: # note that output.txt isn't a Go package! garble reverse output.txt Moreover, it made the handling of Go build flags pretty confusing. Should the command below work? garble reverse -tags=mytag It also made it easy to not notice that one must supply the main package to properly reverse some text that it produced, like a panic message. With the package path being implicit, one could mistakenly provide the wrong package by running garble in a directory containing a different package. See #394. 4 years ago			`stderr 'usage: garble version'`
handle unknown flags in reverse (#290) While at it, expand the tests for build and test too. 4 years ago
			`# We need a dummy module for "garble build -badflag".`
			`-- go.mod --`
			`module dummy`
			`-- dummy.go --`
			`package dummy`