This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Bash and CR/LF line-endings


I've been wondering during this whole event why one of the original proposal
was not used?

As far as I can see, the main problem with both latest bash revisions is that
the solution to the cr/lf problem demands that users be either pro-active or
gifted guessers. Both the d2u and the shopt solutions requires the user to
understand that bash trashing about with incomprehensible  errors is due to
bad line endings. This is compounded by the fact that those scripts may be
lying in the middle of custom toolchains developed internally and used by
non-programming end-users. Also, due to the previous more forgiving behavior
and the nature of working in a Windows environment, the creeping of cr/lf is
inevitable for some users. Add to this that both current solutions requires
the modification of the scripts, Isn't it expected that it raised many red
flags? Not counting those who are not inclined to read announcement and
development mailing list and just install product and have it work
out-of-the-box... I can see future new users figuratively throwing back cygwin
in the trash-bin because it can't even run a simple shell script correctly.

So why was the solution of using the 1st line of the script (which, it was
claimed, is read anyway for other purposes) and base the seeking behavior on
the detection of cr/lf there, rejected?

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]