Feature Report: Add config key/command line option to suppress number of entries found

[Chien-pinWang]

Use Case/Motivation

I used to pipe jrnl titles to fzf and build my own jrnl reader for reading/editing and stuffs. The feature of reporting number of entries found was excellent. However it broke my jrnl reader and I got no way to filter those lines out. I tried to pipe the jrnl --short command to head, tail, grep and alike and still got the first 3 lines reporting number of entries found. I looked through the docs and help and git issues but failed to find a way to eliminate those 3 lines.

It would be nice to have either a key in jrnl.yaml or a command line option that can switch reporting number of entries found. Thanks a lot!

Example Usage

jrnl --entries-found false or

entries_found: false in jrnl.yaml

Other Information

No response

[micahellison]

Hi @Chien-pinWang, thanks for filing this issue, and I'm sorry that this change broke your process. I think this is a good idea, and that the config file is probably appropriate for this setting. Maybe it could be called suppress_entry_counts or something similar so its meaning is clear without context.

However, I think there may be a solution to this problem without having to wait for a new jrnl release. These "entries found" messages are only sent to STDERR, while the contents of the journal are sent to STDOUT. I think that by default, most systems pipe only to STDOUT unless otherwise specified. For instance, if you're using |& to pipe with bash, you should be able to get around this by using | instead. You'll still see the "entries found" message in your terminal, but it won't be consumed by head, tail, or grep.

I also don't see any documentation about that behavior, so we'll want to make some documentation changes as a result of this too. Maybe in our "Tips and Tricks" or "Advanced Usage" sections.

[Chien-pinWang]

Hi @micahellison thank you for your quick response. And I just learned a new lesson from your reply that what you see on the screen is not necessarily from STDOUT! It would be nice to say something about that some where in the docs.

Thanks and keep up the great work!

[micahellison]

Thinking about this some more -- rather than suppressing a single message, I think it's best to tie this to a broader verbosity setting like in #1312. Maybe still include a config key as well.

[dradux]

Its odd to have the number of entries found go to STDERR - not something most *nix users would expect of a CLI app. The logical choice in my opinion would be to have this to STDOUT and controllable via config option; however, the way it is now is easier to filter out if there is no config option.

jrnl --short -and @runner | less
┏━━━━━━━━━━━━━━━━━┓
┃  1 entry found  ┃
┗━━━━━━━━━━━━━━━━━┛
  2022-08-25 05:31 The Runner

jrnl --short -and @runner 2> /dev/null  | less
  2022-08-25 05:31 The Runner

The downside here is you hide any errors that might arise - likely not a problem on listing jrnls but if you want to use the same trick while editing a jrnl it can be an issue

[micahellison]

Its odd to have the number of entries found go to STDERR - not something most *nix users would expect of a CLI app

I can understand why someone might find this behavior surprising, but the distinction between stdout and stderr was created in Unix for this kind of scenario. Its creators found that mixing error and diagnostic messages with normal output made it unpredictable to pipe data. That would be the exact problem for anyone piping jrnl's output if these messages were sent to stdout. So I'm confident that stderr is still the right output stream for these messages.

jrnl --short -and @runner | less
┏━━━━━━━━━━━━━━━━━┓
┃  1 entry found  ┃
┗━━━━━━━━━━━━━━━━━┛
  2022-08-25 05:31 The Runner

In this example, less actually isn't doing anything with the "1 entry found" message. It's going directly to the terminal, then less is processing the journal entry data.