From: pavenis AT lanet DOT lv To: "Juan Manuel Guerrero" , djgpp-workers AT delorie DOT com Date: Thu, 23 Nov 2000 12:03:14 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Subject: Re: New patch for dtou.c Message-ID: <3A1D0782.8231.5A370A@localhost> References: In-reply-to: <5A4F5D3251@HRZ1.hrz.tu-darmstadt.de> X-mailer: Pegasus Mail for Win32 (v3.12c) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-printable to 8bit by delorie.com id FAA06865 Reply-To: djgpp-workers AT delorie DOT com On 23 Nov 2000, at 9:34, Juan Manuel Guerrero wrote: I think that Eli's wishlist was only a draft to think about. > > > > 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. I think returning code for last file processed is rather useless if we are processing more than one file. Maybe it would be better to assign a bit for each type of change and return this bit when for processing at least one file this bit was set. Anyway I think its better to move such information to verbose output and always return 0 (as any conversion done is not really an error). Andris