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
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/
