Hello Bob!

Fri 2003-08-15 19:46, Bob Jones (1:343/41) wrote to Bo Simonsen:

 BJ>> But we could test it when running max in local console mode! 
 BJ>> ("bin/max -k"). 

 BS>> Yes, it works, because i packed the files manually.

 BJ> Ok.  Good.

Not good for dialing users :-)

 BS>>> * Maximus has problems about calling the archiver, it 
 BS>>> quits because zip returns "Nothing to pack".. And the 
 BS>>> string i correctly whitch is executed.

 BJ>> Interesting.  Take a look at (a) path definitions, (b) what's
 BJ>> different between how squish uses the compress.cfg filel and how
 BJ>> max uses the compress.cfg file. 

 BS>> I took at look in the language definitions files, there 
 BS>> was maxpipe defined on UNIX, and i did undefined, so 
 BS>> now it runs '/usr/bin/zip -j -q > path/downlink.qwk> /*.*' and it's quite 
 BS>> wierd because Squish is doing just greate with my Compress definitions.

 BJ> Ah...  That actually makes sense.  Squish doesn't uses maxpipe, so
 BJ> it wasn't impacted.  And I think maxpipe is one of the options we
 BJ> want to exploit in the future, but requires some work....

I did removed the maxpipe thing, but anyway it doesn't work.

 BS>>> * Filetransfer doesn't work properly over TELNET.

 BJ>> In what way?  [I haven't tested this....]

 BS>> It just doesn't work :( Ztelnet works with all BBS 
 BS>> Systems, and it doesn't work :(

 BJ> Ok.  Then we are probably not 8-bit clean on the max telnet side. 
 BJ> That doesn't suprise me....  :(

My feeling too!

 BS>> My suggestion is that we use sz/rz (lrzsz) for zmodem 
 BS>> transfer on UNIX platforms.. 

 BJ> Won't help until we get the tcp/ip connection 8-bit clean....  :(  

Agreed

 BJ> On the other hand sz/rz might just have code in it to reset the
 BJ> pipe to become 8 bit clean, in which case we could look at that
 BJ> code and fix Max....  Hmmmm.... 

Don't think so, i don't see a reason for not making the telnet server 8 bit..

Regards,
         Bo

--- timEd/Linux 1.11.b1