dalance / pipecolor Goto Github PK

I've started using pipecolor with the unit-test log output from the project I work on, and it's great.

However, in one scenario the output cuts off early with the message Error: stream did not contain valid UTF-8. I made sure this only happens when piping through pipecolor, so the message is not coming from our code.

It appears that something in a test of ours is writing some binary data to the log; so pipecolor is correct that there's invalid UTF-8 in the stream. However, it should not give up when this happens; it should just write the offending line as-is and go on to the next one. Otherwise it ends up hiding information from the user.

(PS: I'm running the latest version of pipecolor, built via cargo, on macOS 12.6.5.)

Hi,

I wonder is there a way to activate (/g) flag for regex match:

Example:
/(\d+)/g  --> highlighting all numbers.

1. It would be nice if the tokens property were optional. Many of my rules don't use tokens, so I forget to add them, but currently it's a fatal error if a lines block doesn't contain a tokens property.
2. It would be handy if there were some color synonyms, so I didn't have to remember the exact names. For example, "Gray" as a synonym for "LightBlack", or "Orange" for "Yellow".

Hi! Pipecolor looks like a tool that would be very useful to me, so I've decided to give it a go.

I have tried following the instructions in README.md to create a simple rule that would colourise an entire line based on a regex.

My ~/.pipecolor.toml is

[[lines]]
	pat = "^This is a test message to see if (VARIANT1|VARIANT2|ETC).*"
	colors = ["Magenta"]
	[[lines.tokens]]
		pat = ""
		colors = []

The file I'm testing it on contains these 2 lines

-- Some uninteresting message
This is a test message to see if VARIANT1 is colourised by pipecolor

Running RUST_BACKTRACE=1 pipecolor --mode always test.log results in

-- Some uninteresting message
thread 'main' panicked at 'index out of bounds: the len is 1 but the index is 1', /build/rust/src/rustc-1.38.0-src/src/libcore/slice/mod.rs:2715:10
stack backtrace:
   0: std::panicking::default_hook::{{closure}}
   1: std::panicking::default_hook
   2: std::panicking::rust_panic_with_hook
   3: std::panicking::continue_panic_fmt
   4: rust_begin_unwind
   5: core::panicking::panic_fmt
   6: core::panicking::panic_bounds_check
   7: pipecolor::colorize::colorize
   8: pipecolor::output
   9: pipecolor::main
  10: std::rt::lang_start::{{closure}}
  11: std::panicking::try::do_call
  12: __rust_maybe_catch_panic
  13: std::rt::lang_start_internal
  14: main
  15: __libc_start_main
  16: _start
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Am I doing something wrong?

error[E0432]: unresolved import `nix::poll`
  --> /usr/ports/deskutils/pipecolor/work/pipecolor-0.4.2/cargo-crates/timeout-readwrite-0.1.0/src/lib.rs:46:5
   |
46 | use nix::poll;
   |     ^^^^^^^^^ no `poll` in the root

For more information about this error, try `rustc --explain E0432`.
error: could not compile `timeout-readwrite` due to previous error

rust-1.66.0
OS: FreeBSD 13.1

In a similar way to what https://github.com/garabik/grc does, pipecolor could provide some configuration files targeted at colorising the output of specific tools like dig, ip, kubectl, etc.. And a wrapper to invoke pipecolor with the correct config file.

Hi,

Nice work! Any chance you will support single-binary releases in the future?

I would love to not have to download the pipecolor.toml file in case I don't have it (say I download the binary on a server in the cloud).
Ideally, pipecolor would have a fallback if no configuration is specified.