🚀 go-pugleaf

In NCR Tower Unix, release 20100, if I create a crontab format file as
root then do
crontab filename
it wipes what is currently in the crontab for root and replaces it with
the new entries. It does not append it, as the manual implies. We didn't
have cron.allow or cron.deny set up, so root was the only one able
to use cron (all the users are naive users).

This means I must manually reload the thing myself

Greg
Disclaimer - Thomas Cooks Iron, My Opinions
Greg Calkin                                   Thomas Cook N.Z. Limited,
...!uunet!vuwcomp!dsiramd!marcamd!tcnz2!greg  PO Box 24, Auckland CPO,
or greg@tcnz.co.nz                            New Zealand.    Phone (09)-793920

greg@tcnz2.tcnz.co.nz writes:
>In NCR Tower Unix, release 20100, if I create a crontab format file as
>root then do
>crontab filename
>it wipes what is currently in the crontab for root and replaces it with
>the new entries. It does not append it, as the manual implies. We didn't
>have cron.allow or cron.deny set up, so root was the only one able
>to use cron (all the users are naive users).
>This means I must manually reload the thing myself

That's exactly how System V crontab works and is supposed to work, as far
as I can tell. It works that way on our ATT 3B2s, and our Apple Mac A/UX
systems.

When I don't feel like vi-ing the appropriate file, I do crontab >tempfile,
vi tempfile,
crontab tempfile


aem



a.e.mossberg - aem@mthvax.cs.miami.edu/aem@umiami.BITNET - Pahayokee Bioregion
The life of money-making is one undertaken under compulsion, and wealth is 
evidently not the good we are seeking, for it is merely useful for the sake 
of something else.					- Aristotle

greg@tcnz2.tcnz.co.nz writes:
>On NCR Tower unix, release 20100, the unpack we have unpacks
>linked packed files. I discovered this because I wanted to
>unpack, then compress the man files, some of which are linked.

>Compress isn't this stupid - it doesn't unpack these files.
>Beware - this is going to cause me some headaches.

What do you expect from System V? Geez.

System V only has hard links. If you modify a file, the link is destroyed.
(I'm probably explaining this badly).

When you unpack a file, it becomes a seperate file.

Someone out there probably has written a script or program to handle
this, but it is not a System V bug -- it's a System V "feature".


aem

a.e.mossberg - aem@mthvax.cs.miami.edu/aem@umiami.BITNET - Pahayokee Bioregion
The life of money-making is one undertaken under compulsion, and wealth is 
evidently not the good we are seeking, for it is merely useful for the sake 
of something else.					- Aristotle

To append entries to crontab, try

	crontab -l | cat - /tmp/mynewentries | crontab

Or, as I prefer, from vi, you just type

	:%!crontab -l

then edit the entries as you see fit, and finish with

	:%!crontab

-- 
"My God, Thiokol, when do you     \\	Tom Neff
want me to launch -- next April?"  \\	uunet!bfmny0!tneff

>In NCR Tower Unix, release 20100, if I create a crontab format file as
>root then do
>crontab filename
>it wipes what is currently in the crontab for root and replaces it with
>the new entries. It does not append it, as the manual implies.

Unless somebody at NCR decided to modify "crontab" but didn't get it
right, it's the manual that's incorrect; in vanilla S5 from AT&T,
"crontab" is intended to replace, not append to, the existing "crontab"
file, and that's what it does.  (If you want to append, then as long as
you don't have multiple writers, you can obviously arrange to do that by
using "crontab -l" to copy the file, appending to the copy, and using
"crontab" to write it out.)

