msysGit bash and PROGRAMFILES(X86) environment variable on Win64

[George V. Reilly]

I'm using the version of bash that comes with msysGit on a Win64 Windows 7 RC machine. I'm trying to test the value of the insanely named PROGRAMFILES(X86) environment variable, but I can't figure out how to check its value. Every way of quoting it that I've tried has failed, backslashes, double quotes, braces, ....

$ env | grep PROGRAM

PROGRAMW6432=C:\Program Files

COMMONPROGRAMW6432=C:\Program Files\Common Files

PROGRAMDATA=C:\ProgramData

COMMONPROGRAMFILES(X86)=C:\Program Files (x86)\Common Files

COMMONPROGRAMFILES=C:\Program Files (x86)\Common Files

PROGRAMFILES=C:\Program Files (x86)

PROGRAMFILES(X86)=C:\Program Files (x86)

Actually, what I'm really trying to do is to port the following batchfile to bash. See http://weblogs.asp.net/george_v_reilly/archive/2009/09/11/launching-32-bit-applications-from-batchfiles-on-win64.aspx for background.

@setlocal

@set _pf=%ProgramFiles%

@if not "[%ProgramFiles(x86)%]"=="[]" set _pf=%ProgramFiles(x86)%

@start "" /b "%_pf%\SourceGear\DiffMerge\DiffMerge.exe" %*

Thanks

--
/George V. Reilly  [hidden email]  Twitter: @georgevreilly
http://www.georgevreilly.com/blog  http://blogs.cozi.com/tech
Approve Referendum 71 to keep the Domestic Partnership Law: http://approve71.org

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Keith Marshall]

On Friday 30 October 2009 17:54:53 George V. Reilly wrote:
> I'm trying to test the value of the insanely named
> PROGRAMFILES(X86) environment variable

Insanely named indeed; I don't know of any *nix shell which will
accept parentheses as legitimate characters in variable names!  You
could try something like:

  PROGRAMFILES_X86=`env | sed -n s,'^PROGRAMFILES(X86)=',,g`

and test $PROGRAMFILES_X86 instead.

--

HTH,
Keith.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Earnie Boyd]

Quoting Keith Marshall <[hidden email]>:

> On Friday 30 October 2009 17:54:53 George V. Reilly wrote:
>> I'm trying to test the value of the insanely named
>> PROGRAMFILES(X86) environment variable
>
> Insanely named indeed; I don't know of any *nix shell which will
> accept parentheses as legitimate characters in variable names!  You
> could try something like:
>
>   PROGRAMFILES_X86=`env | sed -n s,'^PROGRAMFILES(X86)=',,g`
>
> and test $PROGRAMFILES_X86 instead.
>

We could standardize on a common set of these and propagate to the  
windows tasks in the spawn functions.  Some windows environment  
variables are already being modified.

--
Earnie




------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-users mailing list
[hidden email]

A: Yes.
> Q: Is it really?
>> A: Because the logical conversation flow is disrupted.
>>> Q: Why does MinGW object to top posting?
(abstracted from Larry Hall signature)

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Keith Marshall]

On Monday 02 November 2009 14:31:07 Earnie Boyd wrote, quoting me:

> > On Friday 30 October 2009 17:54:53 George V. Reilly wrote:
> >> I'm trying to test the value of the insanely named
> >> PROGRAMFILES(X86) environment variable
> >
> > Insanely named indeed; I don't know of any *nix shell which will
> > accept parentheses as legitimate characters in variable names!
> >  You could try something like:
> >
> >   PROGRAMFILES_X86=`env | sed -n s,'^PROGRAMFILES(X86)=',,g`
> >
> > and test $PROGRAMFILES_X86 instead.
>
> We could standardize on a common set of these and propagate to the
> windows tasks in the spawn functions.  Some windows environment
> variables are already being modified.

In some future, yet to be released, version of MSYS?  I guess we
could do that, but who would define the standard set, and who will
implement it?  Perhaps it could be made end-user configurable?  
Ultimately, it will be Cesar's decision.

However, even if we do implement such a feature, it will not solve
George's problem, (as I understand it); rather, it will solve the
complementary problem.  George's problem arises from a malformed
environment variable name, inherited *by* MSYS *from* Windows, and
incapable of interpretation in MSYS shell scripts, as a result of
the invalid characters it contains.  Your proposal mangles valid
MSYS variables to alternatives, (possibly invalid in MSYS), for
passing back to native Windows; the problem at hand requires the
opposite, i.e. transformation of the invalid Windows form to a valid
MSYS form, on inheritance of the malformed variable at MSYS start
up, from the invoking native Windows session.  That transformation
can be achieved, in current MSYS without any modification, by use of
sed filters such as I have suggested[*], as required by the user.

