tywil04 / slavartdl

Simple tool written in Go(lang) to download music using the SlavArt Divolt server
GNU General Public License v3.0
17 stars 1 forks source link

Feature request: silent/semi-silent mode #19

Closed bacon-cheeseburger closed 1 year ago

bacon-cheeseburger commented 1 year ago

Often times users don't need/want detailed output, or just an exit code and no output at all. Please consider adding a -s/--silent option that suppresses all output and only supplies the appropriate exit code. And then a -q/--quiet mode that prints error output and the appropriate exit code. Or an alternative is to only print all the output (like getting download link, downloading, unzipping, etc) when a --verbose flag is set, otherwise the default is to be quiet unless there's an error.

A third option could be storing an output "level" in the config. Default could be "verbose", with other possibilities as "errors" and "silent".

"output_level": "verbose" (shows all output) "output_level": "errors" (only shows errors) "output_level": "silent" (doesnt show anything, only appropriate exit code is provided)

tywil04 commented 1 year ago

I think being verbose by default is probably better for this sort of tool, but I can see why people might want options to mute unimportant logs if they wanted to.

I like the idea of being able to specify how verbose the tool should be. I think the naming should be along the sides of logs and it can be one of all, errors, silent. all would print everything, errors would only print errors and silent would never print to the console - even if something goes wrong (it would just stop running with no output)

tywil04 commented 1 year ago

This appears to be a little more complicated then originally planned. The framework I am using for command line stuff handles error printing. It can be turned off, just not at runtime which means I can't easily disable errors from being printed. I will continue to look for some work arounds.

bacon-cheeseburger commented 1 year ago

Rather than having errors printed directly from the error handling, could you store the errors in an error array and then either print the array or not based on the log level? Basically just letting the error import catch the error, save it, then you decide what to do with it rather than the error import. I'd think that could be one way to bypass the runtime limitation..?

tywil04 commented 1 year ago

I just pushed a commit that introduces a logLevel flag. It takes the options all, errors or silent. There is one slight limitation and it is that any error regarding the config (default or custom) will be logged. This is because I need to load the config to check the log level set. Permanently disabling config related errors isn't a viable option either.

It turned out to be a really simple workaround, I was using a function that returned an error which the framework would then print. I just changed what I returned and instead handled printing errors when the arise. As of this moment in time, all errors are fatal (they kill the running instance with an error code of 1). I am open to the possibility of making some errors non-fatal.

Commit if interested: https://github.com/tywil04/slavartdl/commit/26602516ab11941971cbc88c4178e85bb97bcc39