Just a sample of the Echomail archive
Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.
|    MAKENL_NG    |    MakeNL Next Generation.    |    1,725 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 1,304 of 1,725    |
|    Benny Pedersen to Björn Felten    |
|    Errorlevels    |
|    26 Nov 14 23:08:52    |
      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)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca