I need to write a unix shell script to run with cu

I have some machines that I have to dial into but it will be done automatically passing the password without any user interaction.  I know how to cu to a machine cu -s(baud rate) phone-number | tee out_file but I don't know how to get the parameters passed and was told I need to write a shell script to do this.  I am terrible at writing shells.  What I'm needing to do is:
I'll run the cu -s1200 tel_num | tee out_file
The machine will then display connected and I will need to send it a \n (newline).
The other machine will expect a password and I will need to send it one (this password will be coming from a file).
I will then send it a command once logged in called test for example which will run a program and generate a file which will go to the out_file in the first command.
When this is thru, I will want to send it a bye\n (bye and newline) and then ~.\n to logout.

Any help will be greatly appreciated.

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Does your version of cu have the -C flag to run a command?

If not, then writing an expect script is going to be your best bet.
Agreed with Tintin, try to use expect script.

Information/download expect :

after install expect, you can use "autoexpect" to create an expect
script and them modify the script.

man autoexpect
to learn more details

Also have a look at the following expect script examples:

In case you need more help, please post the sample expect script created by autoexpect.
(becaue the "expect" messages are system depandent !)

If we know your OS version, you migh be able to download the exect binary packages.
(make sure that you install tcl, tk and libgcc as well)  eg:

for Solaris get it from:

for HP-UX:

