Not respecting 'fancy' stdout re-piping

[CodyCBakerPhD]

I wanted to wrap

goaccess ./combined/combined.log -o goaccess_report.html   --log-format=AWSS3

with duct

Normally looks like this

but with duct looks like

[yarikoptic]

oh that special goaccess: #261

most likely goaccess detects that there is no pty for stdout (or may be even stdin) and thus changes progress reporting -- nothing we could do per se besides switching/supporting originally done implementation which would mimic terminal.

[CodyCBakerPhD]

Could go the way of other task trackers (Windows/Mac/top/pyspy) or wireshark and have duct be a separate terminal/listener, and have some special way of signalling the process you want that listener to track from an independent terminal

[CodyCBakerPhD]

Hmm it's also not behaving too well with TQDM progress bars either; freezes up and stops re-piping the output after a couple of iterations

[asmacdo]

@CodyCBakerPhD yep, i have a WIP doc fix at #427 (sloppy atm, will revise later)

Separate-terminal/listener could fix it (nothing duct does sits between command and TTY), but how to actually capture the stdout/stderr gets messy (I didnt dig in very deeply though, maybe I missed something).

History: we used to allocate a PTY for the child (TeeStream), replaced by TailPipe in #29. The problem was #26, TTY-aware programs pollute the logs with ANSI escapes, violating "do not obscure stdout/stderr". Probably revivable as an opt-in --pty flag if someone wants to scope it. See also #370 for a different reason I considered reviving TeeStream.

How do your TQDM progress bars handle output piping straight to a file (no tty)?

[CodyCBakerPhD]

How do your TQDM progress bars handle output piping straight to a file (no tty)?

That's only typically used for tests; each update adds a line to the end

[] | []
[] || []
[] ||| []