(If somebody at NCR *did* decide to do that, they should have thought
twice about making "crontab" incompatible - if it appends, is the only
way then to delete a "crontab" entry to nuke my entire "crontab" file
with "crontab -r" and then to stuff the new file in?  I suspect, though,
that it's purely a documentation screwup.)

I recently examined the crontab man page on a NCR Tower 32/600 Release 2.01
(the exact same system as Greg Calkin used) and I read the man page to mean
that the entries would be replaced, I do not see how he got the impression
he did.  NCR's man page states:
	Crontab copies the specified file, or standard input if no
	file is specified, into a directory that holds all user
	crontab files.  A user crontab file specifies .....

If Greg still feels this is misleading he should contact his NCR representative
and discuss the problem.  Perhaps the man page should be clarified.

Disclaimer:
	I work for NCR, but not on this product.  These opinions in NO WAY
	necesarily reflect those of NCR.

greg@tcnz2.tcnz.co.nz writes:


>In NCR Tower Unix, release 20100, if I create a crontab format file as
>root then do
>crontab filename
>it wipes what is currently in the crontab for root and replaces it with
>the new entries. It does not append it, as the manual implies. We didn't
>have cron.allow or cron.deny set up, so root was the only one able
>to use cron (all the users are naive users).

To quote the TOWER User Reference Manual crontab(1) entry:

	  "Crontab copies the specified file, or standard input if no
	  file is specified, into a directory that holds all user
	  crontab files."

I don't believe copy implies append.

If it is any consolation, you are not the first person to make this
mistake. :-)

-- 
* Tom Moore                NCR Corporation  PCD-6              (513) 445-1373 *
* Consulting Analyst       1700 S. Patterson Blvd.         VOICEplus 622-1373 *
* Network Applications     Dayton, OH 45479          Tom.Moore@Dayton.NCR.COM *

In article <2271@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
> In article <139@tcnz2.tcnz.co.nz> greg@tcnz.co.nz writes:
> >In NCR Tower Unix, release 20100, if I create a crontab format file as
> >root then do
> >crontab filename
> >it wipes what is currently in the crontab for root and replaces it with
> >the new entries. It does not append it, as the manual implies.
> 
> Unless somebody at NCR decided to modify "crontab" but didn't get it
> right,

Nope.  No modifications. Except expanding the usage message to include the
-l option.

> it's the manual that's incorrect;
	[...]
> I suspect, though, that it's purely a documentation screwup.

Nope.  The man page for crontab, while not a verbatim copy of the V.2.1
man page uses the same language:

	Crontab copies the specified file, or standard input if no
	file is specified, into a directory that holds all user
	crontab files.

This isn't the clearest and most complete description of crontab's behavior
but I don't see the "append" implication either.
-- 
	-Mike Wescott
	 mike.wescott@ncrcae.Columbia.NCR.COM

In article <139@tcnz2.tcnz.co.nz> greg@tcnz.co.nz writes:

>In NCR Tower Unix, release 20100, if I create a crontab format file as
>root then do
>crontab filename
>it wipes what is currently in the crontab for root and replaces it with
>the new entries. It does not append it, as the manual implies. We didn't
>have cron.allow or cron.deny set up, so root was the only one able
>to use cron (all the users are naive users).

The 'crontab' command works in exactly the same way on our Encore Multimax,
running UMAX V 2.2f. However, the manual says that the contents of <filename>
or stdin is *copied* to the crontab directory, thus overwriting what's
currently in the crontab file. It doesn't say a word about appending. From
what I've seen, Encore's manual says exactly the same thing all other System
V-like crontab manuals I've seen, so if the NCR manual differ, I guess that
NCR is in error.

BTW, Encore's manual on crontab also says, in the BUGS section, that if one
enter "crontab" and then changes ones mind, one should NOT terminate the
command with ctrl D, but with the interrupt key. Otherwise, the current
crontab will be replaced with an empty one. This phrase is not in all
manuals, even though the command do work in this way.
-- 
          Robert Claeson      E-mail: rclaeson@erbe.se
	  ERBE DATA AB

