what is going on here with the PATH?

[taripo]

I do not understand this

I have two gcc.exe files they are both different.

I guess i'll try to explain what I might expect.. though what I expect is all wrong and then perhaps those here can enlighten me as to why this is happening

Code: Select all

C:\MinGW\bin>set path=.;c:\windows\system32;C:\Perl64\site\bin

C:\MinGW\bin>gcc file6.c

C:\MinGW\bin>.\gcc file6.c

C:\MinGW\bin>set path=c:\windows\system32;C:\Perl64\site\bin

C:\MinGW\bin>gcc file6.c
gcc: error: CreateProcess: No such file or directory

C:\MinGW\bin>.\gcc file6.c

C:\MinGW\bin>

Looking at the above, I do not understand why there should be a difference between gcc and .\gcc

I thought the current directory is in the path by default.. for example if I do set path=, and then do gcc<ENTER> then ir runs gcc (and with no error from gcc). The fact that it runs gcc at all, when I have set path=, tells me that dot is in the path by default.. So then why should I get a difference from gcc between doing .\gcc and gcc as I see above?!

Code: Select all

C:\MinGW\bin>where gcc
C:\MinGW\bin\gcc.exe
C:\Perl64\site\bin\gcc.exe

I guess that where command is telling me that the MinGW one, the one in the current directory, will execute first.

Code: Select all

C:\MinGW\bin>path
PATH=c:\windows\system32;C:\Perl64\site\bin

C:\MinGW\bin>set path=.;c:\windows\system32;C:\Perl64\site\bin

C:\MinGW\bin>where gcc
C:\MinGW\bin\gcc.exe
C:\Perl64\site\bin\gcc.exe

C:\MinGW\bin>

And the Ming gcc will execute first even when it's not in the path, as long as I am in c:\MinGW

Code: Select all

C:\MinGW\bin>set path=c:\windows\system32;C:\Perl64\site\bin

C:\MinGW\bin>C:\Perl64\site\bin\gcc file6.c

C:\MinGW\bin>.\gcc file6.c

C:\MinGW\bin>gcc file6.c
gcc: error: CreateProcess: No such file or directory

C:\MinGW\bin>

So what is going on above?!

Code: Select all

C:\MinGW\bin>set path=

C:\MinGW\bin>gcc file6.c

C:\MinGW\bin>

And what is going on above there? Why does gcc suddenly give no error, when the path is blank?

I thought maybe DLL files use the PATH.. and maybe there is a DLL in the perl directory that is getting hit on..

But that's not the case.. in that every dll in the path, is in c:\MinGW

Code: Select all

C:\MinGW\bin>for %f in (*.dll) do @where %f
C:\MinGW\bin\libcharset-1.dll
C:\MinGW\bin\libgcc_s_dw2-1.dll
C:\MinGW\bin\libgmp-10.dll
C:\MinGW\bin\libgmpxx-4.dll
C:\MinGW\bin\libgomp-1.dll
C:\MinGW\bin\libiconv-2.dll
C:\MinGW\bin\libintl-8.dll
C:\MinGW\bin\libmpc-3.dll
C:\MinGW\bin\libmpfr-4.dll
C:\MinGW\bin\libquadmath-0.dll
C:\MinGW\bin\libssp-0.dll
C:\MinGW\bin\mingwm10.dll
C:\MinGW\bin\pthreadGC2.dll
C:\MinGW\bin\pthreadGCE2.dll
C:\MinGW\bin\zlib1.dll

C:\MinGW\bin>

So I am stumped

[aGerman]

First of all I presume you don't have any name collisions (like a "gcc.bat" in the current directory).
However you may try to call gcc.exe file6.c (with Extension .exe instead).

Elsewise I fully understand your confusion.
I always compile my C programs with an IDE. For that reason I never run into trouble like that.
I tried to reproduce this behavior with an own program "test.exe". C/WinAPI source code:

Code: Select all

#include <windows.h>
#include <stdio.h>
#include <limits.h>

int main(int argc, char *argv[])
{
  char buffer[PATH_MAX] = {0};
  int i = 1;
  HANDLE hFile = INVALID_HANDLE_VALUE;
  WIN32_FIND_DATAA wfd = {0};

  GetModuleFileNameA(NULL, buffer, PATH_MAX)
    ? printf("I am:              %s\n", buffer)
    : fputs("*** Error getting own name.\n", stderr);

  GetCurrentDirectoryA(PATH_MAX, buffer)
    ? printf("Current directory: %s\n", buffer)
    : fputs("*** Error getting current directory.\n", stderr);

  for(; i < argc; ++i)
  {
    if ((hFile = FindFirstFileExA(argv[i], FindExInfoStandard, &wfd, FindExSearchNameMatch, NULL, 0)) != INVALID_HANDLE_VALUE)
    {
      printf("File found:        %s\n", wfd.cFileName);
      FindClose(hFile);
    }
    else
      fprintf(stderr, "*** File %s not found.\n", argv[i]);
  }

  puts("");
  return 0;
}

