On Thu, Dec 24, 2009 at 10:19 PM, David Arnstein wrote:
> I have a bash shell script named xplo that worked as desired under
> cygwin 1.5. It fails under cygwin 1.7. Specifically, the shell expands
> the expression
> $1
> in a way that I simply cannot understand. This expression expanded to
> the first shell script argument in cygwin 1.5. Not any more.
>
> Here is the script xplo in its entirety:
> #!/bin/bash
> if [ $# -gt 1 ]
> then
> echo "Usage: xplo path-or-file"
> exit 1
> else
> set EXPLOR='/cygdrive/c/windows/explorer.exe'
> if [ $# -eq 0 ]
> then
> cygstart ${EXPLOR} /e,.
> elif [ -f "$1" ]
> then
> cygstart ${EXPLOR} /e,/select,`cygpath -w "$1"`
> else
> cygstart ${EXPLOR} /e,`cygpath -w "$1"`
> fi
> fi
>
> I cd to a directory that contains an ordinary file named wongo, as
> well as the shell script xplo. I execute the command
> bash -x ./xplo wongo
>
> I expect to get an instance of Windows Explorer, with folders showing,
> and the file wongo selected (highlighted). This does not occur. The
> text output from the above bash -x looks like this:
> + '[' 1 -gt 1 ']'
> + set EXPLOR=/cygdrive/c/windows/explorer.exe
> + '[' 1 -eq 0 ']'
> + '[' -f EXPLOR=/cygdrive/c/windows/explorer.exe ']'
> ++ cygpath -w EXPLOR=/cygdrive/c/windows/explorer.exe
> + cygstart '/e,EXPLOR=\cygdrive\c\windows\explorer.exe'
> Unable to start 'E:\cygwin\e,EXPLOR=\cygdrive\c\windows\explorer.exe':
> The specified file was not found.
>
> I have attached the output from cygcheck -s -v -r. Thanks for any
> advice.
>
The problem isn't bash nor how $1 is expanded. In fact $1 never gets
used in your test case when no parameters are given. Take the
following test case which does the essence of your script without the
use of cygpath or cygcheck (those are not the issue here).
#!/bin/bash
set VAR="outside"
echo ${VAR}
if [ true ]
then
set VAR2="inside"
echo ${VAR}
echo ${VAR2}
fi
echo ${VAR2}
If you are to run the above script the output is 4 blank lines. The
set command works differently within shell scripts than it does
outside of them. Inside shell scripts you either use export or you
don't use either one. So either replacing set with export or removing
it will fix the script completely for you. I can't test it on debian
with that change because your script uses cygcheck and cygpath but I
did test it locally and once that change was made it worked just fine.
The main difference between using export and not using it is that
export allows child processes to use the variables as well. If you
don't use it then child processes won't be able to access them. This
doesn't change parent processes at all.
*After checking man pages*
Ok. I just checked the man pages again and this is a "by design"
issue in how you are using set. Per the following quote for set in the
bash man page.
"The remaining N arguments are positional parameters and are assigned,
in order, to $1, $2, ... $N. The special parameter # is set to N."
Source: http://www.gnu.org/software/bash/manual/bashref.html#The-Set-Builtin
(yes... this is quoted from online docs -- cygwin has a similar quote)
This test case has the same behavior on debian and cygwin so if it is
a bug then it is in bash itself and not a cygwin issue at all. I
highly doubt it is a bug though based on the above text.
#!/bin/bash
set PARM1=one PARM2=two PARM3=three
echo '$PARM1' is $PARM1
echo '$PARM2' is $PARM2
echo '$PARM3' is $PARM3
echo '$1' is $1
echo '$2' is $2
echo '$3' is $3
It should output something like the following and yes that is correct.
You may be able to understand your script behavior better now.
$PARM1 is
$PARM2 is
$PARM3 is
$1 is PARM1=one
$2 is PARM2=two
$3 is PARM3=three
Robert Pendell
shi...@elite-systems.org
CAcert Assurer
"A perfect world is one of chaos."
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
