From: SourceForge.net <no...@so...> - 2005-08-08 13:25:00
|
Bugs item #1251682, was opened at 2005-08-04 04:38 Message generated for change (Comment added) made by mtew You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1251682&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: msys Group: None Status: Open Resolution: None Priority: 5 Submitted By: Max TenEyck Woodbury (mtew) Assigned to: Earnie Boyd (earnie) Summary: Strangeness when PATH unset or empty Initial Comment: While trying to track down some oddness with the shell, I tried the 'check' target in the distribution package as a general purpose diagnostic of how well MSYS and bash met expectations. On five occasions (in rapid succession) that test produced dialog boxes to the effect that 'msys-1.0.dll' was not available. I wondered what caused that. I think I have identified the situation and problem that underlies this odd behavior. That particular test sets PATH to empty and this apparently confuses the windows loader. While this is only likely to happen as a result of user stupidity or meanness, it should be fairly easy to fix. If PATH is empty, force a temporary value of '/bin' into it so the .dll and basic utilities can still be found. ---------------------------------------------------------------------- >Comment By: Max TenEyck Woodbury (mtew) Date: 2005-08-08 09:24 Message: 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'? ---------------------------------------------------------------------- Comment By: Max TenEyck Woodbury (mtew) Date: 2005-08-07 06:20 Message: 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... ---------------------------------------------------------------------- Comment By: Luke Dunstan (infidel) Date: 2005-08-06 23:19 Message: 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? ---------------------------------------------------------------------- Comment By: Max TenEyck Woodbury (mtew) Date: 2005-08-06 03:11 Message: 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... ---------------------------------------------------------------------- Comment By: Luke Dunstan (infidel) Date: 2005-08-06 02:05 Message: 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 ---------------------------------------------------------------------- Comment By: Max TenEyck Woodbury (mtew) Date: 2005-08-05 11:17 Message: Logged In: YES user_id=735003 OK, I just needed to assure that I understood your decision properly. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2005-08-05 10:18 Message: 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 ---------------------------------------------------------------------- Comment By: Max TenEyck Woodbury (mtew) Date: 2005-08-05 09:46 Message: 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. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2005-08-04 07:32 Message: 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1251682&group_id=2435 |