What’s the problem
kadnode-ctl supports taking a command from arguments (kadnode-ctl status) and from stdin (echo status | kadnode-ctl).
The program does not check whether there is a command in the arguments; instead it checks “is this running in a TTY?”:
- if started from a terminal (interactive) - it takes the command from arguments.
- if started “not from a terminal” (automation, remote execution) - it does not look at arguments at all and waits for a command from stdin. That is the problem.
In many normal automation scenarios, people use arguments.
But kadnode-ctl silently ignores the arguments and switches to reading stdin.
And if there is no command on stdin, it does not report an error - it just prints the help text (Usage), which makes it look like “something is broken in scripts”.
This is an architectural error: the behavior depends on the environment rather than on what the user actually provided - and that makes the behavior “unpredictable”.
How it should work (a more predictable contract)
- If a command is provided in arguments - use it, and ignore stdin.
- If there are no arguments - then keep the current behavior with the TTY check and possible reading from stdin.
- Add a separate explicit
--stdin mode.
- If stdin mode is active but stdin is empty - print an explicit error.
В чём проблема
kadnode-ctl поддерживает команду из аргументов kadnode-ctl status и из stdin echo status | kadnode-ctl.
Программа смотрит не на то, есть ли команда в аргументах, а на "происходит-ли запуск в TTY?":
- если запуск из терминала (интерактивно) - берёт команду из аргументов.
- если запуск “не из терминала” (автоматизация, удалённый запуск) - не смотрит на аргументы вообще и ждёт команду из stdin. Это проблема.
Во многих нормальных сценариях автоматизации используются аргументы.
Но kadnode-ctl тихо и без уведомления игнорирует аргументы и уходит в режим чтения stdin.
При этом если команды в stdin нет, она никак не сообщает об ошибке - просто печатает справку (Usage), из‑за чего выглядит так, будто “что-то сломалось в скриптах”.
Это архитектурная ошибка: поведение зависит от окружения, а не от того, что реально передал пользователь - и это делает поведение "непредсказуемым".
Как должно быть (более предсказуемый контракт)
- Если команда передана в аргументах - использовать её, а stdin игнорировать.
- Если аргументов нет - тогда текущее поведение с проверкой TTY и возможным чтением из stdin.
- Отдельный явный режим
--stdin.
- Если активен режим stdin, но stdin пустой - печатать явную ошибку.
What’s the problem
kadnode-ctlsupports taking a command from arguments (kadnode-ctl status) and from stdin (echo status | kadnode-ctl).The program does not check whether there is a command in the arguments; instead it checks “is this running in a TTY?”:
In many normal automation scenarios, people use arguments.
But
kadnode-ctlsilently ignores the arguments and switches to reading stdin.And if there is no command on stdin, it does not report an error - it just prints the help text (
Usage), which makes it look like “something is broken in scripts”.This is an architectural error: the behavior depends on the environment rather than on what the user actually provided - and that makes the behavior “unpredictable”.
How it should work (a more predictable contract)
--stdinmode.В чём проблема
kadnode-ctlподдерживает команду из аргументовkadnode-ctl statusи из stdinecho status | kadnode-ctl.Программа смотрит не на то, есть ли команда в аргументах, а на "происходит-ли запуск в TTY?":
Во многих нормальных сценариях автоматизации используются аргументы.
Но
kadnode-ctlтихо и без уведомления игнорирует аргументы и уходит в режим чтения stdin.При этом если команды в stdin нет, она никак не сообщает об ошибке - просто печатает справку (
Usage), из‑за чего выглядит так, будто “что-то сломалось в скриптах”.Это архитектурная ошибка: поведение зависит от окружения, а не от того, что реально передал пользователь - и это делает поведение "непредсказуемым".
Как должно быть (более предсказуемый контракт)
--stdin.