From: George V. R. <ge...@re...> - 2009-10-30 17:55:06
|
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 ge...@re... Twitter: @georgevreilly http://www.georgevreilly.com/blog http://blogs.cozi.com/tech Approve Referendum 71 to keep the Domestic Partnership Law: http://approve71.org |
From: Keith M. <kei...@us...> - 2009-10-30 21:53:59
|
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. |
From: Earnie B. <ea...@us...> - 2009-11-02 14:31:19
|
Quoting Keith Marshall <kei...@us...>: > 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 |
From: Keith M. <kei...@us...> - 2009-11-02 21:32:59
|
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. |
From: Earnie B. <ea...@us...> - 2009-11-03 03:51:25
|
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 |
From: Keith M. <kei...@us...> - 2009-11-03 18:11:27
|
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. |