BASH should not choke on scripts with DOS newlines.

[cwsulliv]

Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' 
-DCONF_VENDOR='redhat' -DSHELL -DHAVE_CONFIG_H  -D_GNU_SOURCE 
-D_FILE_OFFSET_BITS=64  -I.  -I. -I./include -I./lib -I/usr/include -O2 
-march=i386 -mcpu=i686
uname output: Linux gso31-125-110.triad.rr.com 2.4.9-31 #1 Tue Feb 26 07:11:02 
EST 2002 i686 unknown
Machine Type: i386-redhat-linux-gnu

Bash Version: 2.04
Patch Level: 21
Release Status: release

Description:
Bash will currently fail to execute a script if (at least) the
first line of the script is terminated with the DOS newline
(\r\n) sequence, since the name of the shell command appears
to be "bash\r", which doesn't normally exist.

Although this is technically speaking the intended behavior,
I propose that bash should instead consider either \n or
\r\n equally acceptable as end-of-line terminators in scripts.

Rationale for proposed change:
1. Files are nowadays frequently passed back and forth between
DOS/Windows and Linux systems, and it is easy for a text file
like a bash script to be inadvertantly written with DOS end-of-line
terminators.  And I understand there is a version of bash intended
for use under a Windows 32 bit OS.
2. The end-of-line terminator used is not easily discernable in
many editors.
3. It can be extremely frustrating for the unwary to have a script
fail to execute for this reason, and one more thing for the Linux
newbie to worry about besides permission and path when attempting
to execute a script.
4. Many other Linux programs handle both DOS and Linux end-of-line 
terminations equally well.

Regards,
Charles Sullivan