Hello Björn!

25 Nov 2014 05:27, Björn Felten wrote to All:

 BF> I've always found it hard to understand the underlying thought behind 
 BF> the original error levels from the old MakeNl. And it seems like we 
 BF> are trying to maintain those even in our new version.

if we change them scripts would fail

 BF> Alas, let's try not to break any batch files from 20 years ago, but 
 BF> really?

+1

 BF>      0  = Process mode - no errors encountered
 BF>      1  = Process mode - no fatal errors encountered
 BF>      2  = Process mode - one or more fatal errors encountered
 BF>      3  = Test mode - no errors encountered
 BF>      4  = Test mode - no fatal errors encountered
 BF>      5  = Test mode - one or more fatal errors encountered
 BF>    254  = MakeNL aborted - I/O error
 BF>    255  = MakeNL aborted - Control file error

feel free to not use return codes :)

echo "war" && echo "done"

 BF> Why the separate, otherwise identical, levels for process mode and 
 BF> for test mode?

its not same test

 BF> Anyway, we can leave that be -- even if I doubt that there are that 
 BF> many systems out there that actually uses those error levels -- but 
 BF> one level I would like is for "Unchanged output file will NOT be 
 BF> submitted".

bad for daily updates

 BF> When eventually the output file is changed, I want to know, so I 
 BF> can delete the old one (that at least for us in zone 2 has a different 
 BF> file extension on a regional level) and hatch out the new one.

check for not zerro return codes there would be error, so dont delete source,
but if zerro return its updated, what ever dont know if bash on windows
changes that


 Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/3.17.3-gentoo (i686))
 * Origin: duggi.junc.org where qico is waiting (2:230/0)