[comp.sys.apollo] perl difficulties on Apollo

mheffron@orion.oac.uci.edu (Matt Heffron) (10/24/90)

I've just installed perl V3.0 pl 37 on an Apollo DN3500 running Domain/OS (10.2)
and two tests fail, both with file mode related errors. Does anyone have any
advice/opinions/... ?

The first seems to be an assumption in the io.fs test:
  # $Header: io.fs,v 3.0.1.1 90/08/13 22:31:17 lwall Locked $
  
  print "1..22\n";
  
  $wd = `pwd`;
  chop($wd);
  
  `rm -f tmp 2>/dev/null; mkdir tmp 2>/dev/null`;
  chdir './tmp';
  `/bin/rm -rf a b c x`;
  
  umask(022);
  
  if (umask(0) == 022) {print "ok 1\n";} else {print "not ok 1\n";}
  open(fh,'>x') || die "Can't create x";
  close(fh);
  open(fh,'>a') || die "Can't create a";
# ^^^^^^^^^^^^^ What here specifies that the file should have mode 0666 ??
#               It seems to be a somewhat erroneous assumption in the test.
#               (perl's 'open' uses the 'fopen' routine with mode "w", why
#                MUST the "real" mode on the file therefor be 0666 ??)
#               (On Apollo Domain/OS the default file creation ACL
#               for the directory (tmp) is used for the file.)
  close(fh);
  
  if (link('a','b')) {print "ok 2\n";} else {print "not ok 2\n";}
  
  if (link('b','c')) {print "ok 3\n";} else {print "not ok 3\n";}
  
  ($dev,$ino,$mode,$nlink,$uid,$gid,$rdev,$size,$atime,$mtime,$ctime,
      $blksize,$blocks) = stat('c');
  
  if ($nlink == 3) {print "ok 4\n";} else {print "not ok 4\n";}
  if (($mode & 0777) == 0666) {print "ok 5\n";} else {print "not ok 5\n";}
#     ^^^^^^^^^^^^^^^^^^^^^^  The failed assumption above appears here.

(By the way, it is NOT stat failing.  If I change the ACL to disallow execute
 for owner, group, and world; then the test passes.)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The second seems to be a real bug in Domain/OS itself,
manifesting itself in the op.dbm test:

  # $Header: op.dbm,v 3.0.1.1 90/03/27 16:25:57 lwall Locked $
  
  if (!-r '/usr/include/dbm.h' && !-r '/usr/include/ndbm.h') {
      print "1..0\n";
      exit;
  }
  
  print "1..10\n";
  
  unlink 'Op.dbmx.dir', 'Op.dbmx.pag';
  umask(0);
  print (dbmopen(h,'Op.dbmx',0640) ? "ok 1\n" : "not ok 1\n");
#        ^^^^^^^^^^^^^^^^^^^^^^^^  the file is created with the default file
#                                  creation ACL for the directory, not the
#                                  specified mode 0640
  ($dev,$ino,$mode,$nlink,$uid,$gid,$rdev,$size,$atime,$mtime,$ctime,
     $blksize,$blocks) = stat('Op.dbmx.pag');
  print (($mode & 0777) == 0640 ? "ok 2\n" : "not ok 2\n");
#        ^^^^^^^^^^^^^^^^^^^^^^  Here's where it becomes apparent

-Matt Heffron           mheffron@orion.oac.uci.edu (now)
                        heffron@falstaff.css.beckman.com (soon!!)

tkacik@rphroy.uucp (Tom Tkacik) (10/24/90)

In article <2724E240.153@orion.oac.uci.edu>, mheffron@orion.oac.uci.edu (Matt Heffron) writes:
|> I've just installed perl V3.0 pl 37 on an Apollo DN3500 running Domain/OS (10.2)
|> and two tests fail, both with file mode related errors. Does anyone have any
|> advice/opinions/... ?

|> The first seems to be an assumption in the io.fs test:

|> The second seems to be a real bug in Domain/OS itself,
|> manifesting itself in the op.dbm test:

Compiling perl on an Apollo DN4000 running Domain/OS (10.1), I also found
these two problems.  But I also had a third.

The test op.stat fails on the first test.
After opening a file, stat returns  nlink == 0. 
I suspect this is another Apollo bug.  Anybody know for sure?
-- 
Tom Tkacik				...uunet!edsews!rphroy!tkacik
GM Research Labs			tkacik@kyzyl.mi.org
"I'm president of the United States, and I'm not going to eat anymore broccoli."
						--- George Bush

rees@pisa.ifs.umich.edu (Jim Rees) (10/24/90)

In article <2724E240.153@orion.oac.uci.edu>, mheffron@orion.oac.uci.edu (Matt Heffron) writes:
  I've just installed perl V3.0 pl 37 on an Apollo DN3500 running Domain/OS (10.2)
  and two tests fail, both with file mode related errors. Does anyone have any
  advice/opinions/... ?

Didn't we hash this over a couple of months ago?  I don't remember the
results, but if you want Perl to work on your Apollo, you need to run it in
a bsd (or maybe sys5) environment, and that includes having your current
directory be a bsd-style directory.  You can change the style of directory
with the "chacl" command: "chacl -B ."

kgallagh@digi.lonestar.org (Kevin Gallagher) (10/25/90)

In article <2724E240.153@orion.oac.uci.edu> mheffron@orion.oac.uci.edu (Matt Heffron) writes: 
>I've just installed perl V3.0 pl 37 on an Apollo DN3500 running Domain/OS (10.2) 
>and two tests fail, both with file mode related errors. Does anyone have any 
>advice/opinions/... ?  
>[examples deleted] 

I had similar problems when I first installed perl 3.0, pl 18, on a DN3500.
Here's what happened and how I fixed the problem.

I installed perl under Apollo's implementation of bsd4.3.  I too found file
mode related problems.  After several days, it dawned on me that 6 months
earlier, when our Apollo's were first installed, they installed all users
under sys5.3.  This meant that everyone's directory structures were set up
with Apollo ACL to emulate sys5 directory protections and inheritance.  Three
months later, it was decided to switch everyone to have their default
environment to be bsd4.3.  HOWEVER, they did not convert user directories to
have Apollo's emulation of bsd directory protections and inheritance!

So, since I built perl under bsd, and Configure told me that it knew I was
running bsd, I concluded that perl was built to expect a pure bsd directory
structure.  So, I went to the perl/t directory and set the acl on that
directory (and its contents) to emulate a bsd directory structure.  I used the
Apollo chacl command, using the -B option.  After that, all the file mode
related errors went away!

Last weekend I installed perl, pl 38, and had no problems.  All tests passed,
with the exception of op.sleep, which sometimes fails and sometimes passes,
because it does not always sleep for the 2 full seconds specified in the test
script.  But this is to be expected in "standard" Unix.  (Apollo is proud of
the fact that it's emulation of Unix is "just like Unix", bugs and limitations
included!)

Good luck!