clewis@mnetor.UUCP (Chris Lewis) (05/29/86)
I just installed and tied together uuhosts/uumail/pathalias, and thought I'd throw my two cents worth in In article <220@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes: >In article <185@comp.lancs.ac.uk> stephen@comp.lancs.ac.uk >(Stephen J. Muir) writes: > >> Then you're running an outdated pathalias. The latest version is given the >> list of map files (so it knows which file each site was in). This way, it >> can differentiate between multiple hosts with the same name. > >What a kludge! I suspect there are a lot of sites out there that, for >one reason or another, are forced to feed the maps to pathalias on standard >input. For example, I don't have enough free space to change my current > > zcat u.*.Z | pathalias How does this work now that: a) some of the u.* file names are 13 or 14 chars long and compress refuses to compress them? b) 4.0 "zcat" refuses to handle uncompressed files (so zcat u.* won't work either given (a)) (we're running 4.0 compress, 1.69 uuhosts and 3.0 uumail all compiled in the Berkeley universe on our Pyramid - they are the latest aren't they? They are all the latest ones I've seen on mod.sources) I went to all of the trouble of converting uuhosts and my pathalias script to do something like: for i in u.* do f=`basename $i .Z` if [ -r $f ] then cat $f else zcat $f fi done | ... But, then I saw quite a few errors coming out from pathalias and I wanted to find out precisely where they were. [somebody oughta fix u.usa.ca.1 and 2 - there are quite a few syntax errors plus lots of alias redeclarations, and for some reason "#NOTE: 0)" got parsed by pathalias as a site called "0)"! Does anybody know what these mean? Did anybody else get them?: /usr/local/lib/pathalias: internal error on private host cs-pacx /usr/local/lib/pathalias: internal error on private host cs-ether The "0)" site and internal errors may very well be a porting problem. Aren't the map files run thru pathalias before posting?] Fortunately we have enough space to create a directory and uncompress: >into > > uncompress u.*.Z; pathalias u.*; compress -f u.* we use: MAPS=/usr/spool/maps cp u.* $MAPS/tmp; cd $MAPS/tmp; pathalias u.*...; rm -f u.* Other things: 1) uumail's "address.c" has a VAXism - "int uswitch" in the main function should be initialized to 0 (eg: "int uswitch = 0;" - VAX's tend to initialize locals as zero. On a Pyramid it's garbage ("address" would call opath correctly about 25% of the time and oupath the rest with the same input) [We're running "class 3" by the way] 2) uumail's uuconf.h has: #define NAMESIZ 32 /* system name size */ #define NEIGHBORS BUFSIZ/NAMESIZ NEIGHBORS is used in the getpath.c declaration: char neighbors[NEIGHBORS][NAMESIZ]; This is used to contain the names of the adjacent sites (sites mentioned in L.sys). Well, we have 71 L.sys entries and BUFSIZ/NAMESIZ is 64. Nor is there a check in getpath.c for overflow... BOOM! I changed the NEIGHBORS define to: #define NEIGHBORS BUFSIZ*2/NAMESIZ And added a check for overflow. 3) Somebody oughta reparagraph uumail 3.0 (ugh!). 4) I had to heavily modify uuhosts to work with the new naming conventions with COMPRESS turned on (see above) After fixing these it appears to work reasonably well. Is there going to be a new uuhosts distribution for the new naming convention? -- Chris Lewis, {pyramid|watmath|utcsri|decvax|allegra|linus|ihnp4}!utzoo! {utcsri|cbosgd}!utcs! {yetti|lsuc|genat|mot|oakhill}! ... mnetor!clewis BELL: (416)-475-8980 ext. 321
geoff@desint.UUCP (Geoff Kuenning) (06/01/86)
In article <3449@mnetor.UUCP> clewis@mnetor.UUCP (Chris Lewis) writes: > > zcat u.*.Z | pathalias > > How does this work now that: > > a) some of the u.* file names are 13 or 14 chars long and compress > refuses to compress them? > b) 4.0 "zcat" refuses to handle uncompressed files (so zcat u.* won't > work either given (a)) To answer these questions, let me summarize some mail conversations I've been having with Mark and Peter: (1) Mark hadn't thought about the 14-character problem vis-a-vis compress. He apparently intends to cure it, apparently by replacing "att" with "a" and "bcr" with "b" in path file names. This is not too hard to do by hand, which is how I solved the problem. (2) It is true that pathalias has knowledge of file boundaries: the "private" keyword takes effect from where it appears to the end of that input file. I have suggested to Peter that a keyword be added that means "eof"; this can be appended to each input file before cat'ing them all together. I don't know what Peter thinks of this idea, however. -- Geoff Kuenning {hplabs,ihnp4}!trwrb!desint!geoff
clewis@mnetor.UUCP (06/03/86)
In article <3449@mnetor.UUCP> clewis@mnetor.UUCP (me) wrote: >I just installed and tied together uuhosts/uumail/pathalias [again], and >thought I'd throw my two cents worth in >But, then I saw quite a few errors coming out from pathalias and I wanted >to find out precisely where they were. > >[somebody oughta fix u.usa.ca.1 and 2 - there are quite a few syntax errors >plus lots of alias redeclarations, and for some reason "#NOTE: 0)" got >parsed by pathalias as a site called "0)"! >Does anybody know what these mean? Did anybody else get them?: > >/usr/local/lib/pathalias: internal error on private host cs-pacx >/usr/local/lib/pathalias: internal error on private host cs-ether Argh. Multitudinous apologies. I was running an old version of pathalias. I had the new one, but I had it unpacked somewhere else.... There isn't any errors now. Thanks Peter for making me think I had the wrong one. Sorry about that. -- Chris Lewis, {pyramid|watmath|utcsri|decvax|allegra|linus|ihnp4}!utzoo! {utcsri|cbosgd}!utcs! {yetti|lsuc|genat|mot|oakhill}! ... mnetor!clewis BELL: (416)-475-8980 ext. 321
clewis@mnetor.UUCP (06/04/86)
In article <222@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes: >In article <3449@mnetor.UUCP> clewis@mnetor.UUCP (Chris Lewis) writes: > >> > zcat u.*.Z | pathalias >> >> How does this work now that: >(1) Mark hadn't thought about the 14-character problem vis-a-vis compress. >He apparently intends to cure it, apparently by replacing "att" with "a" >and "bcr" with "b" in path file names. This is not too hard to do by hand, >which is how I solved the problem. Great. >(2) It is true that pathalias has knowledge of file boundaries: the "private" >keyword takes effect from where it appears to the end of that input file. I >have suggested to Peter that a keyword be added that means "eof"; this can >be appended to each input file before cat'ing them all together. I don't >know what Peter thinks of this idea, however. "eof" would help. However, how about placing a directive somewhat like: the cpp's "#line" directive in each input file, so that if you cat the files together, pathalias can tell you which file and which line. Eg: #line "u.att.ca.bcr.1" 1 Then pathalias can use it to track the line numbers back to the original files. Then "eof" would be at every "#line" directive and at the end of the whole thing. -- Chris Lewis, {pyramid|watmath|utcsri|decvax|allegra|linus|ihnp4}!utzoo! {utcsri|cbosgd}!utcs! {yetti|lsuc|genat|mot|oakhill}! ... mnetor!clewis BELL: (416)-475-8980 ext. 321
honey@down.FUN (Peter Honeyman) (06/06/86)
chris lewis suggests a pathalias directive of the form # line 1 "u.usa..nj.1" for delimiting concatenated input. this is reasonable; it will be in the next release. peter ps: integrating this with a zcat|pathalias scheme is someone else's problem.