ok, you convinced me ;-) Pascal
Marcin Kasperski a écrit : >>> 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 > > > ------------------------------------------------------------------------- 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
