Oplog: an opinionated logging shard

Community
1

This is a tiny shard, but one I use in all my projects. It just sets logging the way I like for CLI tools:

  • Colorized (when it makes sense)
  • Error and worse to stderr
  • Everything else to stdout
  • Configurable logging level 0-6 (defaults to 4, info)

To use it just

require "oplog"

Oplog.setup

Available at GitHub - ralsina/oplog: Opinionated logging setup for Crystal

2 Likes
2

I’m quite surprised about this. What’s the point of splitting log output to different streams?

3

I use log for all program outputs.

Output that is informational should go to stdout, errors should go to stderr, because that’s what they are for.

I may be slightly abusing logging by using it for what are not really logs tho.

4

I’ve been wanting this for a while.

Typical UNIX programs send the valid output you expect to stdout, and any error messages to stderr, so that if you want to capture the output, you won’t capture the error messages. I think this might be because it is difficult to separate them after the fact.

For example,

% find . -name '*foo*' > foo-files.out
./some/dir: permission denied

If you have the output combined, you’d have to look for those error messages and remove them from the file list based on a pattern. But what if there’s a file called dir: permission denied?

In a shell (bash, for example) script, it’s really easy to do:

if find "$dir" -type f > "${tmpdir}/files.out" 2> "${tmpdir}/error.out"; then
  if [ -s "${tmpdir}/error.out" ]; then
    echo "find exited with success but there were some individual errors"
  else
    echo "find exited with success and there were no error messages"
  fi
fi

(untested code off the top of my head)

It’s just so much easier for me to do: /path/to/foo --options >/dev/null to see only the error messages, rather than trying to make an inclusive or exclusive pattern for a grep.

I know that’s not going to be “easy” to many other people, but “old Unix sysadmins” like me just think that way.

That’s why I’m very happy with this.

1 Like
5

Yeah, totally.
But I would argue that per UNIX philosophy programs usually do not print anything if they’re successful. If a program has some inherent output, Log is probably not the right tool for that.
So my argument is that Log output always go to stderr (or somewhere else), never to stdout.

1 Like
6

image

As always the answer is “yes and no” that’s why I say this is just “opinionated” :slight_smile:

As you can see, rm, as unixy a tool as it comes, will happily print to stdout what you are deleting successfully if you ask it to be verbose.

With oplog, I would put that as Log.info, make the default versbosity error, and make -v set it to info

7

This shard do good job for it purpose, and especially suitable for UNIX command line program, the only concerns is, is it appropriate to name it as Log ?

8

It just configures crystal’s Log module

9

The word “opinionated” is often misused, especially in open-source projects.
All projects already reflect the decisions of their creators and using “opinionated” is tautology.
Additionally, authors often use “opinionated” to deflect criticism, which now carries a negative connotation.

These observations come from my experiences with various open-source projects and sometimes within private companies too.

10

Well, I found a minor bug in the crystal tooling because logging and just outputting don’t mix well.

And I don’t think it feels right to use two different methods to make output.

I see your point, but it can be a bit mucky what’s output and what’s logging.

In most of the CLI frameworks I’ve crossed (in PHP land, which might not be the best example), they like to hand over a class to take care of output with appropriate methods for info, errors perhaps table output. And then completely ignore the difference between stderr and stdout, sadly…

11

In my opinion I am using it correctly :joy:

1 Like