Re: Error when script uses CRLF line endings w/ if stmt
On Thu, Feb 04, 2010 at 11:54:51PM -0600, Evan Driscoll wrote: Why not make Bash consider \r\n a legitimate line ending? What possible reason could there be for treating carriage return characters as it does now? Well, the most literal reason is that the shebang (#!/program) line will not work with a carriage return. This line is read as a comment by bash, but as a use this program directive by the underlying OS. The OS is going to try to run $'/program\r' and will not find it. Unless of course you made $'bash\r' a symlink to bash, and so on. Apart from that, there's no reason a Cygwin-style shell option couldn't be used on Unix. Other than, of course, the fact that it's a grossly bad habit to let yourself fall into; and the fact that no other shell would ever be able to read the script; and the 40 years of precedent for the current behavior
Re: Error when script uses CRLF line endings w/ if stmt
According to Jan Schampera on 2/4/2010 10:39 PM: drisc...@cs.wisc.edu schrieb: Some of the time, using CRLF line endings cause syntax errors in Bash scripts (unexpected end of file). This problem shows up on Bash 4.1 on Linux, Bash 3.2 on Linux, and Bash 3.2 on Cygwin (where I first noticed it). Normal. Though I don't know how to treat the Cygwin case, since the underlying platform uses \r\n anyways. Cygwin specifically recommends AGAINST using \r\n. The goal of cygwin is to be a Linux emulation, and Linux does not use \r, so cygwin bash will treat \r in the same manner as Linux _unless_ you turn on the cygwin-specific 'shopt -r igncr' option which I wrote as part of maintaining bash for cygwin. That option is your contract stating that _you_ are aware your script is non-portable, and therefore you are no longer bound by the standards and cygwin bash can then ignore \r on your behalf. It might be nice if upstream bash accepted a patch to make igncr available to all platforms, not just cygwin. Is there any interest? If so, I can port my cygwin-specific bash patches and post them on this list. If not, then those patches will remain cygwin-specific. -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net signature.asc Description: OpenPGP digital signature
Re: Error when script uses CRLF line endings w/ if stmt
Jan Schampera a écrit : Moreover, POSIX talks about newline here, which is a \n. Though I didn't read through all the rationales, I just took a quick look, maybe it's not limited to \n. '\n' can be two characters outside of POSIX, see man fopen. - It would feel good to use CRLF to bash Windows once again. Isn't ridiculous and painful to have two characters for only one thing? Unfortunately CRLF pre-dates Windows by decades. You can argue it is older and more standard than LF. For instance many internet protocols use it. Now I wonder how come a third convention emerged. Just to think different?
Re: Error when script uses CRLF line endings w/ if stmt
[This is an combination of a couple of replies to the various emails since last evening.] Pierre Gaston wrote: cygwin's bash is patched and provides a special igncr shopt option. try shopt -s igncr And with the ability to pass options to Bash on invocation with -o, this provides a better solution to my problem then what had come before. (I was already doing 'bash script' and not using a #! or similar, so changing to 'bash -o igncr script' is no problem.) Thanks very much. Jan Schampera wrote: Personally, I have no problem with the \n-only behaviour (which - in fact - is not Bash specific. Most programs that use text files have trouble when you change to the other world) I'm not totally sure this is true. Sure, a lot of programs have problems, but a lot don't. Emacs can use either line ending standard; so can Vi (I think), and so can Visual Studio. So can GCC and MSVC's 'cl'. So can Antlr. So can Python. Even's CMD.EXE's 'type' builtin displays LF-only files correctly. Then, many programs don't handle them per se, but *not* handling them doesn't cause much problem. grep, cat, and echo probably fall in this category. Really the ones that *can't* tend, in my experience, to be programs based off of old-school Unix programs, like Flex and Bison (IIRC) and Bash. (The main exception to this rule is Notepad.) IMO these programs are universally buggy for this reason. Greg Wooledge wrote: Well, the most literal reason is that the shebang (#!/program) line will not work with a carriage return. This line is read as a comment by bash, but as a use this program directive by the underlying OS. The OS is going to try to run $'/program\r' and will not find it. Unless of course you made $'bash\r' a symlink to bash, and so on. Like the previous response, my personal view is that's a bug in the underlying OS that should be fixed, not used as an excuse for bugs in Bash. :-) Evan
Re: Error when script uses CRLF line endings w/ if stmt
Evan Driscoll schrieb: Then, many programs don't handle them per se, but *not* handling them doesn't cause much problem. grep, cat, and echo probably fall in this category. Bash doesn't handle it. It's a character like 'A' or 'B'. It causes problems :) J.
Re: Error when script uses CRLF line endings w/ if stmt
Jan Schampera jan.schamp...@web.de writes: It's a character like 'A' or 'B'. 'A' and 'B' are letters, $'\r' is whitespace. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: Error when script uses CRLF line endings w/ if stmt
Andreas Schwab schrieb: It's a character like 'A' or 'B'. 'A' and 'B' are letters, $'\r' is whitespace. Yes... :)
command not put into history if it starts with space
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' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -DRECYCLES_PIDS -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables uname output: Linux ram.opd.local 2.6.31.12-174.2.3.fc12.i686 #1 SMP Mon Jan 18 20:22:46 UTC 2010 i686 athlon i386 GNU/Linux Machine Type: i386-redhat-linux-gnu Bash Version: 4.0 Patch Level: 35 Release Status: release Description: When using the bash shell in an xterm or rxvt terminals at least, commands executed which start with a space, eg ls are not added to the command line history and so are not accessible by ctrl-p. Repeat-By: Type any command prefixed by one or more spaces. Press return. Press Ctrl-p or type history | tail. Observe that last command starting with space is not in present in the command history. Thanks, Paul Stansell
Re: command not put into history if it starts with space
On Friday 05 February 2010 05:07:46 Paul Stansell wrote: When using the bash shell in an xterm or rxvt terminals at least, commands executed which start with a space, eg ls are not added to the command line history and so are not accessible by ctrl-p. this is by design -mike signature.asc Description: This is a digitally signed message part.
Re: command not put into history if it starts with space
On Feb 5, 4:07 am, Paul Stansell paulstans...@googlemail.com wrote: 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' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -DRECYCLES_PIDS -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables uname output: Linux ram.opd.local 2.6.31.12-174.2.3.fc12.i686 #1 SMP Mon Jan 18 20:22:46 UTC 2010 i686 athlon i386 GNU/Linux Machine Type: i386-redhat-linux-gnu Bash Version: 4.0 Patch Level: 35 Release Status: release Description: When using the bash shell in an xterm or rxvt terminals at least, commands executed which start with a space, eg ls are not added to the command line history and so are not accessible by ctrl-p. Repeat-By: Type any command prefixed by one or more spaces. Press return. Press Ctrl-p or type history | tail. Observe that last command starting with space is not in present in the command history. Thanks, Paul Stansell From the Bash man page: HISTCONTROL A colon-separated list of values controlling how commands are saved on the history list. If the list of values includes ignorespace, lines which begin with a space character are not saved in the history list.
