vdump behaviour

From: MacDonell, Dennis <DennisMacDonell_at_auslig.gov.au>
Date: Thu, 13 Dec 2001 12:18:35 +1100

Hi,

I'm trying to control an autochanger through a backup script using expect
on a tru64 5.0+ server using vdump to do the dumping. I'm having a little
bit of trouble getting expect to sort out the messages sent back by vdump.
For some reason expect is not line oriented, whereas I would like to be able
to pick up the lines like

vdump: Change Tapes: Mount tape# 0002
vdump: Dumping 577153022 bytes, 1407 directories, 28905 files
vdump: Dump completed at Tue Dec 11 14:03:08 2001
vdump: can't open device file </dev/ntape/tape4_d1>; not ready

but these lines always seemed to get lumped in with other lines of data that
were sent at the same time by vdump.

I've been using
   expect { pat {code} [; pat {code} ] ... }
   where pat is of the form -re "((path|dev|type|advfs)\[^\r]*)\r" and
code is just some expect/tcl code.

The example pattern is supposed to pick up any line that starts with a path
or a dev or a type or a advfs followed by a string not including a \r
followed by a \r. However when it enters the relevant code block for the
pat, a print out of expect_out(0,string) indicates that it matched a
pattern, but a print out of expect_out(buffer) indicates that that match
took a lot more out of the buffer than you would have expected. The actual
match could have been in the middle of the whole buffer.

I have enough patterns in the script to pick out each vdump line as a
separate pattern matching exercise, but when I write out inside the {code}
section what is being captured by each pattern, I see that whole chunks of
lines are being soaked up by a pattern. Can anyone sort me out on what is
going on.

Dennis

######################################
Dennis Macdonell
Systems Administrator
National Mapping Division, Geoscience Australia
mail: PO Box 2, Belconnen, ACT 2617
email: mcdonell_at_auslig.gov.au
ph: 61 2 6201 4326
fax: 61 2 6201 4377
######################################
Received on Thu Dec 13 2001 - 01:19:49 NZDT

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:43 NZDT