CherylvanAuthor Commented:
We do have -C for a script.  The problem is, I don't know how to write the script to get all this information into the dialing string.  We don't have "expect" and there is no chance of us getting it on the machine.  We have to go thru a whole variance process which takes almost a year and then ultimately ends up getting rejected :( I don't have to work with shell scripting very much so my knowledge of it is very very small.  Please help!!!

Cloud Class® Course: SQL Server Core 2016

This course will introduce you to SQL Server Core 2016, as well as teach you about SSMS, data tools, installation, server configuration, using Management Studio, and writing and executing queries.

Ah, the joys of locked-down QA...

Does your machine have bourne shell?  (/bin/sh)
Does it have bourne-again shell (bash)?
Can your machine support named pipes?

Does your machine have a C compiler of any sort on it?
Come to think of it, what type of computer is it, and what's it running?
It might be that, given that you have implicit permission to put any user-changes you like on the machine in pursuit of this particular issue, having your own private copy of the "expect" binary would not be a "configuration change" (it wouldn't be installing it into /bin after all), it would merely be part of your software feature.
The "expect" tool really was designed exactly for this sort of thing.  It is possible to do similar things with shell scripts and pipes, but it's rather awful in comparison.

You create a couple of named pipes.
You run your cu command, redirecting output to one named pipe I'll call "fred", and redirecting input from the other that I'll call "wilma".
You then run your script, redirecting output to the named pipe "wilma" and input from the pipe called "fred"
Your script (assuming it's bourne-shell or bash) will read from what it considers to be stdin using the "read" command, e.g.
  read LINE
reads a whole line, up to the next LF, and puts the result into the variable LINE
and it outputs to what it considers stdout using the "echo" command, e.g.
  echo "bye"
  echo "~."

The main difference between using "sh" or "bash", and using "expect", is the level of robustness that's easy to write.
With "expect", it's possible to have timeouts and deal with things not working as planned.  with the shell script version, it'll either work, fail or hang - much more difficult to make it deal with retries & any other awkwardness.
Fortunately even modem links tend to have error-correction on them these days, so you either get correct data or nothing.

See if you can find a binary of "expect" for your machine that you can dump in the same directory you're intending to put your scripts in.  If anyone from your QA dept whinges, just point out that it's no more a risk than bespoke scripts (and far more efficient!).
CherylvanAuthor Commented:

I am working on a mid-range sun solaris that does have bourne shell.  I have checked all over for any type of 'expect' but it just isn't there.  I'm pretty sure it will support named pipes.  I am a software developer and the only was I can get stuff installed on the machine is thru a CSA and they make us fill out a change management work order and there is no way this will fly because it is not a standard install on this machine.  Why? I have no idea.  Having anything installed or changed on this machine without approval is a 'fireable offense' so we have to find really creative ways around things that should/could be done easily.  If you can help me, even if its doing it in an ugly script, I would really appreciate it.  I'm getting desperate :(

Hi Cheryl,

    Since you are running Solaris, you can download the expect binary package from

    Please read the readme file and download and install all the depandeces package.
    see: http#12601748

    Then just run "autoexpect" to create an expect script, if you need more help for modifing the expect script. We can help you out.

 >>   "solaris that does have bourne shell",

    are you sure? please try in the following commands to verify:

   ls -al /sbin/sh
   ls -al /usr/bin/sh

   sh should be installed in any case, your System startup scrip use them!

I think we need a little more detail on your 'fireable offense' constraints.
I've worked under such conditions before, and I've found that whilst those in charge of enforcing such issues are almost universally ignorant and unable to do a proper risk assessment, it's often possible to find a way around such contraints.

Firstly, do you have permission to make any software changes to the machine that will be doing the dialing-out?
Secondly, what about the ones you're dialing into?

If the answer is "no" to the first question, then that rather implies that you're not authorised to work on this issue at all, and begs the question of why you're investigating something that you're not allowed to do ("corporate politics" being the common reason ;-)

If the answer is "yes" to either, we then have to determine what is deemed an acceptable software change.
It sounds like anything that adds things to the standard /bin (and so on) areas is out of the question, but what about putting additional files elsewhere?
After all, if you're not allowed to put any files anywhere on the box (and modifying existing files would endanger existing functionality) then you're not allowed to do this at all, hence end of enquiry.

So you must, therefore, be permitted to make some changes to one or more areas on the machine in pursuit of this particular goal, otherwise you wouldn't have started asking.

If you have an area on a filesystem somewhere in which you are allowed to place data files and executable files, then "expect" is not ruled out - it's just an executable, it doesn't need root permissions to run or anything special, and hence is just as much a security/functionality risk as any shell script.

However, if you're dead-set on the shell-script option, it's possible.
You're a software developer, hence you've probably heard of the ETLA "RTFM" ;-)   Unix has a good FM, and "man sh" is actually a good reference, once you've learned the basics.
The basics are:
Start your shell script file with the lines
  # write some comments here to say what your script does
(although don't put in the two spaces at the start of each line - I put them there just to mark the start & end of what I was quoting)
You can define a function by stating
Arguments will be passed into the function as ${1}, ${2} etc (or ${*} means "all arguments seperated by spaces")
Stdin, stdout and stderr will be whatever was set up when the function was called.
You call a function as if it were another unix command in its own right, and don't include the (), e.g.
  my_function_name firstArgument secondArgument
A function can return a number using the "return" keyword.  Zero is "true" and non-zero is "false" when using if statements.  e.g.
  if my_function_name argumentOne argumentTwo
    echo "my function said it worked"
    echo "my function said it failed and returned ${?}"
Variables can be set just by saying
but it's important to note that all variables are global, except arguments.

So, you could have a script which went something like

# Arguments:
#   <file-for-test-output> <test command for far end> [ <argument for test command> ... ]

# reads from stdin, outputs to stdout.
  # read in lines until one says "CONNECTED"
  while [ "${WFC_LINE}" != "CONNECTED" ]
    read WFC_LINE
  # now send out a LF
  echo ""

# $1 is the password
# outputs to stdout
  # wait a moment for the other end to be ready to accept the password
  sleep 1
  # now send it
  echo "$1"

# $* is the command to run, with arguments
# outputs the command to stdout
  # wait a moment before sending the command
  sleep 1
  echo $*

# stdin is the output from the command
# stdout is where the results do
  # now read in all the lines from the other end and spit them to stdout, but
  # don't spit out the final "bye" and "~." lines that we sent.
  while [ "${RRAL_LINE1}" != "bye" -a "${RRAL_LINE2}" != "~." ]
    read RRAL_LINE
    echo "${RRAL_LINE2}"

send_password `cat my_password_file`
send_command $*
echo "bye"
echo "~."
receive_results_and_logout > ${OUTPUT_FILE}

Then you run that script telling it to get its input from one named pipe and send its output to the other named pipe (see my earlier comment for why), giving it the name of a file to spit the results to and the command it should run.  Oh, and it'll read "my_password_file" and expect that to contain the password and only the password.
That should be enough to get you started...
CherylvanAuthor Commented:

I have permission to make software changes (of course I had to file a change management work order and have the client VP who doesn't know and doesn't care approve it).  I can make software changes, I just can't load/unload anything from the machine.  The CSA does that.  Your suggestion will work and I appreciate your helping me with this.

Have a good weekend and Thanksgiving.

I used to work for a large multinational and found that, the larger a company's QA dept, the more time one spends fighting the red tape than actually ensuring that the work gets done to a high quality.

I would question how one can "make software changes" without "load/unload anything" from the machine.
Each character you send to it is loading a character onto the machine.
Ok, it's a picky detail, but that level of anal-retention is something QA depts can relate to, and I'm sure there's some small-print in their regulations that clarify this issue, and they probably have a big enough hole in their wording that you can work within their rules without actually breaking any (just bending them a little).
e.g. a rule preventing the uploading of binaries, only allowing text, can be sidestepped by uploading a script that creates the binary (uuencode & uudecode have been converting text to data and back for years - it's what we used before MIME on emails)

Good luck :-)

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
System Programming

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.