I created two directories "C:\foo" and "C:\bar" and copied "test.exe" to each.
I opened C:\foo and created an empty "test.txt" and "check.bat" with code:

Code: Select all

set path=
test test.txt

set path=C:\Windows\system32;C:\bar
test test.txt

set path=.;C:\Windows\system32;C:\bar
test test.txt

pause>nul

When I run the batch file I got:

Code: Select all

C:\foo>set path=

C:\foo>test test.txt
I am:              C:\foo\test.exe
Current directory: C:\foo
File found:        test.txt


C:\foo>set path=C:\Windows\system32;C:\bar

C:\foo>test test.txt
I am:              C:\foo\test.exe
Current directory: C:\foo
File found:        test.txt


C:\foo>set path=.;C:\Windows\system32;C:\bar

C:\foo>test test.txt
I am:              C:\foo\test.exe
Current directory: C:\foo
File found:        test.txt


C:\foo>pause1>nul

As you can see:
- always the test.exe in C:\foo is called and never in C:\bar
- the current working directory is always C:\foo
- test.txt was always found

Sorry, but I really don't know what's going on with gcc in your case

Regards
aGerman

[penpen]

It sounds like you are using the MinGW command shell (instead of the cmd.exe).
In this case the "." is probably a bourne shell builtin:
http://www.gnu.org/software/bash/manual ... ltins.html


penpen

[taripo]

