RE: 1.5.9: tcsh 6.12.00 parses scripts wrong with DOS line endings

[David Mastronarde <mast at bio3d dot Colorado dot EDU>]

On Sat, 10 Apr 2004, Ross Boulet wrote:

> > -----Original Message-----
> > From: cygwin-owner On Behalf Of David Mastronarde
> > 
> > When csh scripts have DOS line endings, tcsh 6.12.00 
> > sometimes parses them 
> > incorrectly.  This seems to happen with scripts that have 
> > while loops, 
> > once the scripts get big enough.  Converting the script to unix line 
> > endings fixes the problem.
> > 
> > The attached script, cshbug, is about as small as it can be 
> > to show the 
> > problem.  It needs to be run with a valid argument, in my case
> > cshbug -inst /usr/local/IMOD
> > 
> > The standard error output is:
> > =: Command not found.
> > 
> > The attached file bugout2 is the output from
> > csh -v cshbug -inst /usr/local/IMOD
> > 
> > After the first trip through the while loop, it jumps back up to the 
> > middle of a line before the loop:
> > = "unsigned int"
> > 
> > If the variable setting section of the script is made 
> > smaller, such as 
> > by removing the first 13 lines, the problem goes away.
> > 
> > This problem has been present for the past year at least.
> > 
> > David Mastronarde
> > Boulder Laboratory for 3-D Electron Microscopy of Cells
> > 
> 
> FWIW, looking at your cshbug.txt file, I see that the line endings are
> unusual.  A normal DOS line ending is a <CR><LF> combination.  Your file
> seems to have an extra <CR> at the end of each line.  Each line ends with
> <CR><CR><LF>.  My guess is when tcsh is processing the script, it does not
> count the extra <CR> characters, so when it loops, its offset into the
> script is off by a number of characters equivalent to the number of extra
> <CR>s.  In other words, the while statement in the script is on line 101.
> When it loops, tcsh is jumping to a location in the file calculated by
> assuming the size of the lines plus a two character line ending, not three.
> Therefore, the jump location is off by the number of bytes (101) its trying
> to get to.
> 
> The script is 190 lines long. If you run dos2unix on the file, the resulting
> file is 380 bytes smaller, having dropped two <CR> per line.  Running
> unix2dos on the result increases the file size by only 190 (one <CR> per
> line).  I'd be curious whether this resulting file with "normal" DOS line
> endings works correctly for you.
> 
> I don't know if tcsh should handle the extra <CR>'s or not.  But perhaps my
> observation will at least narrow down where to look.
> 
> Ross
> 
> 

When I do od -c, I see that the file has normal DOS endings both on the 
Windows system on which I tested it and on the Linux system from which I 
sent the mail attachment.  The extra <CR> must have been added on one end 
or the other of the mail process, so I am attaching a tar of the file to 
preserve the line endings.

My scripts are being checked out from a CVS repository on a Unix 
system where they have Unix line endings.  CVS converts them to <CR><LF>
upon checkout.

I think it is probably the case that tcsh is having trouble counting
characters, as you suggest.  I recall seeing something in the
documentation about potential problems with ftell and fseek for text
files, so maybe this is the source of the problem.

David

Attachment: cshbug.tar
Description: Unix tar archive

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/