Mail Archives: djgpp-workers/1999/01/26/09:46:51
>
> On Mon, 25 Jan 1999, Mark E. wrote:
>
> > This is to (hopefully) prevent mixed EOL styles that confuse Bash with
> > libtool, etc. generated files.
>
> Isn't it a better idea to fix whatever reason causes Bash to become
> confused with mixed EOL format? It's usually best to solve the bug at the
> place where it happens, instead of looking for ways of working around it.
True enough, but the hack works for now.
>
> Can you describe why does Bash barf on mixed DOS/Unix files?
The problem arises in input.c. The function fill_buffer detects whether
any number of CRs were skipped over in the call to read() that it does.
Later in check_bash_input, it's neccessary to sync up the file descriptor
with what hasn't been read from the data buffer. This is done by a call
to sync_buffered_stream_crlf.
The problem arises because this function assumed that when the
'CRs were detected' flag is set, that every LF had a CR that wasn't
placed in the buffer filled by read(). In mixed style files, this assumption
is wrong and in this case results in the file pointer pointing to the
wrong place. This leads to parse errors like what you see with libtool
generated files.
Some possible solutions I'm thinking over:
1) Add even more logic to sync_buffered_stream_crlf that would add
after the two lseek() calls alread there a read() call and compare the
number of bytes it puts into the buffer with the number expected. Any
difference is the result of lone LFs. Then one more lseek to get the file
pointer right going back.
2) Have files handled by input.c be read in binary mode, and have any
CRs read in be ignored. Then all the additional logic above doesn't
need to be added and the current EOL logic can be removed.
#2 seems like a better solution to me, so that will be one I try first.
Mark
---
Mark Elbrecht snowball3 AT usa DOT net
http://members.xoom.com/snowball3/
- Raw text -