Not An Identifier

[Ryan_102]

Hi, I'm new to the unix environment, and now i'm stuck with trying to rectify the problem below. Hope someone can help me out:

I'm suppose to run a cron job that reads and executes the script: sh_download.sh. The content of the script is:

#!bin/sh
###############################################
# Shell Script : sh_download.sh
# Purpose : To schedule all the download job # with FTP to get the data file from NT server
# By:Ryan
# To schedule : Create cron job for
#sh_download.sh,< change the mode>
###############################################

LOCAL_FILES="/home/db01"
BCK_FILES="/home/db01/backup"
ORACLE_HOME="/orasw2/appl/oracle/product/8.1.7"
export ORACLE_HOME

DATE1=`date +"%d%m%Y%H%M%S"`
DATE=`date +"%y%m%d%H%M"`
echo $DATE
echo $DATE1

sqlplus -s scott/tiger@test << !

@ $LOCAL_FILES/mth_pdb.sql

exit
!
sh $LOCAL_FILES\unix_to_mth.sh


When the above job is run, there are 2 errors:

/home/sodb01/so/mha/sh_download.sh[10]: ^M: not found

/home/sodb01/so/mha/sh_download.sh[14]: ORACLE_HOME^M: This is not an identifier


Can someone help to explain the errors? And what is ^M


Many thanks
Ryan

[john korterman]

Hi Ryan,
the ^M indicates that the file has been ftp'ed from Windows/NT without char conversion; probably done with ftp "bin-command". You can convert the chars of the script by running the command dos2ux like this:
# dos2ux sh_download.sh >new_sh_download.sh

However, you can also ftp the script again. I assume that you have given the ftp command "bin". Do not, as unix should be able to figure out the correct conversion itself.

You should also correct the first line:
#!bin/sh
should probably be:
#!/bin/sh

regards,
John K.

[James Murtagh]

Hi Ryan,

The ^M is a control character, normally seen when you ftp a file from a Windows OS to a Unix OS. It appears your script has been ftp'd in this way. To remove these from the script use:

# cat sh_download.sh|sed -e 's/.$//' > sh_download_new.sh

You can then test the new script and if it works move it into place. Use a tool like vi on the original script to see the control character at the end of each line.

A brief discussion of this can be found in this thread:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xd39419434a69d711abdc0090277a778c,00.html

Regards,

James.

[Ryan_102]

Hi. Thanks for the prompt reply..but something still bugs me:

1. So is the ^M that's causing the 2 errors which I have mention? Will removing it solve the errors? Why [10] and [14](not an identifier) has an error?

2. I thought the ^M serves a purpose, that is to act as an automtic function. So how do I distinguish whether which ^M is the result of ftp in binary mode and which serves at the function?


thanks!

Ryan

[T G Manikandan]

When dos files are transferred to unix they are have ^M appended.

To convert those files to unix format
use

#dos2unix source-file desti-file

[Bill Hassell]

^M is an artifact from playing two unrelated opsystems together. In Unix, a plain ASCII file has a single EOL (end-of-line or line terminator) character: LF of linefeed. However, DOS and other PCwindows systems use CR (carriage-return) plus LF fo their ASCII files. There is no reaso to assume that any major opsystem has a comnpatible file format, which is why there is the ASCII translator built into ftp. Just issue ASCII as a command and transfer ASCII files.

This is a 2way street. Transfer and ASCII file from Unix to a PCwindows system using BINARY and Notepad will display black squares for each LF character. Now Wordpad and Word4Windows will APPEAR to display correctly but the lone LF character is called a soft carriage return which has special meanings within the word processors.

SO, ALWAYS use ASCII when transferring ASCII files--ftp eliminates the incompatibility issues.

And the correct path for sh (the POSIX shell) is not /bin/sh, it is /usr/bin/sh (been that way for a decade in HP-UX). The reason that /bin/sh works is that there is a transition link at /bin (which is not a directory at all) pointing to /usr/bin. Same with /lib. Unix systems conforning to V.4 filesystem layouts follow this convention. But most important, symlinks happen to be the default--they *WILL* change to an optional feature in future releases (HP has stated this several times). Time to upgrade your script headers...