Mail Archives: djgpp-workers/2000/11/23/03:25:35
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 <pavenis AT lanet DOT lv>
> > 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 <eliz AT is DOT elta DOT co DOT il>
> > 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
- Raw text -