Re: Opening files so that no cr/lf translation is done.

[Juergen Lock <nox@jelal.north.de>]

Michael Smith writes:

> This is a bit of an interesting one - certainly it's been giving me my
> fair share of migraine problems.

 sorry i didn't see this earlier... :)
> 
> I made a rash (in restrospect) announcement about the Taylor UUCP
> package a short while ago, let me qualify the state of things now :
> 
> uucico works fine, with the exception of the ability to detatch from
> the controlling terminal.

 ok the following is from my 1.03:  try setting HAVE_SETSID 1 in
conf.h (needs recent mintlib), and replace the fork/exit with a hack
with setjmp+tfork where the parent _exit()s and the child waits for
the parent to die and then longjmp back.

>  I assume this has something to do with the
> differences between "normal" fork() and the MiNT fork() - this is not
> a terrible problem, although it makes it (AFAIK) impossible for 
> uucico to receive SIGHUP from the modem,

 _that_ still would need a real tty driver, MiNTs own never even send
SIGHUP... :(  (and so i made it check the CD line itself on every read and
write...)

>  or to put uuxqt in the
> background.

 but this works.
> 
> uuxqt does not.
> 
> In particular, compressed newsbatches get mangled.
> 
> This had me stumped for some time - particularly because the 'od' in
> the shu194st.zoo archive on atari.archive has the same problem : so I 
> have two files, of different size, that 'od' to the same file.

 sounds like some [fp]open wants a "b", not necessarily in uuxqt...
or put try with a `b' in UNIXMODE and patch isspawn() to still pass
UNIXMODE if !fkeepenv. (assuming isspawn isn't changed from 1.03...)
> 
> Jens - if you're reading this, both thanks _and_ flames - can you fix
> it please? 
> 
> Now, I don't know how many of you have tangled with the innards of
> Taylor, but it's not hugely pretty - everything is abstracted to the 
> n'th degree, which probably makes it _great_ for porting, but learning
> it is no fun at all 8(
> 
> I have verified that the rnews I am using works (feeding it a compressed
> newsbatch results in it being neatly stashed where it should (ownership
> is wrong, ends up as uucp not news, despite sticky bit on /bin/rnews,
> but that's life 8( ) and I can verify that it is correct with 
> tail +2 <newsbatch> |zcat |less

 do you have a `b' in UNIXMODE?
> 
> However, if I use uuxqt to invoke rnews, things don't work out.

 if your rnews (which is that btw? :) depends on the b in UNIXMODE...

>...
> I'm not going to go further - there's too much to wade through, but in
> brief : this routine calls ixsspawn() which takes, amongst many
> other arguments, the filedescriptors in aidescs[0] and [1], which are
> used as stdin and stdout for the command.

 mintlib, unlike DOS :) has no `ascii mode' on fds, only on FILE *.
> 
> Somewhere along the line here, translation occurs... 
> I have looked at open.c in the pl44 mintlibs, but the nondiscussion
> of CRMOD has left me none the wiser.

 and CRMOD only exists on ttys, not on regular files.
> 
> If anyone has a suggestion, I'm open to ideas...

 would you like a look at my diffs for 1.03?  get tuu103d3.zoo from a.a
(older version), or mail me.  forget the 8+3 filename nonsense (we have
minixfs now) but most of the other patches should still be useful for 1.05...

 cheers
	Juergen
-- 
J"urgen Lock / nox@jelal.north.de / UUCP: ..!uunet!unido!uniol!jelal!nox
								...ohne Gewehr
PGP public key fingerprint =  8A 18 58 54 03 7B FC 12  1F 8B 63 C7 19 27 CF DA