Hacker News new | past | comments | ask | show | jobs | submit login

One consequence of "the rule of silence" is that sometimes it is not obvious if a command is processing data or waiting for input, there is no visual difference.



That's more an occasional annoyance than a real problem though. The only commands that don't prompt when waiting for input are commands that are written specifically for stream processing from stdin. In which case the user should already be aware of it's behaviour because they're either already familiar with the command or have have consulted it's man page (or similar reference) before executing it. So the unprompted waiting for using input is a bug in a shell script / command line pipe and thus usually pretty quick to debug.

Going back to the man page point: I will granted you that not everyone does check what a program does before running it. Sadly in those instances there's little you can do to protect them from themselves. It's similar to how you cannot protect people from blindly copying and pasting code from the internet. If someone is willing to run a command "blind" then the usefulness of the output is the least of their worries.


I was more thinking of a situation where you have misunderstood the syntax of a command or forgot to type an argument.


I did cover that point. :)


This is why well-behaved programs prompt for input. Like bash, e.g.


With cat being the notable exception :-)


And grep.

Programs that use the input and output to carry data around can not show prompts to the user.


A workaround is to prompt on STDERR. Data input will enter the same place, and output will be distinguished from the text for prompts.


You can often just check by hitting ^D, but yes, this is a workaround, not a fix.


Or if it has failed silently.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: