On 05/08/12 18:57, Anton Shepelev wrote: > I wrote: > >> Is it reasonable to modify gpreconv or its Windows >> port so that on Windows it will expect '\r\n'?
As a software developer, writing code primarily for Windows, I feel obliged to chime in with an emphatic "no" here. > preconv(1) says: > > Trailing '-dos', '-unix', and '-mac' suffixes of > coding tags (which give the end-of-line conven- > tion used in the file) are stripped off before > the comparison with the above tags happens. > > Why not pay heed to these suffixes instead of strip- > ping them and always assuming '-unix', and assume > '-dos' on Windows? Why would you want it to do that? Why should preconv be expected to care whether its input data stream originated on *nix, mac or dos? preconv is written in C++, right? It processes an input stream which may be nominally classified as "text"; i.e. a stream of variable length records, comprising nominally printable character codes, (according to some specific encoding standard), and each terminated by a specific end of line indicator. Microsoft's own C/C++ API, for processing such data streams, converts \r\n to \n by default, before the application code, (preconv, in this case), ever sees it; thus, the behaviour described in the preconv(1) snippet above is completely consistent with the default behaviour [*] of Windows own text processing convention, as it is implemented for applications written in C or C++. [*] Actually, preconv opens its input stream in "binary" mode, rather than in Window's special "text" mode. Thus, it does see the \r\n EOL sequence, which it then explicitly interprets as the line terminator, so explicitly emulating the behaviour which would have been default, had it been opened in "text" mode. Why it does this, I don't know; perhaps the original implementer will chime in with an explanation. -- Regards, Keith
