From: Konstantin S. <st...@me...> - 2005-09-24 19:18:28
|
Hi, I have installed MinGW and MSYS on a Windows XP PC and compiled a C program with make and gcc under MSYS. In principal the executable runs fine, both under MSYS and under the Windows command prompt. However, the compiled C program needs to be given the path (directory) to a file, that will be opened during run time, as an environment variable (say, VARNAME). I figure that, even when using the Windows command line, I have to use slashes '/' instead of backslashes '\'. Thus, before starting the executable of the compiled C program, I need to do something like this: set VARNAME=/Programs/MyProg/helpdir This seems to be the case no matter if compilation was done with (a) make/gcc under MSYS or (b) mingw32-make/mingw32-gcc under MSYS or the Win command prompt - and principally it works fine. Now here is my question: how does one properly specify the drive name (e.g. C: or D:) with the path in the environment variable when using the compiled C program from the _Windows command prompt_? This becomes relevant if I want to start the program from a different drive. When using MSYS, the proper way would be VARNAME=/c/Programs/MyProg/helpdir but under the Windows command prompt set VARNAME=/c/Programs/MyProg/helpdir does not work, and neither does set VARNAME=C:/Programs/MyProg/helpdir Does anyone have an idea how to solve this? Thanks, Konstantin |
From: Tor L. <tm...@ik...> - 2005-09-24 20:50:58
|
Konstantin Strauch writes: > I figure that, even when using the Windows command line, I have to use > slashes '/' instead of backslashes '\'. Umm, why? > Thus, before starting the executable of the compiled C program, I > need to do something like this: > set VARNAME=/Programs/MyProg/helpdir set VARNAME=\Programs\MyProg\helpdir should work just as well > but under the Windows command prompt > set VARNAME=/c/Programs/MyProg/helpdir > does not work Well, it "does work" (in the sense that the environment variable VARNAME then has the value "/c/Programs/MyProg/helpdir"), but that of course is not what you want as that is not a Win32 file name for the file you are trying to use. > does not work, and neither does > set VARNAME=C:/Programs/MyProg/helpdir Why not? Either that or set VARNAME=C:\Programs\MyProg\helpdir should work fine. Look for yourself with the "set" command (without any arguments). There should be environment variables like ALLUSERSPROFILE=C:\Documents and Settings\All Users or ComSpec=C:\WINDOWS\system32\cmd.exe already in your environment. Adding your own VARNAME=C:\Programs\MyProg\helpdir is no different. --tml |
From: Konstantin S. <st...@me...> - 2005-09-25 10:44:45
|
On Sat, 24 Sep 2005, Tor Lillqvist wrote: > Konstantin Strauch writes: > > I figure that, even when using the Windows command line, I have to use > > slashes '/' instead of backslashes '\'. > > Umm, why? > > > Thus, before starting the executable of the compiled C program, I > > need to do something like this: > > set VARNAME=/Programs/MyProg/helpdir > > set VARNAME=\Programs\MyProg\helpdir > should work just as well No, it does not! > > but under the Windows command prompt > > set VARNAME=/c/Programs/MyProg/helpdir > > does not work > > Well, it "does work" (in the sense that the environment variable > VARNAME then has the value "/c/Programs/MyProg/helpdir"), but that of > course is not what you want as that is not a Win32 file name for the > file you are trying to use. > > > does not work, and neither does > > set VARNAME=C:/Programs/MyProg/helpdir > > Why not? Either that or > set VARNAME=C:\Programs\MyProg\helpdir > > should work fine. > > Look for yourself with the "set" command (without any > arguments). There should be environment variables like > > ALLUSERSPROFILE=C:\Documents and Settings\All Users > or > ComSpec=C:\WINDOWS\system32\cmd.exe > > already in your environment. Adding your own > VARNAME=C:\Programs\MyProg\helpdir is no different. Setting the Windows command environment variable with 'set' is indeed no problem. Also the environment variable can be read by the executable MinGW/MSYS compiled C program. The problem is that the path (given successfully to the executable program by the windows environment variable) cannot be accessed when given in the format C:\Programs\MyProg\helpdir or even just \Programs\MyProg\helpdir but rather must be given as /Programs/MyProg/helpdir that is, the executable obviously cannot use DOS path format but definitely needs the path to be given in Unix/MSYS format. Unfortunately, the problem is that now the drive cannot be changed, since /c/Programs/MyProg/helpdir definitely does not work. Does anyone have any further comments on how to solve this? Konstantin |
From: Leif W <war...@us...> - 2005-09-25 12:33:32
|
> From: "Konstantin Strauch" <st...@me...> > Sent: 2005 September 25 Sunday 06:48 > Setting the Windows command environment variable with 'set' is indeed > no > problem. Also the environment variable can be read by the executable > MinGW/MSYS compiled C program. The problem is that the path (given > successfully to the executable program by the windows environment > variable) cannot be accessed when given in the format Ok, I'm a relative novice, but I have managed to set an environment variable in a command prompt, and wrote a program to get the environment value, a path starting with C:, in both forward and backward slash formations, in both Command Prompt and MSYS (rxvt/bash), with versions compiled in both places, using either mingw32-gcc.exe or gcc.exe. In every combination, I am able to pass the path to fread and read the data just fine. So I think it maybe begs some more questions about your setup and what you're trying to do. Are there any "special" characters in the path name? I think getenv uses only ANSI but not sure. How are you getting a file handle, stream, pointer, or whatever the case may be? What function are you passing the variable to, if not fread or fwrite? What else are you trying to do with the file? Leif |
From: Daniel A. <dan...@gm...> - 2005-09-25 14:54:07
|
MjAwNS85LzI1LCBLb25zdGFudGluIFN0cmF1Y2ggPHN0cmF1Y2hAbWVkLnVuaS1tYXJidXJnLmRl PjoKPiBTZXR0aW5nIHRoZSBXaW5kb3dzIGNvbW1hbmQgZW52aXJvbm1lbnQgdmFyaWFibGUgd2l0 aCAnc2V0JyBpcyBpbmRlZWQgbm8KPiBwcm9ibGVtLiAgQWxzbyB0aGUgZW52aXJvbm1lbnQgdmFy aWFibGUgY2FuIGJlIHJlYWQgYnkgdGhlIGV4ZWN1dGFibGUKPiBNaW5HVy9NU1lTIGNvbXBpbGVk IEMgcHJvZ3JhbS4gIFRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIHBhdGggKGdpdmVuCj4gc3VjY2Vz c2Z1bGx5IHRvIHRoZSBleGVjdXRhYmxlIHByb2dyYW0gYnkgdGhlIHdpbmRvd3MgZW52aXJvbm1l bnQKPiB2YXJpYWJsZSkgY2Fubm90IGJlIGFjY2Vzc2VkIHdoZW4gZ2l2ZW4gaW4gdGhlIGZvcm1h dAo+Cj4gICBDOlxQcm9ncmFtc1xNeVByb2dcaGVscGRpcgo+Cj4gb3IgZXZlbiBqdXN0Cj4KPiAg IFxQcm9ncmFtc1xNeVByb2dcaGVscGRpcgo+Cj4gYnV0IHJhdGhlciBtdXN0IGJlIGdpdmVuIGFz Cj4KPiAgIC9Qcm9ncmFtcy9NeVByb2cvaGVscGRpcgo+Cj4gdGhhdCBpcywgdGhlIGV4ZWN1dGFi bGUgb2J2aW91c2x5IGNhbm5vdCB1c2UgRE9TIHBhdGggZm9ybWF0IGJ1dAo+IGRlZmluaXRlbHkg bmVlZHMgdGhlIHBhdGggdG8gYmUgZ2l2ZW4gaW4gVW5peC9NU1lTIGZvcm1hdC4KPiBVbmZvcnR1 bmF0ZWx5LCB0aGUgcHJvYmxlbSBpcyB0aGF0IG5vdyB0aGUgZHJpdmUgY2Fubm90IGJlIGNoYW5n ZWQsIHNpbmNlCj4KPiAgIC9jL1Byb2dyYW1zL015UHJvZy9oZWxwZGlyCj4KPiBkZWZpbml0ZWx5 IGRvZXMgbm90IHdvcmsuCj4KPiBEb2VzIGFueW9uZSBoYXZlIGFueSBmdXJ0aGVyIGNvbW1lbnRz IG9uIGhvdyB0byBzb2x2ZSB0aGlzPwoKWW91IGhhdmVuJ3Qgc2FpZCB3aGF0IHlvdSdyZSB0cnlp bmcgdG8gZG8gd2l0aCB0aGUgUEFUSCB2YWx1ZS4gUGVyaGFwcwp0aGF0IHdpbGwgZXhwbGFpbiB3 aHkgeW91J3JlIGhhdmluZyBwcm9ibGVtcy4K |
From: Duncan M. <mi...@mu...> - 2005-09-25 13:26:55
|
Konstantin Strauch wrote: > On Sat, 24 Sep 2005, Tor Lillqvist wrote: > > >>Konstantin Strauch writes: >> > I figure that, even when using the Windows command line, I have to use >> > slashes '/' instead of backslashes '\'. >> >>Umm, why? >> >> > Thus, before starting the executable of the compiled C program, I >> > need to do something like this: >> > set VARNAME=/Programs/MyProg/helpdir >> >>set VARNAME=\Programs\MyProg\helpdir >>should work just as well > > > No, it does not! > > >> > but under the Windows command prompt >> > set VARNAME=/c/Programs/MyProg/helpdir >> > does not work >> >>Well, it "does work" (in the sense that the environment variable >>VARNAME then has the value "/c/Programs/MyProg/helpdir"), but that of >>course is not what you want as that is not a Win32 file name for the >>file you are trying to use. >> >> > does not work, and neither does >> > set VARNAME=C:/Programs/MyProg/helpdir >> >>Why not? Either that or >>set VARNAME=C:\Programs\MyProg\helpdir >> >>should work fine. >> >>Look for yourself with the "set" command (without any >>arguments). There should be environment variables like >> >>ALLUSERSPROFILE=C:\Documents and Settings\All Users >>or >>ComSpec=C:\WINDOWS\system32\cmd.exe >> >>already in your environment. Adding your own >>VARNAME=C:\Programs\MyProg\helpdir is no different. > > > Setting the Windows command environment variable with 'set' is indeed no > problem. Also the environment variable can be read by the executable > MinGW/MSYS compiled C program. The problem is that the path (given > successfully to the executable program by the windows environment > variable) cannot be accessed when given in the format > > C:\Programs\MyProg\helpdir > > or even just > > \Programs\MyProg\helpdir > > but rather must be given as > > /Programs/MyProg/helpdir > > that is, the executable obviously cannot use DOS path format but > definitely needs the path to be given in Unix/MSYS format. > Unfortunately, the problem is that now the drive cannot be changed, since > > /c/Programs/MyProg/helpdir > > definitely does not work. > > Does anyone have any further comments on how to solve this? MinGW programs should be fine with pathnames specified in the Windows style c:\... or with forward slashes. If yours isn't, you're probably doing something unusual. Post the code you're using to get the environment variable and to open the file, and maybe someone can spot what it is. Duncan Murdoch |
From: amores p. <lif...@ho...> - 2005-09-25 14:27:39
|
>From: Duncan Murdoch >Reply-To: mailing list >To: mailing list >Subject: Re: [Mingw-users] change drive C: in path >Date: Sun, 25 Sep 2005 09:27:36 -0400 > >MinGW programs should be fine with pathnames specified in the Windows style >c:\... or with forward slashes. If yours isn't, you're probably doing >something unusual. Post the code you're using to get the environment >variable and to open the file, and maybe someone can spot what it is. > Is this because MinGW programs simply pass the path to C RTL functions such as fopen, which on MS-Windows is implemented in msvcrt.dll, which in fact requires MS-Windows style paths? |
From: Duncan M. <mi...@mu...> - 2005-09-25 14:53:27
|
amores perros wrote: > > >>From: Duncan Murdoch >>Reply-To: mailing list >>To: mailing list >>Subject: Re: [Mingw-users] change drive C: in path >>Date: Sun, 25 Sep 2005 09:27:36 -0400 >> >>MinGW programs should be fine with pathnames specified in the Windows style >>c:\... or with forward slashes. If yours isn't, you're probably doing >>something unusual. Post the code you're using to get the environment >>variable and to open the file, and maybe someone can spot what it is. >> > > > Is this because MinGW programs simply pass the path to C RTL > functions such as fopen, which on MS-Windows is implemented > in msvcrt.dll, which in fact requires MS-Windows style paths? Yes, though it's up to the programmer to decide to use fopen or some other way of opening a file. But that's the normal way to do things. Duncan Murdoch |
From: Greg C. <chi...@co...> - 2005-09-25 15:37:17
|
On 2005-9-25 14:27 UTC, amores perros wrote: > > Is this because MinGW programs simply pass the path to C RTL > functions such as fopen, which on MS-Windows is implemented > in msvcrt.dll, which in fact requires MS-Windows style paths? This works for me, even if I run it from a D: drive: #include <stdio.h> int main() { FILE* f = fopen("C:/msys/1.0/doc/msys/COPYING", "r"); if(0==f) { fputs("Cannot open file\n", stdout); fflush(stdout); return 1; } while(!feof(f)) fputc(fgetc(f), stdout); return 0; } |
From: amores p. <lif...@ho...> - 2005-09-25 17:28:24
|
>From: Greg Chicares >Reply-To: mailing list >To: mailing list >Subject: Re: [Mingw-users] change drive C: in path >Date: Sun, 25 Sep 2005 15:37:02 +0000 > >On 2005-9-25 14:27 UTC, amores perros wrote: > > > > Is this because MinGW programs simply pass the path to C RTL > > functions such as fopen, which on MS-Windows is implemented > > in msvcrt.dll, which in fact requires MS-Windows style paths? > >This works for me, even if I run it from a D: drive: > >#include <stdio.h> > >int main() >{ > FILE* f = fopen("C:/msys/1.0/doc/msys/COPYING", "r"); > if(0==f) > { > fputs("Cannot open file\n", stdout); > fflush(stdout); > return 1; > } > while(!feof(f)) > fputc(fgetc(f), stdout); > return 0; >} > See what I know :) I just ran almost the same thing using Microsoft Visual Studio, and it worked as well, so I must be wrong, and fopen in msvcrt must handle both types of slashes. #include <stdio.h> int main(int argc, char* argv[]) { FILE * f = fopen("F:/msys/doc/msys/COPYING", "r"); if(0==f) { fputs("Cannot open file\n", stdout); fflush(stdout); return 1; } while(!feof(f)) fputc(fgetc(f), stdout); fclose(f); return 0; } |
From: Duncan M. <mi...@mu...> - 2005-09-25 20:12:15
|
amores perros wrote: > > >>From: Greg Chicares >>Reply-To: mailing list >>To: mailing list >>Subject: Re: [Mingw-users] change drive C: in path >>Date: Sun, 25 Sep 2005 15:37:02 +0000 >> >>On 2005-9-25 14:27 UTC, amores perros wrote: >> >>>Is this because MinGW programs simply pass the path to C RTL >>>functions such as fopen, which on MS-Windows is implemented >>>in msvcrt.dll, which in fact requires MS-Windows style paths? >> >>This works for me, even if I run it from a D: drive: >> >>#include <stdio.h> >> >>int main() >>{ >> FILE* f = fopen("C:/msys/1.0/doc/msys/COPYING", "r"); >> if(0==f) >> { >> fputs("Cannot open file\n", stdout); >> fflush(stdout); >> return 1; >> } >> while(!feof(f)) >> fputc(fgetc(f), stdout); >> return 0; >>} >> > > > See what I know :) > > I just ran almost the same thing using Microsoft Visual Studio, and > it worked as well, so I must be wrong, and fopen in msvcrt must > handle both types of slashes. Most Win32 API functions handle both types of slashes. There are relatively few places that don't, but they include the common dialogs, so it appears that Windows requires backslashes, when mostly it doesn't. Duncan Murdoch |
From: Benjamin R. <b.r...@tu...> - 2005-09-25 17:30:07
|
Hi, "amores perros" writes: > Is this because MinGW programs simply pass the path to C RTL > functions such as fopen, which on MS-Windows is implemented in > msvcrt.dll, which in fact requires MS-Windows style paths? To clarify: fopen passes the path to Windows APIs. Windows APIs accept both forward slashes and backslashes, as the OS APIs have done since the introduction of directories into DOS some decades ago. It's not the OS API that has problems with forward slashes, it's just some tools that have been distributed with OSs forever, like COMMAND.COM and CMD.EXE. These tools treat "/" as an option character so they can't accept it in filenames. Unless you are calling one of these tools, you don't need to put backslashes into paths, if you don't really want to. benny |
From: Konstantin S. <st...@me...> - 2006-02-16 17:07:45
|
Dear all, My apologies for following up on this rather late. (My problem was that I had tried to pass a Windows path in an environment variable to a mingw32-gcc-compiled C program, but the format 'C:\dir\...', that is, including 'C:' and backslashes would not work). On Sun, 25 Sep 2005, Duncan Murdoch wrote: > Konstantin Strauch wrote: > > On Sat, 24 Sep 2005, Tor Lillqvist wrote: > > > > > > > Konstantin Strauch writes: > > > > I figure that, even when using the Windows command line, I have > > > > to use slashes '/' instead of backslashes '\'. > > > > > > Umm, why? > > > > > > > Thus, before starting the executable of the compiled C program, > > > > I > > > > need to do something like this: > > > > set VARNAME=/Programs/MyProg/helpdir > > > > > > set VARNAME=\Programs\MyProg\helpdir should work just as well > > > > > > No, it does not! > > > > > > > > but under the Windows command prompt > > > > set VARNAME=/c/Programs/MyProg/helpdir > > > > does not work > > > > > > Well, it "does work" (in the sense that the environment variable > > > VARNAME then has the value "/c/Programs/MyProg/helpdir"), but that of > > > course is not what you want as that is not a Win32 file name for the > > > file you are trying to use. > > > > > > > does not work, and neither does > > > > set VARNAME=C:/Programs/MyProg/helpdir > > > > > > Why not? Either that or > > > set VARNAME=C:\Programs\MyProg\helpdir > > > > > > should work fine. > > > > > > Look for yourself with the "set" command (without any > > > arguments). There should be environment variables like > > > > > > ALLUSERSPROFILE=C:\Documents and Settings\All Users > > > or > > > ComSpec=C:\WINDOWS\system32\cmd.exe > > > > > > already in your environment. Adding your own > > > VARNAME=C:\Programs\MyProg\helpdir is no different. > > > > > > Setting the Windows command environment variable with 'set' is indeed no > > problem. Also the environment variable can be read by the executable > > MinGW/MSYS compiled C program. The problem is that the path (given > > successfully to the executable program by the windows environment > > variable) cannot be accessed when given in the format > > > > C:\Programs\MyProg\helpdir > > > > or even just > > > > \Programs\MyProg\helpdir > > > > but rather must be given as > > > > /Programs/MyProg/helpdir > > > > that is, the executable obviously cannot use DOS path format but > > definitely needs the path to be given in Unix/MSYS format. > > Unfortunately, the problem is that now the drive cannot be changed, since > > > > /c/Programs/MyProg/helpdir > > > > definitely does not work. > > > > Does anyone have any further comments on how to solve this? > > MinGW programs should be fine with pathnames specified in the Windows style > c:\... or with forward slashes. If yours isn't, you're probably doing > something unusual. Post the code you're using to get the environment variable > and to open the file, and maybe someone can spot what it is. > > Duncan Murdoch I finally figured what the problem was - Duncan, you and the others who replied were right: the C program I was looking at had a routine to automatically remove the ':' and '\' after reading the string from the environment variable =8~) . After having changed this routine, path specification in the environment variable, and proper access of the path by the C program to which the variable is given, work perfectly fine, with 'C:' as well as forward and/or backward slashes. Thank you all for your help and comments. Konstantin |