>> No, no, no, it should be continue! >> >> This is just semantics of handling possible empty lines. In case of >> continue, we just ignore empty lines and keep reading stdin. In case >> of break, first empty line abort the process. >> The process is over when stdin is finished, fgets returns false then >> and while loop is over. stdin is finished >> - if you run it manually, when you press Ctrl-D >> - if you redirect from pipe or file - when it is finishe > I thought a blank line to abort the process was more intuitive than > Ctrl-D (moreover I don't know if Ctrl -D is correctly handled under > Windows). On Windows that's Ctrl-Z if I remember correctly. But neither of those shortcuts is of any importance, no one will be ever writing names of the bases to merge using keyboard on the terminal/console (maybe except testing ;-)). The feature is to be used for shell scripts and for reading bases list from the file. In thise cases end-of-file works perfectly well as the signal of end of data.
> And in a script, there shouldn't be any blank lines : for example > "find . -name '*.si3' ..........." does not generate blank lines. Single find, does not. But if you try to merge a few finds and feed those to the command, then empty lines may happen. Also, empty lines may be useful if somebody prepares such bases list by hand, to separate groups. > So I don't see any use case where the process should continue after a > blank line. The case where it would be necessary to break is even more difficult to find. At the same time aborting on the blank line is likely to cause the problems. Some shells report an error if the consuming side of pipe ends before whole input is read. To summarize: this is of course corner case, in most situations no empty line will ever happen on input. But if it ever happens, continuing the work seems to be better solution (and suits the way most shell utils work....). ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Scid-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/scid-users
