Normalized output (allow an option for non-human readable output)

[crozone]

Overview

An option for normalized output in bytes (aka a non-human readable form) would allow for easier machine processing of the output.
For example, normalized results could be trivially plotted over time.

Currently the result is always printed in human readable form, which makes the magnitude of the numeric result change depending on its unit. Machine processing requires post-processing of the result in order to get it back into bps, which is cumbersome to do from the command line. The resultant line also includes additional whitespace prefixing, which makes processing in bash even more cumbersome.

Example

Example of current output:

$ fast-cli --simple
  47.19 Mbps

Example of normalized output:

$ fast-cli --simple --normalized
47190000

Workaround

Current workaround is to use numfmt (available in debian coreutils package):

$ fast-cli --simple | numfmt --from=auto --suffix=bps -d \n
47100000bps

However, this still includes a "bps" suffix which must be removed.

Changes

This would require parsing an additional argument, and adding an extra case in main.go:

fast-cli/main.go

Lines 161 to 163 in 7d2b485

	} else {
	fmt.Printf("%s\n", format.BitsPerSec(bandwidthMeter.Bandwidth()))
	}

[gesquive]

Thanks for the suggestion. I'll think about including something like this in a future release

[adabru]

ChatGPT was suggesting sindresorhus/fast-cli as lightweight alternative to speedtest-cli from ookla for bandwidth monitoring. The Go binary approach is definitely more lightweight than the npm module approach.

Reference: https://github.com/sindresorhus/fast-cli?tab=readme-ov-file#usage

[crozone]

ChatGPT was suggesting sindresorhus/fast-cli as lightweight alternative to speedtest-cli from ookla for bandwidth monitoring.

This truly shows that ChatGPT has no idea what it's talking about, it should be a crime to describe a nodejs project as "lightweight"😅 That version is absurdly bloated and slow for a simple CLI tool - I clocked it downloading hundreds of megabytes of dependencies during a fresh installation. It's comically bad.

Keeping on topic though, @adabru are you suggesting an equivalent --json output as a solution to this particular issue?

{
	"downloadSpeed": 52,
	"uploadSpeed": 64,
	"downloaded": 270,
	"uploaded": 290,
	"latency": 9,
	"bufferBloat": 46,
	"userLocation": "Somewhere, NO",
	"userIp": "49.222.206.21"
}

[adabru]

Where do/did you want to integrate fast-cli? Does your code support JSON parsing?

I think it wouldn't hurt to have a somewhat compatible API to the currently more popular npm tool.

[crozone]

Where do/did you want to integrate fast-cli? Does your code support JSON parsing?

I think it wouldn't hurt to have a somewhat compatible API to the currently more popular npm tool.

My usecase is simple scripting with bash/perl to periodically log and monitor bandwidth, do alerting, stuff like that. My use case is not for integration with any complex software stack but really just lightweight, standard Linux tools and utilities. For this usecase it's helpful if the tool can output raw integers, instead of human readable data, otherwise an entire extra parsing step is required to get it from the human readable version. This is why most unix tools default to a "raw" output, and have human readable behind a "-h" flag.

JSON output is a good idea in general since it can be easily parsed with jq and provides all the information all at once, although I think that should probably be considered as an entirely separate feature.

For the --simple output where all that matters is a single value for download speed, some a --normalized or --raw flag would be a simple and effective solution.