RE: RE: Bug with backticks behaviour in mSYS?

Mark Cave-Ayland wrote, quoting Luke Dunstan:
>> The "bash" command you are using is not part of MSYS, so it is
>> probably Cygwin bash or something.
>
> The machine I am using MingW/MSys with is 100% cygwin clean, so it
> must be something that comes with MingW/MSys/Msys-DTK... I also tried
> upgrading to the latest candidate of bash from the releases page to
> see what effect that would also have.

Mark,

We don't distribute bash with any standard MinGW/MSYS/msysDTK package;
(or rather we *do*, but we call it sh.exe, so it runs in its POSIX
compatibility mode).  You *must* have acquired your bash from some
other source, unless you are referring to the bash-2.05b-MSYS.tar.bz2
appearing in the MSYS snapshot section of the download page -- and
you should note that snapshots may not be stable.

IIRC, this snapshot was provided to kludge any environment variable
named `prefix' to represent a native Win32 path, even if specified
with MSYS semantics;  this was to co-operate more effectively with
autoconf, but it has since been established that there is a *much*
more effective method of achieving the desired goal.  In any case,
that snapshot of bash was intended to be installed as /bin/sh.exe

Using the standard MSYS sh.exe, from MSYS-1.0.10.exe, and also using
"correct" portable command quoting, I can't reproduce the failure
of your original simple test case:

  <file name="test.c">
  #include <stdio.h>

  main()
  {
    printf("this is a test string\n");
  }
  </file>

  <commands>
  gcc -o test test.c
  sh -c 'echo `./test`" -lpd" > x.x'
  od -cb x.x
  </commands>

  <output>
  0000000   t   h   i   s       i   s       a       t   e   s   t       s
          164 150 151 163 040 151 163 040 141 040 164 145 163 164 040 163
  0000020   t   r   i   n   g       -   l   p   q  \n
          164 162 151 156 147 040 055 154 160 161 012
  0000033
  </output>

(This output is reproduced identically, if I rename sh.exe as bash.exe,
and adjust the appropriate command accordingly, so even without the
POSIX compatibility mode turned on, I can't reproduce the failure).

You should avoid using backtick substitution within quoted command
arguments;  it isn't *generally* a problem with bash, but some shells
-- notably some of the BSD shells -- mishandle them.  And, in this case,
I *can* identically reproduce your failure when I use improper quoting,
regardless of whether the shell is called sh.exe or bash.exe, i.e. in:

  <commands>
  sh -c 'echo "`./test` -lpd" > x.x'
  od -cb x.x
  </commands>

the backticked command is improperly quoted, and fails *exactly* as you
have described:

  <output>
  0000000   t   h   i   s       i   s       a       t   e   s   t       s
          164 150 151 163 040 151 163 040 141 040 164 145 163 164 040 163
  0000020   t   r   i   n   g 001       -   l   p   q  \n
          164 162 151 156 147 001 040 055 154 160 161 012
  0000034
  </output>

Regards,
Keith.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click