Successfully running software delivery scripts in Unix and Windows environments

Document ID : KB000028202
Last Modified Date : 14/02/2018
Show Technical Document Details

Question: 

Why could a software delivery job to a Unix agent fail?

There are a few reasons why deliveries from an NT local server to Unix agents may not succeed. One of the most common is due to the differing conventions used by the two operating systems to terminate lines of text. This article discusses these differences and gives hints as to how to avoid mixing the two formats.

Environment:  

CA Client Automation – All Versions

Answer: 

On Windows and Dos based platforms, text files have each end of line terminated with a special character sequence. This is commonly known as a carriage return / line feed pair (CRLF). In programming terms, these can be represented by the escape characters '\r' (Ctrl-M under Unix) and '\n' (Ctrl-J)respectively. The purpose of these control characters is to aid the operating system in interpreting text files on a line by line basis.

On Unix systems, the convention is to terminate lines with a newline character only ('\n'). This is where the problem arises. Most installations under Unix are controlled by a shell script, which
is essentially a text file, for which the shell supplies the correct
interpreter based on hints in the first line of the script.

Commonly the following line is seen at the top of such scripts, indicating to the shell that the Bourne shell executable should be used to interpret and execute the 
script.

#! /bin/sh 


If such a script is created, or even just edited, on a Windows machine, then, when saved, each line will be terminated with the sequence '\r\n'. So that the first line (including control characters) will read:


'#!/bin/sh\r\n'

When such a script is loaded on to a Unix machine , the first line that is read will look (to the Unix system like):

'#!/bin/sh\r'

On seeing this, the system will search the /bin directory for a program named 'sh\r'. Of course, this does not exist (or should not!), and the script fails with the error (or something similar):

ksh: /bin/sh : not found

 

Similarly, ips scripts created on a Windows machine will have each line terminated with '\r\n', and when run with the script interpreter casdips, which under Unix expects only '\n' as line terminator, then the script too will fail. The error message will depend on the command which casdips attempted to execute.

The simplest way to prevent this kind of error is to create, test and debug packages and install scripts intended for Unix agents on the Unix machine itself. This will ensure that the correct line end convention is used, and also that the install script is bug free,
before an attempt is made to deliver the software package via CA Client Automation. To check whether a script has the wrong line endings, it is sufficient to load it into the vi editor on a unix machine. The superfluous '\r' characters can be seen as '^M' at the end of each line.

Additionally, if it is necessary to store the package on a Windows volume, proceed as above, then transfer the package back to the Windows machine using ftp in BINARY mode. (Using ASCII text mode would again corrupt the file)

The package can then be registered to the Software Library.