Being a Perl twiddler I cant give you much advice regarding Expect.
I just want to say something about "hiding" stuff from non-staff users.
You can actually return different content to different users, depending on, for example, the ip number of the calling machine.

We were in a situation where our opac required a time out value to be configured.
A high value would take too much resources, and the lower the value, the more frustating for staff working at circulation and information desks sitting with browsers timing out every now and then.

Now we have a javascript being loaded to staff browsers reloading the current html page at an interval triggered before the session times out.

<!cript language javascript src="http://myserver/cgi-bin/javascript/"></script>

This refers to a perl script, but of course it could be any kind.
The script checks the ip number of the caller.
If it is identified as a staff machine it returns a certain set of javascript code.
If it is not it returns some different javascript.

This technique is quite handy when you are dealing with webpages you dont have compleate control over, but have to rely on some kind of "injection" methods.
As is often the case with web opacs.

You can use the same technique to add a link to a page, when requested by staff.

Leif Andersson, Systems Librarian
Stockholm University Library
SE-106 91 Stockholm
Phone : +46 8 162769
Mobile: +46 70 6904281

-----Ursprungligt meddelande-----
Från: Code for Libraries [mailto:[log in to unmask]]För Ken Irwin
Skickat: den 7 juli 2006 15:57
Till: [log in to unmask]
Ämne: [CODE4LIB] "Expect" OPAC output to web?

Hi folks,

I've been toying with the idea of trying to rig a web page to call an
expect script to login to our OPAC, look up a book and then display the
circ/renewal stats. The function would be accessible through a
mostly-invisible* link on our web page, and lead to a password-protected
script so that the output was only available to library staff. This
would let us look up circ stats from the web OPAC (which we can't do
through its native functionality), rather than having to log in to the
telnet/staff side to do so. The script takes about 20 seconds to
execute, so it would be pretty inefficient for large-scale lookup
operations, but would be really handy on those fairly frequent occasions
when you just want to know if a book that shows up in a search has ever

(* "mostly invisible" -- the link would be background-colored, so it
would show up for anyone using a text-browser on our web OPAC, and would
just get them to a password request if they followed it. Staff would
just have to know where to click the link on the page. I've tried that
approach for a previous experiment and it worked out reasonably well.)

My questions:
1) does anyone have experience shunting Expect script output to web
pages? how did you get it to work? My initial attempts have not worked out:
 - first try: using php's *echo exec ("script.exp")* or *passthru
("script.exp")* -- this returned my input, but didn't show the resulting
info screens output by the OPAC
 - second try: calling the Expect script directly with a *puts
"Content-type: text/plain\n\n"* declaration at the beginning -- this
might work, but right now Apache is not configured to execute Expect
scripts for web output, so it just echoes the script contents instead of
executing the file. This could be altered, but not today.

2) Is this an inherently Bad Idea? I don't think it would be
particularly prone to abuse, and the user would not get to specify any
of the inputs for the script so I think it would be ok, but you may have
some ideas I'm overlooking.

3) Is there a much smarter way to do this?

What think you all?

expect "ingenious replies"
send "Ken"

Ken Irwin
Reference Librarian
Thomas Library, Wittenberg University