Hello Bj÷rn!

08 May 18 02:54, you wrote to me:

 BF>    I beg to differ. The proper way to use MakeNl (and I was the one person
 BF> that instigated the reverse engineering of MakeNl a decade ago, so I think
 BF> I know) is to *NOT* use the outfile name as in:

 I know what you did in the past with makenl and I appreciate that very much.
 But, you and Ward are using features, that do not exist in the unix version.
 Janis as well I run manknl on a unix system.

 BF> outfile Region20   ;Filename (not used as password) given by ZC
 BF>    ...but as in:
 BF> outfile password.UPD   ;Filename (also used as password) given by RC

 a file is file name. Most region updates are distributed as filename.XXX where
 XXX is the daynumber for the coming friday. But that does not matter, it
 will be put in the master directory with the daynumber of the the
 publishing day.

 In windows as well a in Unix, you can use filename.upd or whatever. What
 makenl will do with when it is moved to the master directory, is as above,
 dat the daynumber of the publishing day. So you get a file with the name:
 filename.upd.128 if today was the publishing day.

 What happens in windows/dos, is the OS cannot handle two dots in a filename
 and the OS concatenates the name at the second dot.
 On a unix system multiple dots in a filename are permissible.

 So on a unix system the update files will alway have a daynumber suffix.
 That is what triggers the the only finding files in a MOD 7 way.

 You can blame unix for not giving the results you expect, it is a limit
 in your OS that saves your hide. If it should work as you say, then there
 is a definit bug in the makenl code.

 BF>    In the later case there should never be a day number problem.

 Well I did, and using a * in the CTL file as some do, also creates havoc
 on systems that do not limit how the filename is structured.

 Your turn Sir.

Kees

--- GoldED+/LNX 1.1.5
 * Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)