Date: Thu, 23 Nov 2000 09:26:25 +0200 (WET) From: Andris Pavenis To: Juan Manuel Guerrero cc: djgpp-workers AT delorie DOT com Subject: Re: New patch for dtou.c In-Reply-To: <58DAE532FD@HRZ1.hrz.tu-darmstadt.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=windows-1257 X-MIME-Autoconverted: from 8bit to quoted-printable by ieva01.lanet.lv id JAA23138 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id DAA23508 Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk I didn't really test the patch yet so only some comments ... On Thu, 23 Nov 2000, Juan Manuel Guerrero wrote: > Date: Wed, 8 Nov 2000 09:43:15 +0200 (WET) > From: Andris Pavenis > > One additional suggestion: There are small DOS utility in Simtelnet > > (simtelnet/msdos/fileutils/nocrlf10.zip) which permits to repair > > binary files which are errorously transfered as text (it was DOS only so > > no LFN support, of course). Now only change we need for that in dtou is to > > skip Ctrl-Z processing. My suggestion is to do that if executable name is > > nocrlf only. So one can do: > > > Date: Wed, 8 Nov 2000 13:27:53 +0200 (IST) > From: Eli Zaretskii > > And, if we are talking about adding features to DTOU, here's a small > > wishlist: > > > > - add verbose operation option, whereby the program will print whether > > it removed any CR's and ^Z's, and whether some lines had LF without a > > CR (a sure sign the file is either binary or has inconsistent EOL > > format for some other reason). > > > > - add an option which will remove any number of CRs before an LF, as in > > "\r\r\r\r\r\n" (this happens with buggy ports of Unix software, such > > as the Windows CVS client, which always blindly add a CR to LF, even > > if there's already a CR there). > > > > - return an exit status which says whether any changes were done to the > > file. > > > > - add an option which causes the file time stamps to be preserved only > > if the file was left unchanged. > > > > - explain more about how these two programs work in utils.tex. > > > I have added 5 command-line options to dtou: > -h: Displays a help text and exits. > > -r: Repair mode. This mode transforms MSDOS-style EOL (CRLF) into > UNIX-style EOL (LF). It ignores Cntl-Z thus it will not truncate the file. > CR sequences in front of LFs are left unchanged. A CR sequence is a sequence > except for the last CR of the sequence. This last CR together with the LF > forms the MSDOS-style EOL (CRLF). This implies that if there are n CRs followed > by a LF, the sequence is only n-1 CRs long, of course. This mode is intended > for repairing files that have erroneously been transmited in text-mode > instead of binary-mode during a FTP session. Also with Windows version of Netscape which has bad habit to transfer files with such extensions as .gz, .bz2, .tgz as text ones I think it's OK > > -s: Strip mode. It transforms MSDOS-style EOL (CRLF) into UNIX-style EOL (LF) > and strips a CR sequence of arbitrary length from a file, if the sequence > is followed by a LF. CR sequences that are not followed by a LF are left > unchanged. > > -t: Timestamp. With this option the timestamp of a file (modified or not) > will be preserved. I think preserving timestamp should be default. But user may want to turn it off ... > > -v: Verbose mode. This mode outputs some information during file processing. > All possible output looks like: > > File: foo.c > File unchanged. > At least one CRLF to LF transformation. > Warning: At least one CR sequence striped from a LF. > Warning: At least one Cntl-Z. File truncated at line n. > Warning: At least one LF without a preceeding CR. > I think we should have more than one level of verbosity: -v - output file names being processed only -vv or -v -v - outputs also additional info mentioned above I suggest to add also option -b to keep backup file. > The program is backward compatible with previous program versions if no options > are given at all. In this case, an occurrence of Cntl-Z will truncate the file, > MSDOS-style EOL (CRLF) are transformed into UNIX-style EOL (LF) and CR sequence > stripping will not happen at all. Also the timestamp will not be alterated. > > > The table below summarizes the exit status: > 0: File is unchanged. > 1: At least one CRLF to LF convertion has occurred in the processed file. > 2: At least one CR sequence has been removed from a LF in the processed file. > 3: At least one CR sequence has been removed from a LF and one CRLF to CR > conversion has occurred in the processed file. > 4: Cntl-Z (software EOF) has occurred, thus the processed file has been truncated. > 5: Cntl-Z has occurred, thus the processed file has been truncated and at least > one CRLF to LF convertion has occurred. > 6: Cntl-Z has occurred, thus the processed file has been truncated and at least > one CR sequence has been removed from a LF in the processed file. > 7: At least one LF has ocurred without a preceeding CR in the processed file. > 8: At least one LF has ocurred without a preceeding CR and at least one > CRLF to LF convertion has occurred in the processed file. > 9: At least one LF has ocurred without a preceeding CR and at least one > CR sequence has been removed from a LF in the processed file. > 10: At least one LF has ocurred without a preceeding CR, one CR sequence > has been removed from a LF and one CRLF to LF conversion has occurred > in the processed file. > 11: At least one LF has ocurred without a preceeding CR and at least one > Cntl-Z has occurred. The processed file has been truncated. > 12: At least one LF has ocurred without a preceeding CR, one CRLF to LF > convertion and one Cntl-Z has occurred in the processed file. > The file has been truncated. > 13: At least one LF has ocurred without a preceeding CR, one CR sequence > has been removed and one Cntl-Z has occurred in the processed file. > The file has been truncated. > 14: At least one LF has ocurred without a preceeding CR, one CR sequence > has been removed, CRLF to LF convertion and one Cntl-Z has occurred > in the processed file. The file has been truncated. > 16: Some I/O error occurred. > It's OK if we are processing only one file. But one could write something like dtou `find foo -name '*.cc' -or -name '*.h'` under bash. How to interpret return values in this case (if we have many files processed). I think only reasonable way is to provide this info when verbose output is required. > I have tested it on DOS. No linux/unix testing at all but I have only used posix functions > so there should appear no diffuculties when compiling and running dtou under unix. > > Comments, objections, suggestions, etc. are welcome. > Andris