UNIX for Advanced & Expert Users

I've experienced a problem with CVS when I've checked out sh script.
When new build was created sources were checked out from CVS under Windows. Later this build was deployed under Linux und I recieved error from shell becouse of CR-LF EOL in file. I've tryed command dos2unix and become script without errors.
But when this script is checked out under Linux there are only LF EOL (without CR) and no errors in script.

How can I check out file from CVS with LF as EOL (or how can I modify script to become no errors due to CR-LF)?

Any help appriciated.

CVS under Windows will always produce files with Windows carriage-control characteristics. My version of Windows cvs doceumentation (Don Harper 1999)
does not mention anything about changing file formats with regard to EOL.

Stick with dos2unix. I do not think you can check it into CVS as a DOS format file and then check it back out and have it be a UNIX carriage-control file.

1) what if I switch script file from ASCII to Binary in CVS?

2) what problems can be in script due to CR?? (It was a surprise for me)

If files are checked in in ASCII mode, it will always be checked out with DOS EOL on Windows and Unix EOL on any Unix. This is similar to the ASCII/Binary mode in FTP. This behaviour is intentional and in general will not cause any problems. In fact, I find it good sometimes to do it this way because some Windows editors such as Notepad does not interpret Unix EOL at all. Some editors may convert EOLs without notice, causing more problems. Also, if you check out the files from Windows and just ship to Linux and commit from there, you are bound to experience this sort of issues.

Therefore, maintain two checkout copies. One from Linux and another from Windows, and do not ship these files in between. There should be no problems with ASCII mode at all.

From your description, it appears to be that your script has already been corrupted with residue control characters. This is pretty normal as I have seen files from some open source projects are also messed up this way, although C sources are less sensitive than sh scripts when it comes to this problem. Of course this should be fixed. VIM for instance lets you see these control characters, so you may fix the file manually.

Do not switch ASCII/Binary without good reasons, or corruptions may easily arise. It is never a good idea to set a text file binary mode with CVS, as I think some CVS operations may fail with files that are marked as binary.

We build java program under windows and use different scripts to run this program. So our build contains .bat and .sh-files. Then this build is deployed under windows and unix. I cannot make 2 separate builds (for Unix/Windows).
So I need somehow modify this script to make it insensitive to CR charachters (the sript is below).

Code:

#!/bin/sh
export CLASSPATH=${JAVA_HOME}/jre/lib/rt.jar:${CLASSPATH}:.:../lib/mt2-delegate.jar:../lib/mt2-if.jar:../lib/mt2-ui.jar:../lib/foundation.jar:../lib/wlclient.jar:../lib/wljmsclient.jar:../lib/log4j.jar
if [ "$3" = "" ]; then
   ${JAVA_HOME}/bin/java com.datos.ui.client.MappingExporterClient $1 $2
else
   ${JAVA_HOME}/bin/java com.datos.ui.client.MappingExporterClient $1 $2 "$3"
fi

The error I've recieved:

Code:

$ ./MappingExporterClient.sh 
: bad interpreter: No such file or directory

The problem was in CR charachter in first string:

Code:

$ od -cx MappingExporterClient.sh | head -1
0000000   #   !   /   b   i   n   /   s   h  \r  \n   e   x   p   o   r

(there is no sh\r interpreter)

Now:

Code:

$ od -cx MappingExporterClient.sh | head -1
0000000   #   !   /   b   i   n   /   s   h  \n   e   x   p   o   r   t

But your shell script is only run on Linux and the .bat only on Windows. Am I right? If so, just check out the whole project on Linux then the EOL will be \n, and the shell script will work. Check out the project again on Windows, the EOL will be \r\n, and the .bat will work. This is the same set of sources and you just check out two times on two different platforms. I still don't understand why this cannot be done as I know many projects have mixed .sh and .bat using CVS in similar situations as you are in.

If the shell script checked out on Linux still has the \r, that means either
(1) the file has been set to binary mode (previously or currently) and later checked in from Windows with the EOL changed, probably silently by the editor;
(2) has otherwise been corrupted with spurious control characters.

Then you should fix by removing all the \r, set the file to ASCII, and commit it back to CVS to fix the problem. In most cases I still do not encourage switching to all Binary mode without careful checking, as the change may easily lead to more severe corruptions, rather than fixing anything.