I am using CMD.EXE not the MinGW command shell (I'm not sven sure there is such a thing? do you mean `C:\MinGW\msys\1.0\bin\bash.exe`? ) I am not using bash.exe I am using cmd.exe

I'll add some more info.

When c:\perl64\site\bin is not in the path, and the curent directory is c:\mingw\bin then no funny behaviour. C:\MinGW\bin>gcc file and C:\MinGW\bin>.\gcc file both work fine.

When c:\perl64\site\bin is in the path, then as long as DOT is before it in the PATH, or c:\mingw\bin is before it, there's no funny behaviour. C:\MinGW\bin>gcc file and C:\MinGW\bin>.\gcc file both work fine.

When c:\perl64\site\bin is in the path, and there's no dot before it in the path, and c:\MinGW\bin is not in the path prior, then C:\MinGW\bin>gcc file and C:\MinGW\bin>.\gcc file give different results


It's still running mingw's gcc whether you do gcc or .\gcc as shown by --version (and yeah there's no gcc.bat).. The one in the perl directory is a different version.


A theory is it looks like Mingw gcc perhaps tries to run some other file it needs, and it looks to the path and not to the current directory first. And if it finds a gcc/related files there, it gets confused. If mingw is in the path, before perl then it's fine.

Code: Select all

C:\MinGW\bin>set path=c:\perl64\site\bin

C:\MinGW\bin>gcc file6d.c
gcc: error: CreateProcess: No such file or directory

C:\MinGW\bin>.\gcc file6d.c

C:\MinGW\bin>gcc --version
gcc (GCC) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


C:\MinGW\bin>.\gcc --version
gcc (GCC) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


C:\MinGW\bin>set path=c:\MinGW\bin;c:\perl64\site\bin

C:\MinGW\bin>gcc file6d.c

C:\MinGW\bin>.\gcc file6d.c

C:\MinGW\bin>set path=.;c:\perl64\site\bin

C:\MinGW\bin>gcc file6d.c

C:\MinGW\bin>.\gcc file6d.c

C:\MinGW\bin>set path=c:\perl64\site\bin

C:\MinGW\bin>gcc file6d.c
gcc: error: CreateProcess: No such file or directory

C:\MinGW\bin>.\gcc file6d.c

I ran process monitor, filtering for path(not environment path, but accessing files on path) C:\MinGW and c:\perl

I have uploaded process monitor logs

http://ge.tt/1fw4oMK2

When doing .\gcc the command line gave no error, and all reads were within C:\MinGW's

When doing just gcc<ENTER> the command line gave an error, and looking at process monitor, it was sometimes looking at the perl directory

[Squashman]

I am using CMD.EXE not the MinGW command shell (I'm not sven sure there is such a thing? do you mean `C:\MinGW\msys\1.0\bin\bash.exe`? ) I am not using bash.exe I am using cmd.exe

Penpen made it pretty clear he was referring to bash.
BASH = Bourne Again Shell

[taripo]

I am using CMD.EXE not the MinGW command shell (I'm not sven sure there is such a thing? do you mean `C:\MinGW\msys\1.0\bin\bash.exe`? ) I am not using bash.exe I am using cmd.exe

Penpen made it pretty clear he was referring to bash.
BASH = Bourne Again Shell

He is referring to a shell(probably bash) within Windows within Ming. I responded that in Ming I suppose that'd be bash.exe

I can see he's talking about Bash. And i'm telling him that i'm not using it.

bash.exe is Bourne Again Shell, what else would you think bash.exe was for!

I'm just making it clear that i'm not using Bash(Bourne Again Shell) e.g. I am not running Ming's bash.exe.

[Squashman]

He is referring to a shell(probably bash) within Windows within Ming.

No, not probably. He is definitely referring to bash when he said "Bourne" and linked to the manual.

[taripo]

He is referring to a shell(probably bash) within Windows within Ming.

No, not probably. He is definitely referring to bash when he said "Bourne" and linked to the manual.

OK I didn't spot that. Anyhow, no i'm not using Bourne.

If I was using Bash or Bourne then I wouldn't have a C:\> I'd have a $

And if I was using Bash or Bourne, or something liek it, then I could after creating a file asdfasdf1 with 'ls' in it, I could do this and it'd run or try to run the ls command.

But it doesn't.

Code: Select all

C:\MinGW\bin>echo ls>asdfasdf1

C:\MinGW\bin>. asdfasdf1
'.' is not recognized as an internal or external command,
operable program or batch file.

C:\MinGW\bin>

and


Also it is running the same gcc (as shown by --version) whether I do gcc or .\gcc even when the path is set to a directory with another gcc, The gcc in the current directory gets precendence. cmd does that. Bash or Bourne wouldn't do that.


even

this is bash/bourne

Code: Select all

$ .
bash: .: filename argument required
.: usage: . filename [arguments]

this is the cmd prompt

Code: Select all

C:\>.
'.' is not recognized as an internal or external command,
operable program or batch file.

C:\>

I am very clearly not using Bourne or Bash.

edit- that said, maybe it's running some helper executable in a partly bash-y or partly bash-ish! way, and for some reason using whether the .\ or or no .\ precedes gcc to determine whether it does .\ or not when preceding some helper executable, and then when not doing .\ it as bash does, goes through the path and if the current directory is not in there it won't look there.

[penpen]

If i haven't missed anything then your csv-files show, that windows behaves exact the same for both call types,
but the gcc behaves different!

The first difference is located in the following lines:

Code: Select all

:: dotbackslash.csv
"2:46:52.0452413 PM","gcc.exe","15384","CreateFile","C:\MinGW\bin","SUCCESS","Desired Access: (...)

:: withoutdotbackslash.csv
"2:47:45.8155465 PM","gcc.exe","17528","CreateFile","C:\Perl64\site\bin\gcc","NAME NOT FOUND","Desired Access: (...)

(Shortened marked as "(...)".)

So it seems gcc uses an emulation (or some dll's) of the bash environment internally (whyever).


penpen

[taripo]

what makes you think ming gcc emulates bash or uses dlls of bash?

[penpen]

In both call types windows (in this case: cmd.exe, csrss.exe, svchost.exe) does exactly the same, with only one exception:
The cmd.exe initializes gcc with another command line parameter:

Code: Select all

:: dotbackslash.csv
"2:46:51.8235449 PM","cmd.exe","16020","Process Create","C:\MinGW\bin\gcc.exe","SUCCESS","PID: 15384, Command line: .\gcc  file6.c"

:: withoutdotbackslash.csv
"2:47:45.6719865 PM","cmd.exe","16020","Process Create","C:\MinGW\bin\gcc.exe","SUCCESS","PID: 17528, Command line: gcc  file6.c"

After that no windows process has control over what gcc does:
Within the log files this fact is indicated by lines with process name "gcc.exe" and a process identicator (PID) of "15384" / "17528".

So gcc "decides on its own" to show the behaviour of the bash command "." (see the codeblock in my last post).

If the gcc.exe contains this code, then it uses an emulation of this bash command ("."),
else a (MinGW/bash) dll contains this code and is executed by the gcc
(windows does not provide this functionality, so it is not contained in any of its dll's).


penpen

[aGerman]

I agree with penpen. It's the only plausible explanation in my opinion. The dot must have another meaning in the GCC process since you can't reproduce that behavior with other programs (as my example shows).

Also remember that GCC was originally developed for *nixoid operating systems and still is the default C compiler for various Linux distributions. MinGW is only a port of GCC for Windows. It isn't really surprising to me that default behavior of *nixoid shells is partly left in MinGW.

BTW: I'm wondering if that is really an issue for you. Once you know the behavior of GCC it's easy to work around, isn't it?

Regards
aGerman

[taripo]

yeah the workarounds I mentioned are easy.

Initially I thought this might be a fundamental thing about CMD and if so then I wanted to get to the bottom of it by posting here.

Now I know it's not, and it's Ming GCC behaviour