Strangeness when PATH unset or empty

Logged In: YES
user_id=15438

So your proposal is to test PATH for empty before spawn and
set it to a minimal string of ``/bin''? This would need to
be done at the top of the spawn_guts function so that the
translation back to win32 paths work correctly.

Submit a patch to the patch tracker and I'll have a try at it.

earnie

Logged In: YES
user_id=735003

Frankly, I do not yet know enough about the overall
structure of MSys to propose a definitive solution. As I
understand it, the change to PATH does have to go in ahead
of the tranlation to DOS file names as you said, but that
might go either before or after the creation of the new
thread depending on how the code is structured. It might
even be a good idea to make it a patch to 'bash'. Once that
is decided, I will almost certainly be able to generate the
actual code change, if that is what you want me to do.

Logged In: YES
user_id=15438

I gave you the location of where the patch needs to happen
in the MSYS runtime code. It isn't a problem that bash
needs to deal with.

Earnie

Logged In: YES
user_id=735003

OK, I just needed to assure that I understood your decision
properly.

Logged In: YES
user_id=30442

What is the advantage of doing this though? Why does the
test set the PATH to empty, and what command fails? I think
if PATH is empty it should do what it is documented and
expected to do, which means not looking in /bin

Logged In: YES
user_id=735003

>Sender: infidel SourceForge.net Subscriber

>What is the advantage of doing this though?

It would remove an anomoly due to a limitation in windows.

>Why does the test set the PATH to empty,

To test the effect of the -p option in bash and probably
other things as well.

>and what command fails?

All commands that link to msys-1.0.dll or any other .dll for
that mater. I think any file reference would also fail.
They would not fail in a real POSIX environment.

>I think if PATH is empty it should do what it is documented and
>expected to do, which means not looking in /bin

That would be correct with respect to executables, but
windows also needs to know where to look for .dlls and there
is a whole raft of issues with not being able to translate
file names between the native and nominal environments. In
particular msys-1.0.dll provides critical file system name
mapping information and having two copies causes all sorts
of odd behavior. This key .dll is always in /bin - by
definition. While the addition /bin to PATH is somewhat
inconsistant with POSIX, not being able to run /bin/sh or
any other command specified by an absolute path when
specifically requested is even more inconsistant. It's
hobson's choice with this being the lesser infraction...

Logged In: YES
user_id=30442

In what way is POSIX different from Windows, exactly? What
does this have to do with the "-p" option?

When I try setting PATH to empty in an interactive shell, I
can certainly execute /bin/sh with an absolute path, because
Windows looks for DLLs in the directory containing the
executable (sh.exe) even before looking in PATH. Can you
give an example that demonstrates the problem?

Logged In: YES
user_id=735003

>Sender: infidelSourceForge.net Subscriber

>In what way is POSIX different from Windows, exactly?

Hey, I said I was a bit fuzzy on the details. It's got
something to do with trying to find .dlls. Since I don't
have the Windows source code to nose through, it's a bit
tough to give you an exact answer. However it is pretty
clear that they ARE different.

>What does this have to do with the "-p" option?

Again, I don't know the details. That's just what some of
the comments associated with the test mentioned. If you
want the details, the source code for 'bash' and the test
suite are all on-line for your edification. Exactly what is
going on in the mind of the guy (or gal) who wrote the test
is something that does not grab my interest at this point.
Why the tests were playing around with PATH not a
significant problem. The fact that some very strange
behavior shows up when that particular action was taken is
much more significant as far as I am concerned.

>When I try setting PATH to empty in an interactive shell, I can
>certainly execute /bin/sh with an absolute path, because
Windows
>looks for DLLs in the directory containing the executable
(sh.exe)
>even before looking in PATH. Can you give an example that
>demonstrates the problem?

OK. /bin/sh was not the greatest example. If you think about
it I have already provided another example.. The 'check'
target of the 'bash' package shows this. There is only one
place where msys-1.0.dll can be - in /bin. The directory
containing msys-1.0.dll is by DEFINITION the location of
/bin. All other directories are relative to that location.
It must be unique if there is to be any coordination with
repect to file access. In the 'check' tests, the just built
copy of 'bash' is being exercised. It needs the
msys-1.0.dll to run. If you put an extra copy of
msys-1.0.dll in the same directory with it, you get hundreds
of errors and a stack dump or two because you've screwed
with one of the basic assumptions underlying MinGW and MSys.
(Yeah, I tried it. Twice about ten days apart, once with
the .dll from the distribution and again with one that I had
built from sources.) On the other hand, when the tests chop
off 'PATH', it can no longer find the official msys-1.0.dll
and produces a sequence of five errors with dialog boxes.
In other words it was fairly hard not to notice the problem.
This is very obviously one of those 'corner' cases where
odd things happen. It's not going to hurt very many people,
but now that the problem has been noticed and a simple
solution identified, it should be fixed...