In article <485@umigw.MIAMI.EDU> aem@Mthvax.CS.Miami.Edu writes:
>greg@tcnz2.tcnz.co.nz writes:
>>On NCR Tower unix, release 20100, the unpack we have unpacks [...]
>>Compress isn't this stupid - it doesn't unpack these files.
>
>System V only has hard links. If you modify a file, the link is destroyed.
>(I'm probably explaining this badly).

Actually, NCR has implemented symbolic links for System V. So far as I know,
these aren't used by any of the "standard" software supplied by NCR. We use
them for development, but compared to Berkeley symbolic links, they are not
complete (particularly with respect to linking directories).

Nicholas Jacobs
UUCP: ...!uunet!toro!nick Internet: toro!nick@uunet.uu.net
AT&T: (212) 236-3230

In article <737@toro.UUCP>, nick@toro.UUCP (Nicholas Jacobs) writes:
> In article <485@umigw.MIAMI.EDU> aem@Mthvax.CS.Miami.Edu writes:
>>greg@tcnz2.tcnz.co.nz writes:
>>System V only has hard links. If you modify a file, the link is destroyed.
>>(I'm probably explaining this badly).
>
> Actually, NCR has implemented symbolic links for System V.

NCR's implementation of symbolic links is almost unusable.  There is no
way of telling if a link is a symbolic link or a hard link; and most
programs break when they come across a symbolic link that points to a
non-existant file (can't stat xxxx).

A related problem: A symbolic link that points to a non-existant file
stops ftw(3) from walking the file tree.  I don't think that should
happen.  It seems to me that ftw(3) is supposed to continue walking,
even after a file that it can't stat(2).

Grump.  (Hello NCR, Columbia.  Are you listening?)


David Newall                     Phone:  +61 8 343 3160
Unix Systems Programmer          Fax:    +61 8 349 6939
Academic Computing Service       E-mail: ccdn@levels.sait.oz.au
SA Institute of Technology       Post:   The Levels, South Australia, 5095

In article <966@levels.sait.edu.au> ccdn@levels.sait.edu.au (DAVID NEWALL) writes:
>In article <737@toro.UUCP>, nick@toro.UUCP (Nicholas Jacobs) writes:
>> Actually, NCR has implemented symbolic links for System V.
>
>NCR's implementation of symbolic links is almost unusable.  There is no
>way of telling if a link is a symbolic link or a hard link; and most
>programs break when they come across a symbolic link that points to a
>non-existant file (can't stat xxxx).

A friend of mine (wdr@csoft.co.nz) wrote a small number of utilities
to get around these problems, including one to cruise down the file
system and generate a script which could rebuild the current symbolic
links.

The major headache we had with them is that our dbms appeared to do
file locking on the filessystem:inode basis, but did not handle
symbolic links, so that two programs could lock the same data if they
were running in the DBMS on different file systems. We have not had 
the spate of DB corruptions we used to have since the last upgrade of
the software, but it is something to watch for.

greg
Disclaimer : no-one tells me what to write
Quote :   Have I aligned
            with a blown mind
              Wasted my time
                On a drawn blind -- Zappa

Greg Calkin                                   Thomas Cook N.Z. Limited,
...!uunet!vuwcomp!dsiramd!marcamd!tcnz2!greg  PO Box 24, Auckland CPO,
or greg@tcnz.co.nz                            New Zealand.    Phone (09)-793920

greg@tcnz2.tcnz.co.nz (super) writes:

>In article <966@levels.sait.edu.au> ccdn@levels.sait.edu.au (DAVID NEWALL) writes:
>>In article <737@toro.UUCP>, nick@toro.UUCP (Nicholas Jacobs) writes:
>>> Actually, NCR has implemented symbolic links for System V.
>>
>>NCR's implementation of symbolic links is almost unusable.  There is no
>>way of telling if a link is a symbolic link or a hard link;...

Even then, the latest man page for /usr/ucb/ls (Page 1, Feb. 1989) still
insists on, that -F will mark symbolic links with '@'. Does it work? NO
Does the assembler command swbeg generate correct code? NO
Can you put a comment line after swbeg? NO
Can you change a register value with adb? NO
Does the C modifier work? NO
Is there a man page for the alternative assembler? NO
Can you write assembler on a TOWER? ????
-- 
Jan B. Andersen                              ("SIMULA does it with CLASS")