Document TTY-detection limitation for goaccess, tqdm, etc.

README.md

@@ -290,3 +290,22 @@ $ duct --log-level DEBUG echo "hello world"
 By default, [git-annex](https://git-annex.branchable.com/) treats all dotfiles, and files under directories starting with a `.` as "small" regardless of `annex.largefiles` setting [[ref: an issue describing the logic](https://git-annex.branchable.com/bugs/add__58___inconsistently_treats_files_in_dotdirs_as_dotfiles/?updated#comment-efc1f2aa8f46e88a8be9837a56cfa6f7)].
 It is necessary to set `annex.dotfiles` variable to `true` to make git-annex treat them as regular files and thus subject to `annex.largefiles` setting [[ref: git-annex config](https://git-annex.branchable.com/git-annex-config/)].
 Could be done the repository (not just specific clone, but any instance since records in `git-annex` branch) wide using `git annex config --set annex.dotfiles true`.
+
+### My command behaves differently under duct (e.g. `goaccess` fails, progress bars look off)
+
+By default, duct starts the wrapped command in a new session (`start_new_session=True`; `--mode new-session`), so the child has no controlling terminal, and duct attaches pipes to its stdout/stderr instead of a PTY.
+Programs that inspect `isatty()` to decide how to behave will therefore take their non-interactive path under duct, and the result may be surprising.
+If you run duct with `--mode current-session`, this session detachment does not happen.
+Two examples:
+
+- Under duct, [`goaccess`](https://goaccess.io) may require an explicit `-` argument to force stdin mode; otherwise it can exit with `No input data was provided` in this non-TTY/piped setup [[ref: con/duct#261](https://github.com/con/duct/issues/261)].
+  Pass `-` (e.g. `... | goaccess - --log-format=AWSS3 -o report.html`) to force stdin mode.
+- Progress-bar libraries such as [`tqdm`](https://tqdm.github.io) may render differently when stdout/stderr is a pipe rather than a TTY [[ref: con/duct#426](https://github.com/con/duct/issues/426)].
+
+To check whether a given problem is a TTY issue and not a duct bug, reproduce it outside duct with `setsid`, which similarly detaches the controlling terminal:
+
+```bash
+setsid bash -c "your command here" > out.log 2>&1
+```
+
+If the symptom reproduces under `setsid`, develop and test the non-interactive flag set there; the command will then behave the same way under duct.