Meanwhile the build of newlib and binutils is tying up this
machine to the point where it is pointless to do anything
but type in long-winded responses to bug reports. Trying to
get a good gcc build just isn't in the cards at this time.
I think getting some sleep might be a better investment at
the moment...

Logged In: YES
user_id=735003

Earnie:

I've just taken a look at spawn_guts in spawn.cc. If the
change is made there, a duplicate of envp would be needed.
On the other hand the setup for the spawned processes
environment is done in 'winenv' in envron.cc and spawn_guts
seems to be the only thing that calls 'winenv'. It's
already got loops that scan the environment list so it would
be fairly simple to add the PATH check there. Have I missed
any other calls to 'winenv'?

Logged In: YES
user_id=30442

OK, I understand the problem now. The test is probably
setting PATH to empty to make sure that /bin/sh is NOT
executed, so hacking MSYS to pretend that PATH=/bin
seems dangerous and may or may not do what the test
intended. I wonder how the Cygwin build process for bash
handles this? (hopefully not by putting cygwin1.dll in a
system directory, but I don't remember)

Has this particular problem come up in any other builds? If
not I hardly think that it justifies modifying MSYS. A much
less disruptive alternative could be to modify the bash test
scripts to do something special for MSYS.

I am only trying to point out the dangers of adding hacks to
MSYS to solve a problem building a single package. If you
add it and nobody complains then I guess that is good
enough.

Logged In: YES
user_id=735003

>Sender: infidelSourceForge.net Subscriber

>OK, I understand the problem now. The test is probably
>setting PATH to empty to make sure that /bin/sh is NOT
>executed, so hacking MSYS to pretend that PATH=/bin
>seems dangerous and may or may not do what the test
>intended. I wonder how the Cygwin build process for bash
>handles this? (hopefully not by putting cygwin1.dll in a
>system directory, but I don't remember)

There are at least two misaprehentions here:

1) Whatever the intent of the test, it has nothing to do
with finding /bib/sh because (a) it finds whatever
executable it is looking for but can not find the .dll it
requires and (b) it is testing bash.exe, not sh.exe and
bash.exe is not normally in /bin/ and would not have
produced the actual error generated because the .dll it
would have required would have been in the local directory.

2) While I need to do tests to be sure, the 'system'
directory where such things as kernel.dll reside is normally
included in the path. Windows may not be able to find even
these critical .dlls without a path.

>Has this particular problem come up in any other builds? If
>not I hardly think that it justifies modifying MSYS. A much
>less disruptive alternative could be to modify the bash test
>scripts to do something special for MSYS.

I don't mind munging the test script too much to avoid
fundamental differences between POSIX and Windows, like the
meaning of ':', but having identified the problem, it is
clearly fixable at a more global level and will do more than
just diddle a diagnostic.

>I am only trying to point out the dangers of adding hacks to
>MSYS to solve a problem building a single package.

That would depend on the package now wouldn't it. If it
were something absolutely critical, like the main shell, the
terminal emulator or the compilers, then hacking at the
problem until a real solution emerges is definitely the
right thing to do.

While this is a mere diagnostic target, it does show a
rather basic gotcha that can and should be addressed now we
know about it. The fact that the circumstances where it
arise are unusual and can usually be avoided is the reason
this is not a 'show stopper', but it does diserve a normal
portion of attention.

>If you add it and nobody complains then I guess that is good
>enough.

And that is almost exactly what Earnie said to do, exept he
included a 'quality of implementation' restriction in the
mix by implication as well.

Speaking of Earnie -- I asked a question about environ.cc
earlier -- any reaction?

Logged In: YES
user_id=15438

I missed the question. I'll have to look; it'll be two or
three weeks before I can get back to it. I'm going to be on
a business trip.

Earnie

Logged In: YES
user_id=30442

Just for your information:

1. While MSYS has no /bin/bash, many operating systems
do, so I still think the intent is to _avoid_ executing /bin/bash.
I'm sure the test will work after your changes though

2. The DLL search rules are documented and my comments
are based on this:

http://msdn.microsoft.com/library/en-us/dllproc/base/dynamic-
link_library_search_order.asp

Logged In: YES
user_id=15438

The issue is executing a test where the binary being tested
is dependent on dll's that do not exist in the directory
with the exe or on the PATH. Setting PATH to null should
not be done on windows regardless of what is executing the
test. In unix it isn't an issue because the shared library
paths are controlled by a different variable. I'm thinking
that even the windows system dlls will not be findable in
this scenario.

Now it is time to ask for a consideration. Should we lie to
the user and let them think PATH is not set or should we
tell the truth and cause setenv to set a default PATH when
the user tries to set it to empty and thus allow the user
see the default PATH?

Earnie