Martin Wheatley wrote: > Description: > Bash may inadvertently execute a command that the user did not > anticipate if STDIN is closed.
The shell reads data from the input. It then parses the input into commands and executes them. If this is not what you want then you must avoid closing the input stream with a valid command in the stream. > Unfortunately I can't construct a test case that doesn't need > our local s/ware. Then that will make it difficult to understand your problem. > But the problem is ... > > When bash reads input (in interactive mode) if it gets EOF it > then executes any partial command that is in the input buffer - even > though <CR> has not been entered by the user Can you construct an example where a bash user can interactively create eof without making such an action intentional? Can this happen accidentally? I can only think of very difficult ways to do this and so they would not happen accidentally. > Fix: > Incomplete commands should not be executed - they can have disasterous > results. One person's incomplete command is another person's completed command. Can you provide an example where a bash user could accidentally interactively terminate the input stream? Is there an example of another command shell which handles this situation in a different and possibly better way? I think this issue is just like others. ls *~<ENTER> ...yes.those.are.the.files... rm *<ENTER> ...aaaarrrggh!... The truly paranoid form dangerous commands with a # first and then delete the comment character after the command is fully formed. Bob _______________________________________________ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
