The --nostdin argument doesn't appear to have the stated effect
LeXofLeviafan opened this issue · comments
According to the manpage, it's supposed to disable reading from stdin (which should result in a completely non-interactive, CLI-only usage that ignores piped input).
However, using it doesn't prevent buku from entering the interactive mode (whether as a result of an operation or when passing no other arguments) which absolutely requires reading from stdin, and reading commands from stdin (e.g. supplied with echo) isn't prevented by this option either.
If this is the intended behaviour, then the purpose of the option isn't clear from the docs.
This wasn't about preventing from entering the interactive mode. This was about piping data to buku. Please check the history why it was added.
Three problems here:
- Users should be able to tell the purpose of the option from reading the docs, without having to delve into commit history.
- Piping data to buku works even without
piped_input()– only the syntax is affected (CLI arguments vs shell commands). Which doesn't seem to be mentioned anywhere in the docs – in fact, I can't seem to find any mention of even the possibility of supplying CLI arguments via stdin at all. - The condition should be
len(sys.argv) < 2 or …– otherwise running buku with no arguments (which is how it'd normally be used if the args are meant to be supplied via stdin instead) doesn't trigger thepiped_input()call.
Also, in the second check len(sys.argv) <= 2 and … is an excessive condition, as the other part checks the same value explicitly.
You are a developer, not a user.
If you want to document it better, feel free to do so. But no code changes for this. We can't keep going back for corner cases.
A feature being unusable in the primary scenario where it would be used is not exactly a "corner case" though.