Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor the way output works #74

Closed
srid opened this issue Apr 7, 2021 · 8 comments
Closed

Refactor the way output works #74

srid opened this issue Apr 7, 2021 · 8 comments

Comments

@srid
Copy link
Contributor

srid commented Apr 7, 2021

I use the following script to bulk move emails to another folder:

himalaya -o json search subject Stripe | jq '.[].uid' | xargs -n 1 -I {} himalaya move {} Folders/FinanceLog

This script doesn't output anything, so I have no way of knowing the list of messages that just got moved by that command (that I constructed on the fly). I can script the logging manually, but it would be more convenient if the CLI had an option to log all mutable actions that himalaya takes on my mail account.

@soywod
Copy link
Member

soywod commented Apr 8, 2021

In fact the move command (as well as other commands like copy, delete etc) should display a log by default (without any verbose mode). I prefer to introduce a --silent or --quiet flag to disable output instead.

@soywod soywod self-assigned this Apr 8, 2021
soywod added a commit that referenced this issue Apr 8, 2021
@soywod
Copy link
Member

soywod commented Apr 8, 2021

Logs added for copy, move and delete commands + add a --silent flag to disable them. It will be added to the next release!

@soywod soywod closed this as completed Apr 8, 2021
@srid
Copy link
Contributor Author

srid commented Apr 8, 2021

Should --silent be ignored in some commands? For eg., both h --silent and h -o json --silent outputs nothing, but h and h -o json normally would output the list of messages.

Perhaps it would be helpful to distinguish between two kinds of outputs: "content" vs "logging". And use --silent to suppress only the later kind.

@soywod
Copy link
Member

soywod commented Apr 8, 2021

It's a good point indeed, I like the idea!

@soywod soywod reopened this Apr 8, 2021
@soywod soywod changed the title Verbose mode Refactor the way output works Apr 8, 2021
@soywod
Copy link
Member

soywod commented Apr 8, 2021

Perhaps it would be helpful to distinguish between two kinds of outputs: "content" vs "logging".

In fact it depends on the ouptut type. For text then indeed you have content and logging. But for json you can only have content. I have an idea on how to implement this, I let you know!

@srid
Copy link
Contributor Author

srid commented Apr 8, 2021

Another idea that comes to mind is to send all logging output to stderr, leaving regular output to stdout. Then quiet behaviour can also be achieved using himalaya ... 2> /dev/null (this is the approach used by neuron). But then I wonder if there are better ways.

@soywod
Copy link
Member

soywod commented Apr 8, 2021

I am not so fan of this idea, it sounds a bit "hacky". I prefer to keep the stderr for errors only.
I have a working prototype based on the log crate and the env_logger crate:

  • A new arg is introduced (and replaces --silent): --log or -l that defines the log level (one of error, warn, info, debug, trace as defined in the log crate)
  • The PLAIN output will show logs depending on the given log level (info is the standard default one)
  • The JSON output will show only info and error logs:
    • info logs are serialized to JSON strings
    • error logs remains plain strings (this way, a client knows that a command fails if he can't parse the JSON)
  • error logs are sent to the stderr channel, and all other logs are sent to the stdout one (no matters the output format)

soywod added a commit that referenced this issue Apr 8, 2021
@soywod soywod closed this as completed Apr 8, 2021
@soywod
Copy link
Member

soywod commented Apr 8, 2021

Added in v0.2.4 🎉

@soywod soywod added this to the v1 milestone Apr 17, 2021
@soywod soywod removed their assignment Feb 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants