[comp.unix.ultrix] Ultrix 4.1

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.