# Issue #3, How to properly use it with kubectl logs -f ?

https://github.com/alexsavio/cor-cli/issues/3

**Labels:** -
**Milestone:** -

## Context

One of the examples in the README is this:

```bash
kubectl logs my-pod | cor --level warn
```

This works as expected.

However, if I add the `-f` or `--follow` flag to the `kubectl` command to keep watching the logs, it doesn't work. Nothing is printed.

I guess that's due to buffering, so I tried adding different things like `less -R`,  `stdbuf` and `script` with no success. Using `tee` to save the output of kubectl to a file while piping the logs `cor` I could confirm that it is receiving the logs but not printing anything.

I searched for a `cor` command line option related to buffering but it seems there is none.

What is the proper way to do it?

Thanks

Version: cor 2026.3.1
OS: Linux x86_64

## Acceptance criteria

- [x] Streaming input (`kubectl logs -f`, `tail -f`, etc.) prints lines as they arrive without waiting for EOF or full buffer — fixed by replacing `BufWriter::new(stdout.lock())` with `LineWriter::with_capacity(8 * 1024, stdout.lock())` in `src/main.rs`. `LineWriter` flushes whenever a `\n` is written; `write_entry` already terminates every entry with `writeln!`, so per-entry flush is automatic.
- [x] Output is flushed per line so downstream pagers / tee see each line immediately — same fix; `LineWriter`'s flush-on-newline contract delivers this for both formatted JSON entries and raw passthrough lines.
- [x] Existing batch behavior unchanged; tests still pass — 100 pre-existing integration tests still pass; the 7 demo screenshots regenerated byte-identical to `main`.
- [x] Add regression test covering line-streaming flush behavior — added `tests/integration/streaming.rs` with three cases: short JSON line flushed before EOF, raw passthrough line flushed before EOF, and a >2 KiB JSON entry flushed before EOF (covers the LineWriter capacity bump).

## Notes

### Live reproduction (before / after)

Slow producer (1 line/sec, 5 lines), reader timestamps each line as it arrives.

```text
LineWriter (this branch):
[19:52:06.690]  INFO: line 0
[19:52:07.294]  INFO: line 1     # 1.0 s gap, line streamed live
[19:52:08.295]  INFO: line 2
[19:52:09.295]  INFO: line 3
[19:52:10.296]  INFO: line 4

BufWriter (main, before fix):
[19:53:58.174]  INFO: line 0     # all 5 lines arrive
[19:53:58.174]  INFO: line 1     # at the same timestamp,
[19:53:58.174]  INFO: line 2     # held in the 8 KiB block
[19:53:58.174]  INFO: line 3     # buffer until producer EOF.
[19:53:58.174]  INFO: line 4
```

Reproduction command:

```bash
python3 -c "
import time
for i in range(5):
    print(f'{{\"level\":\"info\",\"msg\":\"line {i}\"}}', flush=True)
    time.sleep(1)
" | cor --color=never | python3 -c "
import sys, time
for line in sys.stdin:
    print(f'[{time.strftime(\"%H:%M:%S\")}.{int((time.time()*1000)%1000):03d}] {line}', end='', flush=True)
"
```

### Why `LineWriter` over keeping `BufWriter` + manual flush

- `LineWriter` is the standard library primitive for "buffer writes, flush on newline" — exactly the semantics a TTY-bound stdout already gets from libc. Using it makes the binary behave the same whether stdout is a terminal, a pipe, or a redirected file.
- Capacity matched to the previous `BufWriter::new` default (8 KiB) so long formatted lines (many fields, large values) still get coalesced before the trailing `\n` triggers the flush. `LineWriter::new` would default to 1 KiB.
- Alternative ("`BufWriter` + `writer.flush()` after each `write_entry`") works but adds a flush call to every write path and is easier to forget on a new code path. Same syscall cost, more surface area.
- An auto-detect "TTY → line-buffer, pipe → block-buffer" approach was considered and rejected: it gets the kubectl-logs-f case wrong (pipe target) and adds a branch per write.
