Writing shell scripts that call SAS® software


(Author: Roland Rashleigh-Berry                                                                                Date: 26 Jun 2006)

Introduction

You should limit shell scripts that call SAS software to those needing to get information from SAS software objects or those required to call SAS software procedures. This is because invoking SAS software in a script creates an overhead. For reading text, the language "gawk" is faster and better. You can read about how to use gawk here. If your script combines information from a SAS software object with other tasks not related to SAS software objects, then you should learn how to split up your task into multiple scripts so that one script just acts on the SAS software object and then outputs this information to other scripts for further processing. Knowing how to split up tasks like this and the best way to do it comes with experience.

The reason you will want to write shell script that call SAS software is to avoid using an interactive SAS session. Spectre favours batch working so if programmers need information about SAS software objects or need to call a SAS software procedures to show them some simple output then it would help them if they could do this from the Unix command line. There are already some shell scripts that call SAS software in Spectre such as contentsl and summary for this but the list is not exhaustive. There will be times when you need to write your own shell script that call SAS software.

Writing shell scripts that call SAS software is very easy and to make it even easier there a utility to help you do this that you will be introduced to.

Invoking SAS® software with -stdio

If you have a script then it is good practice to have all the code you are going to use in that script and not in an external file. The reason for this is to avoid the possibility of somebody changing that code while the script itself sits in a separate secure library. It is a matter of security. So the easiest way to include SAS software code in a script is to put it in a "here document", and if you have forgotten what that is then click here. You also have to think about the user interrupting the script half way through. If they interrupt the script then it is better to not have a code member and a log member left over. One approach to get around this problem is to use the "here document" to write to a temporary code member, to execute that code member and write the output to a temporary file, next to delete the code member and the log and then to "cat" the temporary file to the user's terminal and lastly to delete that temporary file. That way, if the script gets interrupted, it will most likely get interrupted at the "cat" stage with the sas member and log already deleted. But there is an even neater way of doing it using the "-stdio" option. This way you can feed your code in the "here document" directly into SAS software with the log directed to the Unix dustbin /dev/null using "2>/dev/null" and you can route the output to stdout in your code. That way nothing gets left over if the script is interrupted.

sasunixskeleton

There is a script named "sasunixskeleton" to help you create a shell script that calls SAS software that uses the "-stdio" option. Here is an example with me creating a script named "dummy" in my home directory. I will use the script without an argument so "sasunixskeleton" will prompt me for a script name.
 
$ sasunixskeleton
Enter script name: dummy
This utility will generate a script and store it in the current
directory.

Enter purpose of script: Just a demo
script "dummy" has been generated and stored in the current directory
 

...and here is the script it created.
 
#!/bin/bash
# Script     : dummy
# Version    : 1.0
# Author     : Roland Rashleigh-Berry
# Date       : 23-Apr-2006
# Purpose    : Just a demo
# SubScripts : none
# Notes      : EDIT
# Usage      : dummy       EDIT
#
#===============================================================================
# PARAMETERS:
#-pos- -------------------------------description-------------------------------
#  1   First parameter (if any) description    EDIT EDIT EDIT
#  2   Second parameter (if any) description   EDIT EDIT EDIT
#  3   etc. or.....
# N/A  Do not supply any parameters            EDIT EDIT EDIT
#===============================================================================
# AMENDMENT HISTORY:
# init --date-- mod-id ----------------------description------------------------
#
#===============================================================================

# Put out a usage message if not enough parameters supplied
if [ $# -lt 2 ] ; then
  echo "Usage: dummy ............EDIT EDIT" 1>&2
  exit 1
fi
 

# Feed SAS code into standard input
sas -stdio -noautoexec -sasuser work 2>/dev/null << -----FINISH-----
options validvarname=any nofmterr noovp nodate nonumber;
libname here './' access=readonly;

EDIT EDIT EDIT EDIT

Put your code here. Use $1 to resolve the first entered parameter.
Use $2 to resolve the second entered parameter.

$'s get treated like the &'s in front of macro variables by scripts.
It will try to resolve a Unix variable if you use one in a format.
To get round it you have to use a slash in front of the dollar like
this "\$" .

Your final output should be written to normal print output or you
could use a data _null_ step like the following to put the contents
of a dataset out to stdout.

data _null_;
  file stdout;
  set xxxxx;
  put @1 xxxx;
run;
-----FINISH-----
 

The script it created is skeleton script code, hence the name of the utility "sasunixskeleton". You have to edit the script where you see "EDIT" and add your code to the "here document" which is ended by the string "-----FINISH-----" starting in the first column. Note the options used when invoking SAS software. "-stdio" is needed but you may need to change the default options "-noautoexec -sasuser work". With the "-stdio" option in effect, the log gets written to stderr (standard error) which has file handle "2" (standard output has file handle "1") so you see I have routed the log to the Unix dustbin using "2>/dev/null". If you are debugging the script then you will need to route the log to a file in your home directory so you can look at the log and see what the problem is. But don't forget to route the log back to /dev/null again when you have finished debugging.

The important thing you have to remember is what happens to the "$" (dollar) sign in a script. Just like you reference a macro variable with a "&" in front of it, scripts use the "$" sign to reference shell variables. So if you have a format like this "$200." then it will cause an error because it will look for a shell variable named "200". So to get round this in the here document you should put an escape character "\" in front of the "$" so you would write the same format as "\$200.". You need to remember this. However, this does not apply to the script parameter values "$1", "$2" etc..

If your script creates normal print output then it will automatically be written to stdout (standard output) which is what you want, as this will go to the user's terminal. But if you "put" the values then you must use "file stdout" so that the "put" values are written to standard output.

Examples

Here are some examples of shell scripts that call SAS software where the output is normal print output.
summary
printall

Here are some examples where "file stdout" is used.
contentsl
showlfmt

Conclusion

Hopefully, you have seen how easy it is to create a shell script that calls SAS software. Using the information in this document then the only difficulty you should encounter is with the code itself, but then you should be an expert with that in any case.
 
 
 

Use the "Back" button of your browser to return to the previous page

contact the author




SAS and all other SAS Institute Inc. product or service names are registered trademarks or trademarks of SAS Institute Inc. in the USA and other countries. ® indicates USA registration.