On 03/26/2015 09:37 AM, smith@cygwin.akamoz.jp wrote:
> Dear Cygwin developers:
> 
>  It seems that bash-4.3.33(1) handles CR+LF end-of-line in 
> the shell-script incorrectly, all of the following conditions are met:
> 
> a. the shell-script file is on TEXT-MOUNTED directory,

Thanks for the report.  I'll have to test this and see if I can spot
what is going wrong (I don't normally try text-mount directories).

> b. end-of-line style of the file is CR+LF, and

Are you absolutely sure that you don't have excess CR in your file?
text mounts only treats the CRLF as a single newline, but does not eat
lone CR elsewhere in the file.

> c. the command in the file includes & (exec-background),
>    $( ), or `` (command substitutions)
> 
> It works:
> d. it is on the binary-mounted directory, and with igncr shell-option,

Does igncr make a difference in the text mount directory situation?

> e. end-of-line style is LF, or

Yeah, if you don't have CR, it doesn't matter whether you are text mount
or binary mount.  It is only CR that chokes bash, and only if you don't
do something like igncr or text mount to hide it.

> f. condition c is not met. It seems that &&, | and || work fine,
>    although I didn't try all of the metachacters and control-constructs.

Weird.

> 
>  I found it on x86 Cygwin with 64bit Windows environment first,
> the same behavior is observed on 32bit Windows environment also.
> I've not tried yet on x64 Cygwin with 64bit Windows environment.
> 
> shell-script to test: (WITH CR+LF END-OF-LINE STYLE)
> --- 8< ------ 8< ------ 8< ------ 8< ------ 8< ---
> #!/bin/bash

Please ATTACH the script as a binary file, rather than pasting it inline
in your email; or at a bare minimum, show 'od -tx1z yourscript' to make
it obvious the exact byte patterns your file contains.  Inline text in
email does NOT make it obvious what line endings you are intending.
> 
> example of execution, on bash-4.3.33(1):
> --- 8< ------ 8< ------ 8< ------ 8< ------ 8< ---
> $ LANG=C ./test.sh
> hoge
> ./test.sh: line 3: fuga: command not found
> ./test.sh: line 4: piyo: command not found
> ./test.sh: line 5: o: command not found
> ./test.sh: line 6: ho: command not found
> ./test.sh: line 7: cho: command not found
> --- 8< ------ 8< ------ 8< ------ 8< ------ 8< ---
> 
> Maybe commands are read from the positions one-byte shifted, line-by-line.

Use of & or $() causes bash to fork; maybe the forked child is
attempting to lseek back to the position last visited by the parent
based on characters read, but failing to account for the fact that lseek
on a text-mount file causes issues because characters read is different
than file offset advanced?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org