Go 1.19 includes some changes to gofmt which intend to make lists and
heading clearer when rendered (https://go.dev/doc/go1.19). This commit
is the result of running the new gofmt and manually fixing some of it.
This was necessary because the new gofmt assumed lines beginning w/ tabs
to start lists or examples. While this is often true in our codebase,
we occasionally also use tabs to indent the lines after a TODO or FIXME
prefix or in yaml (e.g., excerpts of a snap.yaml). This meant that a lot of the
reformatted comments were broken and had to be fixed manually.
Signed-off-by: Miguel Pires <miguel.pires@canonical.com>
making progress bars should take a stdout io.Writer
ToolingStore should carry an overridable stdout
make sure in image, preseed and cmd/snap code the overridable
top-level Stdout is passed along to make progress bars
Currently, if you try to use a snap with an app named "test", os.Args will also
end in ".test", making numerous places in the codebase think that it is being
run in a test environment and behave differently. In the case of the reported
bug, the code panics from `snap run` as it seems to the mountinfo code that we
are not mocking something that we should always be mocking in unit tests.
The bug could still hypothetically happen if someone made a symlink from
somewhere with "go-build" in the path (but not as part of the app name in the
snap) and a .test suffix on the executable, but this is sufficiently specific
that it is highly unlikely we would ever actually run into that problem "in the
wild".
Fixes: https://bugs.launchpad.net/snapd/+bug/1886786
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
* progress: tweak multibyte label unit test data
Since the progress bar calculates speed based on actual time, any
flakyness/delay in test execution may influence the reported value. Account for
that in the regex.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
* progress: drop unused field in unit tests
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
* progress: one more format tweak
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
Some languages may use multibyte characters for duration. In such case, the
width of the progress bar would be incorrectly calculated, making the displayed
label too short.
At runtime this would randomly cause a panic with the translation used a
multibyte characters:
panic: runtime error: slice bounds out of range [80:79] [recovered]
panic: runtime error: slice bounds out of range [80:79]
goroutine 1 [running]:
main.main.func1()
github.com/snapcore/snapd/cmd/snap/main.go:477 +0x95
panic(0x561d5f7fac80, 0xc000144280)
runtime/panic.go:679 +0x1b6
github.com/snapcore/snapd/progress.(*ANSIMeter).Set(0xc000214eb0, 0x41a891a000000000)
github.com/snapcore/snapd/progress/ansimeter.go:152 +0xa1b
main.waitMixin.wait(0xc0002e42a0, 0x561d5f3e0000, 0xc0001e4488, 0x2, 0x0, 0x0, 0x0)
github.com/snapcore/snapd/cmd/snap/wait.go:130 +0x700
main.(*cmdInstall).installOne(0xc000359040, 0x7ffcf44c33e4, 0xb, 0x0, 0x0, 0xc00036cba0, 0x561d5f805060, 0x561d5f8693a0)
github.com/snapcore/snapd/cmd/snap/cmd_snap_op.go:491 +0x316
main.(*cmdInstall).Execute(0xc000359040, 0xc0003787a0, 0x0, 0x2, 0xc000359040, 0x1)
github.com/snapcore/snapd/cmd/snap/cmd_snap_op.go:596 +0x3d7
github.com/snapcore/snapd/vendor/github.com/jessevdk/go-flags.(*Parser).ParseArgs(0xc000316bd0, 0xc000032190, 0x2, 0x2, 0xc000330330, 0xc0002a5cd0, 0x561d5ee49fbd, 0x561d5f7d08a0, 0xc000330330)
github.com/snapcore/snapd/vendor/github.com/jessevdk/go-flags/parser.go:333 +0x8e7
github.com/snapcore/snapd/vendor/github.com/jessevdk/go-flags.(*Parser).Parse(...)
github.com/snapcore/snapd/vendor/github.com/jessevdk/go-flags/parser.go:190
main.run(0xc0002a5de0, 0xe)
github.com/snapcore/snapd/cmd/snap/main.go:515 +0xa7
main.main()
github.com/snapcore/snapd/cmd/snap/main.go:482 +0x371
Since we are assuming that terminal can display up to the column number of
runes, fix the length calculation to use slices of runes for all
components (keep in mind that len(string) >= len([]rune)).
Fixes: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1876583
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
minicom's vt220 implementation was improperly displaying half of
cvvis. It seems it can't handle CPI codes separated by ;, and fails to
ignore the unknown escape.
This simplifies it, but it still does what we want (the cvvis we were
using, taken from terminfo for xterm, was additionally doing an 'echo
on', which we don't need).
Additionally I received feedback about the spinner being nastier than
the old slash-based one, so I moved to that.
... some day I might make that customisable :-)
Package progress had some useful formatting functions (originally
taken from github.com/chipaca/quantity), that are more generally
useful. Circular imports mean they can't be in strutil directly
(quantity uses i18n which uses strutil), but strutil/quantity seems
fine to me.
This introduces a `progress.Meter` written from "scratch" (mostly based on
previous work and experiments I did on IO progress bars and fixed-width
displays). It's called `progress.ANSIMeter`.
We were using a `progress.NullProgress` in situations where we actually didn't
want progress bars but still wanted notifications, so `progress.QuietMeter` is a
`progress.Meter` that does that, and that is returned by
`progress.MakeProgressBar()` when it doesn't think we have an actual terminal.
We were replacing `os.Stdout` to look at the output of progress bars, so I wrote
`progresstest.Meter` that just records what it's told instead of printing it
anywhere, and use it in some places.
I renamed `progress.NullProgress` to `progress.NullMeter`, and added
`progress.Null` as a default `progress.NullMeter`; as it's a `struct{}`, it
doesn't make sense not to use that (we were using `&progress.NullMeter{}` in
many many tests).
`image` was not calling `Finished()` on the progress bar, so I added code for it to
do that both in the sane case and in the case the user `^C`'s out.
