[520] in SIPB-AFS-requests
potential improvement to backup procedure
daemon@ATHENA.MIT.EDU (Mark W. Eichin)
Tue Oct 29 04:13:59 1991
Date: Tue, 29 Oct 91 04:13:37 -0500
From: "Mark W. Eichin" <eichin@Athena.MIT.EDU>
To: sipb-afsreq@Athena.MIT.EDU
I ran across this a while ago, but forgot to deal... does anyone think
this might be useful for improving the backup procedure we use,
perhaps to automate it a little more?
_Mark_
[0339] daemon@ATHENA.MIT.EDU (NIK%ZURLVM1.BITNET@pucc.princeton.) Info-AFS_Redistribution 10/16/91 06:25 (30 lines)
Subject: YES NONE
Date: Wed, 16 Oct 91 10:19:11 SET
To: Info-AFS@transarc.com
From: NIK%ZURLVM1.BITNET@pucc.princeton.edu
Date: 16 October 1991, 10:04:20 SET
From: Michael Niksch 0041-1-7248-913 NIK at ZURLVM1
To: Info-AFS@transarc.com
Subject: Running 'butc' in background
I am currently setting up the zurich.ibm.com cell and ran into the same
problem of 'butc' always wanting to run in the foreground. I found a
workaround by starting butc like
ksh -c "(while :;do print -- \"$answer\";done)|butc -port $port >$file)"&
which essentially keeps sending a default answer into butc's input pipe.
You should be aware that different backup commands may require different
default answers. The 'dump' routine will ask to put in a tape and will be
glad if you pipe in just a newline. If you do a scantape, the oh-so-friendly
butc will ask you whether you want to scan another tape and you have to
respond a 'n' to make it stop. Seems that butc was written by people having
the imagination of every site being able to afford thousands of human slaves
to run interactive backup.
Transarc told me that backup will stay interactive in the next release.
I am afraid that the addition of more 'user-friendly' butc features will
break my approach.
Michael Niksch
--[0339]--
