J.Purchase@cs.ucl.ac.uk (Jan Purchase) (04/15/91)
Recently I installed A/UX 2.0.1 (fortunately, without incident) and although I am impressed with the system, I am surprised by the number of niggling bugs which it apparently did not correct. I installed the ftp'able upgrade, so it might be that the 'bugs' I'm about to cover are due to defficiences in this upgrade path, or indeed to my lack of knowledge! However, I'd be very grateful if anyone out there could give me work-arounds, fixes, say "Oh yeh, I get that too!", or correct the error of my ways concerning the following problems: a) Why, after I have used settimezone (as root) to set the system time zone to "GB-Eire", does the command "at" fail to work properly although "date" shows the correct time? Typically the argument of "at" is always interpreted as one hour sooner that it actually is, so that the command % at now + 5 minutes gives: at: too late whereas: % at now + 65 minutes works and schedules a job to execute in 5 minutes time. I realise that I could just tolerate this or use the timezones GMT and GMT+1 (switching manually in late March and October), but computers are supposed to make life easier. Other mac applications also seem to have timezone related problems, print submission is a prime example. Under GB-Eire, submitting a print job via PrintMonitor causes it to be queued 1 hour in the future! b) Why do mail headers express the send-time of a message in the system time zone in one part and in PDT in the other two? The mixing of time zones is very confusing. Why is sendmail annotating mail messages with PDT at all if the system TZ is ":GB-Eire"? c) Why can one not change the speed of a serial port which does not have a getty process associated with it (e.g., one connected to a outgoing only modem)? commands like: stty -n /dev/modem 1200 or: stty 1200 < /dev/modem which are quoted in SVR2 text books have no effect. A/UX just keeps the line speed at the default 9600 baud. d) Why does wall refuse to write to terminal devices it cannot read from? On executing "wall", as a normal user, one gets: Will not write to /dev/console, sid Will not write to /dev/ttyC1, sid and your message will not get to user sid. Surely permission to wall should be granted on write access not read access! e) Why do talk and write only function if the target terminal device is world writable? Surely permission should be granted according to an individuals access to the target device. Hence if the user using write is a member of group x and the terminal device is group writable by x then write should work, right? No. It returns: Permission denied. even if the user is root! talk behaves in a similar fashion returning: [Your party is not accepting messages] This is silly. It means that no-one, not even root, may talk or write to someone unless everybody can. Point (e) also prevents a wise superuser from setting up a group "tty" to which all terminal devices belong. This, in conjunction with setting write and talk sgid tty, means that users may inter-communicate with write and talk in the normal way (disabling it with mesg if required), but may not redirect text to each others terminals anonymously (a favourite trick amongst undergraduates) using ">". Will A/UX ever lose these "immaturities"? I realise that other versions of UNIX have bugs too, but I don't believe that they are this fundamental. Any help with these questions would be greatly appreciated. Cheers Jan.
ksand@Apple.COM (Kent Sandvik, 120dB or more) (04/16/91)
In article <1530@ucl-cs.uucp> J.Purchase@cs.ucl.ac.uk (Jan Purchase) writes: > >c) Why can one not change the speed of a serial port which does not >have a getty process associated with it (e.g., one connected >to a outgoing only modem)? commands like: > stty -n /dev/modem 1200 >or: > stty 1200 < /dev/modem >which are quoted in SVR2 text books have no effect. A/UX just keeps >the line speed at the default 9600 baud. I thought that this 'immaturity' was always present with SysV UNIX:es, i.e. the only way to program the speed/other attributes for a non-respawn port was to write a small program that opens the port, ioctls the new values, and keeps the port open until the doomsday of the running system. It's always a fun game trying to find out the default port values of the manifacturer's UNIX system. Sometimes they even document them. Regards, Kent -- Kent Sandvik, DTS junkie
jms@apple.com (John Michael Sovereign) (04/16/91)
In article <> J.Purchase@cs.ucl.ac.uk (Jan Purchase) writes: > a) Why, after I have used settimezone (as root) to set the system time > zone to "GB-Eire", does the command "at" fail to work properly.... I believe this is due to a bug in the GB-Eire data file; I have included a uuencoded version of this file which is a temporary fix. The only defect with this file is that it does not know that "summer time" was in effect throughout 1968-71. > b) Why do mail headers express the send-time of a message in the > system time zone in one part and in PDT in the other two? While the settimezone script states that you only need to logout and log back in, you really need to reboot to update sendmail and other daemons' TZ. > c) Why can one not change the speed of a serial port which does not > have a getty process associated with it.... Standard System V semantics require the characteristics of a terminal device be reset to their default values after the last close of the device. You can workaround this by using a command like the following where the sleep keeps the device open. ( stty 1200; sleep 100000) < /dev/tty1 & BTW, the flow control characteristics (modem, etc.) ARE preserved, since this is desirable and they are not defined by the SVID. > d) Why does wall refuse to write to terminal devices it cannot read > from? This "feature" was introduced in 2.0.1 to plug a security hole. I will investigate to see if this paranoia can be relaxed enough to allow non-privileged users to run wall. > e) Why do talk and write only function if the target terminal device > is world writable? This is the "security mechanism" used in these versions; the "tty group" mechanism you suggest is preferable, I hope that it will be adopted in a future release. Cheers, John Sovereign jms@apple.com #include <std/disclaimer.h> ------------------------------------------------------------------ begin 644 GB-Eire M P #P P R: MUC00F]7W$)S/(I"=I+60GIR/D)^7#)"@A:P0H7;ND*)ECA"C>[J0I$ZJD*4_ M[1"F)5(0IR>X$*@J'A"I$W>0JA<O$*K5!Q"KZ>(0K,=>$*W)Q!"NIT 0KZFF M$+"'(A"QB8@0LG ^D+-RI)"T4""0M5*&D+8P I"W,FB0N _DD+D22I"Y[\:0 MNO(LD+O/J)"\T@Z0O;C%$+Z[*Q"_F*<0P)L-$,%XB1#">N\0PUAK$,1:T1#% M.$T0QCJS$,=8R)#'V?N0RA8FD,J769#+T1Z0S'<[D,VQ )#.8%@0SY#BD-!N M7I#1<A80T?LR$-)I\!#38QN0U$G2$-4>$Y#50OV0U=_@$-9.GA#6_?60V"Z M$-CYAQ#:#F(0VNO>$-OE"9#<R\ 0W<3KD-ZTW)#?K@@0X)2^D.%R.I#B:V80 MXU(<D.14@I#E,?Z0YC1DD.<;&Q#H%$:0Z/K]$.G]8Q#JVM\0Z]U%$.RZP1#M ML^R0[IJC$.^!69#PGV\0\6$[D/)_41#S2E@0]%\S$/4@_Y#V/Q40]P#AD/@> M]Q#XX,.0^?[9$/K I9#[Y_60_'N=D -PN! $*4H0!5":$ 8)+! ','P0!^D. M$ D07A )R/ 0"O! $ NR#) ,T"(0#9'ND ZP!! /<="0$)D@D!%1LI 2>0*0 M$S&4D!18Y) 5(^N0%CC&D!<#S9 8&*B0&..OD!GXBI :PY&0&^&G$!RLKA = MP8D0'HR0$!^A:Q @;'(0(8%-$"),5! C82\0)"PV$"5*2Y F#!@0)RHMD"?U M-) I"@^0*=46D"KI\9 KM/B0+,G3D"V4VI NJ;60+W2\D#"2TA Q7=D0,G*T M$#,]NQ T4I80-1V=$#8R>! V_7\0.!):$#C=81 Y^W:0.KU#$#O;6) \IE^0 M/;LZD#Z&09 _FQR00&8CD$%Z_I!"1@600UK@D$0EYY!%0_T01@7)D$<CWQ!' M[N8020/!$$G.R!!*XZ,02ZZJ$$S#A1!-CHP03J-G$$]N;A!0C(.045>*D%)L M99!3-VR05$Q'D%473I!6+"F05O<PD%@,"Y!8UQ*06?4H$%JV])!;U0H07* 1 M$%VT[!!>?_,07Y3.$&!?U1!A=+ 08C^W$&-4DA!D'YD093VND&8(M9!G'9"0 M9^B7D&C]<I!IR'F0:MU4D&NH6Y!LO3:0;8@]D&ZF4Q!O:!^0<(8U$'%1/!!R M9A<0<S$>$'1%^1!U$0 0=B7;$';PXA!X!;T0>-#$$'GNV9!ZL*80>\Z[D'R9 MPI!]KIV0?GFDD'^.?Y 0 ! $ 0 ! $ 0 ! $ 0 ! $ 0 ! $ M 0 ! $ 0 ! $ 0 ! $ @ " ( @ " $ 0 " $ 0 ! $ 0 ! M $ 0 ! $ 0 ! $ 0 ! $ 0 ! $ 0 ! $ 0 ! $ 0 ! $ M 0 ! $ 0 ! $ 0 ! $ 0 ! $ 0 ! $ 0 ! $ 0 ! $ 0 ! M $ 0 ! $ 0 ! $ 0 ! $ 0 ! $ 0 ! $ 0 ! $ 0 ! $ M 0 ! $ 0 ! $ 0 ! $ 0 ! $ 0 ! $ X0 0 0 !P@ 1 0A"4U0 1TU4 $135 ! 0$ end
paul@taniwha.UUCP (Paul Campbell) (04/17/91)
In article <1530@ucl-cs.uucp> J.Purchase@cs.ucl.ac.uk (Jan Purchase) writes: >c) Why can one not change the speed of a serial port which does not >have a getty process associated with it (e.g., one connected >to a outgoing only modem)? commands like: > stty -n /dev/modem 1200 >or: > stty 1200 < /dev/modem >which are quoted in SVR2 text books have no effect. A/UX just keeps >the line speed at the default 9600 baud. Whenever you close a serial port (ie all processes that have it open close it) it resets the port's state (including baud rate and all the settings - with the exclusion of the apple defined ones like -modem). This is standard SVR2 (despite what the books might say). Every Unix I've ever used did the same thing ... Paul -- Paul Campbell UUCP: ..!mtxinu!taniwha!paul AppleLink: CAMPBELL.P "But don't we all deserve. More than a kinder and gentler fuck" - Two Nice Girls, "For the Inauguration"