grunwald@foobar.colorado.edu (Dirk Grunwald) (10/06/90)
I saw mention that ultrix 4.1 is shipping with 3D machines now and will be shipping for other platforms ``soon''. Does ultrix 4.1 include all the patches and fixes that people say you need to e.g., make `cc' work under ultrix 4.0? I have not upgraded to 4.0 yet, and am wondering if I should bother of if I should just wait for 4.1.
avolio@decuac.dec.com (Frederick M. Avolio) (10/07/90)
To get cc to work??? Works for me, but you must be talking about a particular problem. In any event, when 4.1 comes out it will contain bug fixes, 3D support, etc. but I would recommend updating to 4.0 now. 4.0 is a full reinstall. 4.1 is an update release. 4.1 will just layer on top of 4.0. Fred
avolio@decuac.dec.com (Frederick M. Avolio) (10/08/90)
I am sorry. Forget what I wrote. I have been informed by someone smarter and bigger than me (inside joke :-) ) that 4.1 is also a full upgrade. I guess I'd wait... Fred
grunwald@foobar.colorado.edu (Dirk Grunwald) (10/08/90)
someone else locally install 4.0 and had trouble recompiling many applications. I tried to compile some things that work on many other hosts and under 3.2, but not under 4.0 (at least with optimizations enabled). A couple of weeks ago, there was a flurry of similar complaints. People we told to get the compiler patch kit from their DECdude. Those were the problems I was trying to avoid - sorry to not have been more precise.
meissner@osf.org (Michael Meissner) (11/21/90)
--text follows this line-- In article <m0iYsVi-000KGMC@srchtec.uucp> mra%srchtec.uucp@MATHCS.EMORY.EDU (Michael Almond) writes: | I'm installing libg++ version 1.37.0 on a DECstation 2100 running | Ultrix 4.1. In malloc.c fputs and fprintf use const in their declarations. | In /usr/include/stdio.h they don't have these and the compiler complains about | incompatiable type delcarations. I commented out the ones in malloc.c and let | the one's in stdio.h do the work. The code compiled after I made this change. Sigh, I would have hoped that DEC would have fixed these bogus header files in Ultrix 4.1. What's happening is DEC within a __STDC__ ifdef, supplied prototypes that do not match ANSI. In particular, the 'const' keyword was removed. I speculate that this is because the MIPS compiler shipped with 2.0, does not fully support ANSI, but since it's within a __STDC__ section, and their compiler does not define __STDC__, I have to wonder why....... -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Considering the flames and intolerance, shouldn't USENET be spelled ABUSENET?
D. Allen [CGL]" <idallen@watcgl.waterloo.edu> (02/20/91)
/usr/etc/subsets/UDTBIN410.inv has this entry: 0 19 00000 0 0 120777 8/28/90 410 s ./usr/sys/machine/mips/io/tc ../../../io/tc/mips UDTBIN410 This is wrong and creates a symlink that points nowhere. It should be: /usr/sys/machine/mips/io/tc -> ../../../io/tc as should most of the symlinks in that directory. Or perhaps all the /usr/sys/io/* directories are missing their "mips" subdirectories. The scsi one has a mips subdirectory, and is thus correct. In fact, the Ultrix 4.1 (RISC) /usr/include/ stuff for the system is full of dangling symlinks that point nowhere, e.g. /usr/include/machine: Unsatisfied Symbolic Links: dist h sas sys /usr/include/machine/fs: Unsatisfied Symbolic Links: gfs nfs specfs ufs /usr/include/machine/io: Unsatisfied Symbolic Links: bi ci gvp mba msi netif scs sysap tc uba vme xmi /usr/include/machine/net: Unsatisfied Symbolic Links: ccitt dli lat net netbsc netdnet netimp netinet rpc rpcsvc We are a DS5400 running ULTRIX V4.1 (Rev. 52) -- -IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu [129.97.128.64] Computer Graphics Lab/University of Waterloo/Ontario/Canada
D. Allen [CGL]" <idallen@watcgl.waterloo.edu> (04/15/91)
The Ultrix 4.1 who (and all previous versions) suffers from the following ancient BSD bugs. Ultrix who bug #1: The first one will hit you if you run programs that use ptys without making utmp entries, as in "script" or "screen" or "xterm": Sample output: Script started on Sun Apr 14 14:54:35 1991 % /bin/who am i watcgl! ttype Apr 12 18:00 <- nonsense Script started on Sun Apr 14 14:55:23 1991 % /bin/who am i % <- no output! The first nonsense output comes from who finding a utmp entry that matches your tty, left over from a previous user of the tty. (When someone logs out, the utmp userid field is zeroed, but not the tty field.) Who blindly prints the userid field without checking it, and since you have no userid entered in the utmp when you run script, who blindly prints a null string. We fixed that in our BSD source in 1986. Ultrix who bug #2: If you understand the above, then you'll realize that since Ultrix "who am i" only searches for a match on the tty field, without regard for a non-null userid field, the output can be wrong because of old entries in the utmp file. The entries in the utmp file are made in one-to-one correspondence with the ttys in the /etc/ttys file, so if you run your system with a particular set of ttys you get a utmp file that has entries for a lot of the ttys (the userid fields being zeroed out when people log out). If you then add or delete ttys in /etc/ttys, the correspondence between ttys and utmp shifts and "who am i" prints the wrong thing again. We fixed that in 1988: * Revision 1.3 88/06/18 14:50:00 idallen * No longer prints wrong utmp entry for "who am i". * Used to find the first entry that matched the tty name, even if the * userid was null; but, null-name entries can get created by changes * in the /etc/ttys file causing a tty's ttyslot() number to shift. * Must have a non-null name to get a match. [...] /* "who am i" mode: * Have to have a non-null name on the line. * As /etc/ttys changes, we can end up with * duplicate ut_line entries for ttys (since * the ttyslot() number of a tty may change). * We must ignore all entries with null names. * -IAN! */ Ultrix (and BSD) who inconsistency: Look! No host name in the first example: % rsh localhost /bin/who am i idallen tty?? Apr 14 15:27 <- why no host name? % /bin/who am i watcgl!idallen tty01 Apr 14 15:28 -- -IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu [129.97.128.64] Computer Graphics Lab/University of Waterloo/Ontario/Canada
D. Allen [CGL]" <idallen@watcgl.waterloo.edu> (04/15/91)
We all know that Unix treats the null pathname as equivalent to the current directory. Try for example: ls "" Well, don't pass the null pathname to an Ultrix find command -- look what you get: % cd /usr/tmp && find "" -print /VIc34646cef /VIc34k4ofpu /RIc34k4ofpu /msg.idallen [...etc...] Look! Absolute pathnames transplanted onto the root file system! More interesting, sadly, is this example, perhaps run via the cron: cd /usr/tmp && find "" -exec rm -f {} \; Run this as root and trash anything under "/" that has the same name as something under /usr/tmp/. Not nice. Most other "find" commands we've tried have this fault, too. We have source; we fixed ours. -- -IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu [129.97.128.64] Computer Graphics Lab/University of Waterloo/Ontario/Canada
de5@ornl.gov (Dave Sill) (04/15/91)
In article <1991Apr14.195247.15341@watcgl.waterloo.edu>, idallen@watcgl.waterloo.edu (Ian! D. Allen [CGL]) writes: >We all know that Unix treats the null pathname as equivalent to the >current directory. Try for example: ls "" Says who? I've never heard that one before. Dot (".") is the universally accepted handle for the current directory. -- Dave Sill (de5@ornl.gov) It will be a great day when our schools have Martin Marietta Energy Systems all the money they need and the Air Force Workstation Support has to hold a bake sale to buy a new bomber.