Shell Programming and Scripting

I have asked this before but I haven't had any luck so far getting this to work. I use RCS(revision control system). When it runs if I pass the value 'unlock' to $3 its reassigned to $unlock. When I run the command (rcs -u'version number' 'filename') ti will ask me 1-(Do you want to break the lock y/n?) then 2-(The reason for breaking the lock) 3-(Enter a '.' period on a blank line when done) All I want to pass to the program is (y,production install,'.') When I run rcs manually and I simply hit enter on the line asking if I want to unlock the file, it will terminates and says the file is still locked which is what is occurring. It will not pass the answers I have put into the script. It seems to act like I simply hitting the enter key. Does anyone have any ideas?

Code:

if [[ $unlock = "unlock" ]]; then
print $PS1 "rcs -u${Reqvers} $Reqfile"
rcs -u${Reqvers} $Reqfile<<PAUL
y
PROD install of $acr
PAUL
 fi

try with expect

I would if I could but the script is doing other things not compatible with expect and this part of the script runs within a while ..do.. done

A ksh co-process might work. Here is an example of using a co-process to talk with the ftp program. But a script that breaks rcs locks automatically would scare me.

I can see no reason to run this in a while loop.

Why not just have a script with the program name as a parameter "su" to the user holding the lock.

Code:

rcs -u "${program_name}"
Or if it is not the most recent version which is locked:
rcs -u "${revision}" "${program_name}"

For those who are wondering, you need an "unlock" script for the cases when programmers check out a program using "co" with some intention to make changes ... and then make no changes.

As administrator (i.e. root) I always run an unlock script while in a "su" session as the user holding the lock. This way the unlock program does not ask questions.

Thanks for your responses.

methyl,
There is actually a reason we do it this way and it involves sox compliance rules and auditor requirements. We have generic users setup for testing and production installs and they are the only users allowed to do these installs(actually we su to them) and as such they must be the ones checking out and breaking the locks. The developers cannot be the users doing installs or even be shown as the owners of the files when they are installed(segregation of duties). We normally use HP'S GCM tool to do our installs and it su's to the proper user prior to checking out and installing(and it handles unlocking properly) but sometimes a manual install by my release op's department is required since automation may not be possible for whatever reason. Also this script is only used when we have a large number of files to install and checking them out manually and breaking the lock is time consuming. We also want to be prompted to break the lock since this sends an email to the developer and business owner that the lock is broken and now they can make changes to the code for future installs. It also creates an audit trail. I know this is wordy but we only run this script during production installs by running it with 'unlock' as the third parameter and its at this point we break that lock and we need to be prompted for this so we can enter information about the install ID # and version of the lock being broken, again only for auditing purposes. Its in a loop because we have an input file with several files to process and it needs to loop through each of them. Yeah, this probably just makes it more confusing. I am thinking of just sending the output to a file with file,version and unlock reason and running this separate after all files have been checked out. Maybe using 'expect' as someone suggested but I am unfamiliar with that but it seems fairly straightforward.

---------- Post updated at 08:52 PM ---------- Previous update was at 08:31 PM ----------

Thanks Perderabo,

I'll take a look at that tomorrow. Just getting back into unix/linux and scripting after being stuck in a windows world for so long is taking time to get ramped up again..