home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!paladin.american.edu!darwin.sura.net!wupost!sdd.hp.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!ohstpy!miavx1!watson.lib.muohio.edu!pmurray
- Newsgroups: alt.gopher
- Subject: Re: Executing shell scripts
- Message-ID: <1992Jul24.130134.11882@miavx1.acs.muohio.edu>
- From: pmurray@watson.lib.muohio.edu (Peter Murray)
- Date: 24 Jul 92 13:01:34 -0500
- References: <19920720163956SEB1525@MVS.draper.com>
- Organization: Miami University Libraries
- Nntp-Posting-Host: watson.lib.muohio.edu
- Lines: 25
-
- SEB1525@MVS.draper.com (Steve Bacher) writes:
- : In article <1992Jul20.101113.11811@miavx1.acs.muohio.edu>,
- : pemurray@miavx1.acs.muohio.edu writes:
- :
- : >Interactive shell scripts aren't going to work in the standard release because
- : >there is no mechanism for the client to pass information back to the server
- : >(other than a "query" request or something along those lines).
- :
- : Wouldn't these work if the "exec:" hack were modified to take the
- : query data and pass it to the script following the args embedded
- : in the "exec:" selector path? The script would then see the options
- : following the "hard-coded" ones. Or else the tab character could be
- : passed on the command line to delimit the variable options. On Unix
- : systems this would have to be quoted, of course.
-
- This isn't an interactive shell script, though. The application I have
- in mind is forking of an expect script to automatically log a user on
- to our library automation system. Data has to be passed interactively
- between the client and the computer the user is telnetting to.
-
- Peter
- --
- Peter Murray, Library Systems Manager pmurray@watson.lib.muohio.edu
- King Library Technical Support pemurray@miavx1.bitnet
- Miami University, Oxford, Ohio W:513/529-2884
-