[*] corrected from my original reply:

  PROGRAMFILES_X86=`env | sed -n s,'^PROGRAMFILES(X86)=',,p`

(note `p' flag, not `g', following the sed substitution command).

--

Regards,
Keith.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-users mailing list
[hidden email]

A: Yes.
> Q: Is it really?
>> A: Because the logical conversation flow is disrupted.
>>> Q: Why does MinGW object to top posting?
(abstracted from Larry Hall signature)

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Earnie Boyd]

Quoting Keith Marshall:

> On Monday 02 November 2009 14:31:07 Earnie Boyd wrote, quoting me:
>> > On Friday 30 October 2009 17:54:53 George V. Reilly wrote:
>> >> I'm trying to test the value of the insanely named
>> >> PROGRAMFILES(X86) environment variable
>> >
>> > Insanely named indeed; I don't know of any *nix shell which will
>> > accept parentheses as legitimate characters in variable names!
>> >  You could try something like:
>> >
>> >   PROGRAMFILES_X86=`env | sed -n s,'^PROGRAMFILES(X86)=',,g`
>> >
>> > and test $PROGRAMFILES_X86 instead.
>>
>> We could standardize on a common set of these and propagate to the
>> windows tasks in the spawn functions.  Some windows environment
>> variables are already being modified.
>
> In some future, yet to be released, version of MSYS?  I guess we
> could do that, but who would define the standard set, and who will
> implement it?  Perhaps it could be made end-user configurable?
> Ultimately, it will be Cesar's decision.
>

Yes, that is what I meant and agree.

> However, even if we do implement such a feature, it will not solve
> George's problem, (as I understand it); rather, it will solve the
> complementary problem.  George's problem arises from a malformed
> environment variable name, inherited *by* MSYS *from* Windows, and
> incapable of interpretation in MSYS shell scripts, as a result of
> the invalid characters it contains.  Your proposal mangles valid
> MSYS variables to alternatives, (possibly invalid in MSYS), for
> passing back to native Windows; the problem at hand requires the
> opposite, i.e. transformation of the invalid Windows form to a valid
> MSYS form, on inheritance of the malformed variable at MSYS start
> up, from the invoking native Windows session.  That transformation
> can be achieved, in current MSYS without any modification, by use of
> sed filters such as I have suggested[*], as required by the user.
>

Well, the complement would also be done.  That is what happens with  
such things as PATH, although PATH's value is modified and not the  
variable name.  So PROGRAMFILES_X86 would become PROGRAMFILES(X86) to  
windows processes and PROGRAMFILES(X86) would become PROGRAMFILES_X86  
during the init phase of the dll.

--
Earnie



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-users mailing list
[hidden email]

A: Yes.
> Q: Is it really?
>> A: Because the logical conversation flow is disrupted.
>>> Q: Why does MinGW object to top posting?
(abstracted from Larry Hall signature)

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

[Keith Marshall]

On Tuesday 03 November 2009 03:51:12 Earnie Boyd wrote:
> Well, the complement would also be done.  That is what happens
> with such things as PATH, although PATH's value is modified and
> not the variable name.  So PROGRAMFILES_X86 would become
> PROGRAMFILES(X86) to windows processes and PROGRAMFILES(X86) would
> become PROGRAMFILES_X86 during the init phase of the dll.

I don't dispute that this could be a useful feature; we should
certainly give consideration to implementing it.  My point was that
the aspect of it that you described is difficult, if not impossible,
to work around today, but isn't required to solve the OP's immediate
problem; a work around for the complementary issue may be relatively
easier to implement, should solve the OP's immediate problem, and is
possible today, (e.g. coded in /etc/profile for automatic set up at
MSYS login, or coded by the OP at point of use).

Obviously, a formal implementation should address both aspects of
the issue, as an integrated solution.

--

Regards,
Keith.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-users mailing list
[hidden email]

A: Yes.
> Q: Is it really?
>> A: Because the logical conversation flow is disrupted.
>>> Q: Why does MinGW object to top posting?
(abstracted from Larry Hall signature)

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users