Mail Archives: djgpp-workers/2000/11/23/03:46:02
Date: Thu, 23 Nov 2000 09:26:25 +0200 (WET)
From: Andris Pavenis <pavenis AT lanet DOT lv>
> > -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
OK, I will add this text to util.tex.
> > -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 ...
I agree. Netherless, please note that I have tried to follow Eli Zaretskii's wishlist.
Preserving timestamp will be a contradiction to that item in the wishlist.
I will wait until some concensos has been reached and then change the
sources accordingly. Once again, I prever the version with the preserving timestamp
as default.
> > -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.
OK. I will do this. I will add backup and two levels of verbosity.
> > 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.
Sorry, but I do not unterstand this at all. The numbers in the table are the return code
of main() to the calling environment. **No** text at all will ever be outputed.
The text in the table is only for the djgpp-workers' information and will never be send to
stdin nor stderr. The above table is the same table that I have added to the util.tex file
for user's information. Only the numbers (return codes/exit status) are of importance
and will be seen by the calling context (bash in your example).
The return code of main() is always the return code generated by the last processed file
as usual.
Regards,
Guerrero, Juan Manuel
- Raw text -