Menu
▾
▴
[Mingw-notify] [ mingw-Bugs-1511614 ] msys in Program Files, msys.bat fails
|
From: SourceForge.net <no...@so...> - 2009-06-19 00:00:10
|
Bugs item #1511614, was opened at 2006-06-23 20:01 Message generated for change (Comment added) made by cstrauss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1511614&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: Feature requests Status: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: John Ralls (jralls) Assigned to: Earnie Boyd (earnie) Summary: msys in Program Files, msys.bat fails Initial Comment: MSys 1.0.11 Snapshot 2004.04.30-1 If msys is installed in a path with spaces, msys.bat fails unless launched from a command window with explicit short-names in the path. This is because the line which sets WD, set %WD%=%~dp0\bin\ strips the quotes from the path, so when it comes time to execute start %WD%rxvt... cmd.exe uses the path only up to the first space. Since there isn't a modifier which doesn't strip the quotes and will still lose the filename, the only recourse is to use all short names: set %WD%=%~dps0\bin\ (BTW, the '\' between '0' and 'bin' is superfluous, though harmless) ---------------------------------------------------------------------- Comment By: Cesar Strauss (cstrauss) Date: 2009-06-18 21:00 Message: Hamish wrote: > I can't seem to figure out how to add an attachment to a ticket without > opening up a new one, I believe it is a SourceForge policy to only allow attachments from the original poster. > so I humbly submit the following patch via URL: Thank you for your patch submission. It would be really best, however, if you did open a new ticket in the patch tracker. It is a new patch, that treats the issue in a different way, after all. Regards, Cesar ---------------------------------------------------------------------- Comment By: Hamish B (hbowman) Date: 2009-06-11 11:47 Message: Hi, I can't seem to figure out how to add an attachment to a ticket without opening up a new one, so I humbly submit the following patch via URL: http://bambi.otago.ac.nz/hamish/dev/msys/abort_on_spaces.diff it fixes the quoting problems AND adds the following: +for /F %%i IN ('echo %WD%') DO @set PART1=%%i +if NOT "%PART1%" == "%WD" ( + echo Path names containing spaces are not supported -- aborting. + pause + exit 1 +) if the user decides to remove that, well they can expect about as much recourse from the manufacturer as if they had unweleded the seat belts from their car to save weight, and they'll know it. this way we can work on finding and fixing the quoting problems in the background without you guys getting flooded with support requests for an issue which isn't necessarily a useful sink of your time. at minimum at least with this patch it'll fail cleanly & obviously if the user ignores your prior warnings. Hamish ---------------------------------------------------------------------- Comment By: Cesar Strauss (cstrauss) Date: 2009-06-11 01:20 Message: I guess it is good engineering to make programs (e.g. msys.bat) more robust against erroneous input (e.g. spaces in pathnames). It does not mean spaces in pathnames are now officially supported, it just means they are somewhat tolerated. Since there is a simple fix to msys.bat available (#1840961), which was verified to work by a third-party (Hamish), I am inclined to accept it. Regards, Cesar ---------------------------------------------------------------------- Comment By: Hamish B (hbowman) Date: 2009-06-09 12:43 Message: Obviously I can't make open ended promises to audit and patch the entire GNU toolchain, nor do I expect you to. I just fix bugs as I find 'em and hope others do the same. as far as bending over backwards, here are some pertinent comments by the lead of another project I work on from time, http://article.gmane.org/gmane.comp.hardware.gps.gpsd.user/2428/ http://article.gmane.org/gmane.comp.hardware.gps.gpsd.user/2554/ http://article.gmane.org/gmane.comp.hardware.gps.gpsd.user/2443/ that doesn't really add anything new, just to point out that others walk this path as well. (in the above case the code deals with unix sockets and such, so it is not just simple software tweaks to maintain the port) Personally I don't use MS Windows and haven't for many years, and in general have little motivation to put my back out for it, but a bug is a bug and unquoted variables can certainly have much more important implications than failure to run on an unfavored OS. regards / over & out, Hamish ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2009-06-09 11:54 Message: If you can provide the maintainers of all of the packages used fixes for the issue and their acceptance of those changes into the package sources then I will reconsider. There are many though you'll have to bend over backward to even consider a change for Windows. As for your development rules for make, you have a smart team. Other users of make simply don't bother and many packages that are built will break with spaces in the path name simply because the make rules aren't setup to deal with it. It is a hard struggle but I don't know that it is one to spend much time on. We give a default path we know works. Changing it is the users choice but we recommend that the choice isn't with spaces in the name. It is a long and standing rule just because of the many factors to consider when dealing with other packages. ---------------------------------------------------------------------- Comment By: Hamish B (hbowman) Date: 2009-06-09 11:41 Message: As you wish, but I would have preferred a technical reason rather than a strategic one. Our dev team is in a rather strong position to find and fix these bugs for you, it's a bit of a shame to hear that we can't even try / must maintain our own orphaned patch-set. fwiw, w.r.t make- our rule is that build-time requires no-spaces, but run time allows them. the distinction being that our developers can effortlessly deal with *nixisms but our end-users probably can't. respectfully understanding the limited manpower issues but hate to be defeatist, Hamish ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2009-06-09 10:54 Message: MSYS.BAT isn't the only issue with spaces in the path name. I'm not even sure if MSYS itself doesn't have some problem with it somewhere. I know tools like make will choke on it. Since it assigned to me, I'm marking it Won't Fix. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2009-06-09 10:35 Message: My immediate inclination is that we should reject this. Spaces in path names are know to create myriad problems. Just because you *can* have them, doesn't mean that you *should*. (Personally, I think they are an insane idea; not only are they more difficult for the machine to parse, but my eye also finds them to be a completely unnecessary distraction). We have always cautioned against installing either MSYS or MinGW into any path with white space in its name, yet here we are being asked to consider a patch which would facilitate such an installation, (which we have previously declared to be invalid). Do we *really* want to encourage this? Do we want the additional burden of support requests, as even more users explore the pitfalls of such inadvisable installations? Cesar, as maintainer, I would welcome your viewpoint. From my perspective: MSYS in "Program Files" == Broken Installation *I* will *not* offer support advice to users who refuse to accept this. ---------------------------------------------------------------------- Comment By: Hamish B (hbowman) Date: 2009-06-06 11:52 Message: after the msys.bat "start" patch from #1840961 and modifying msys/etc/fstab to use C:\PROGRA~1\... our app loads and runs from within C:\Program Files. I can live with ~1 in the fstab file until someone submits a quoting patch (it's a feature), but could the "start" patch be applied? (it's a bug) Hamish ---------------------------------------------------------------------- Comment By: Hamish B (hbowman) Date: 2009-06-06 11:33 Message: I wrote: > some issues ":startrxvt" of msys.bat, > see http://trac.osgeo.org/grass/ticket/629 pending patch here: https://sourceforge.net/tracker/index.php?func=detail&aid=1840961&group_id=2435&atid=102435 > is it legal to quote a path with spaces in fstab? e.g. "C:\Program Files\fooware2000" > is there a Windows command that can convert from expanded to 8.3 DOS~1 > names as part of a batch file? That way our installer could work around > the fstab parsing issues at the time of fstab creation. dir /x; some .bat code here: https://sourceforge.net/tracker/index.php?func=detail&aid=1087569&group_id=2435&atid=202435 but `dir /x` doesn't really help when we want to set the path in fstab as part of the installer, when the files don't exist yet so `dir` fails with "File not found." understanding that y'all are burned out on spaces-in-filenames issues, but none the less if no one tries it's never going to fix itself.. at least these bugs are not subtle. thanks, Hamish ---------------------------------------------------------------------- Comment By: Hamish B (hbowman) Date: 2009-06-06 11:13 Message: Hi, some issues ":startrxvt" of msys.bat, see http://trac.osgeo.org/grass/ticket/629 > You'll surely have issues with other items with spaces in the path names. I'd like to fix them, one by one. Even if it takes a long time. After all, spaces are legal in UNIX filenames too. is it legal to quote a path with spaces in fstab? e.g. "C:\Program Files\fooware2000" is there a Windows command that can convert from expanded to 8.3 DOS~1 names as part of a batch file? That way our installer could work around the fstab parsing issues at the time of fstab creation. thanks, Hamish ---------------------------------------------------------------------- Comment By: John Ralls (jralls) Date: 2006-06-24 14:36 Message: Logged In: YES user_id=138414 You mean the part about using DOS names for embedded-space-pathnames in fstab, or the part where you show how to start Word (including escaping the spaces in 'Program Files' and 'Microsoft Office')? Both seem to work just fine. The unmodified msys.bat file works ok from the command line too as long one invokes it with the DOS name (e.g. Progra~1 for Program Files). When one double-clicks a shortcut, though, even if the shortcut specifies the DOS name, Windows XP passes in the expanded path name. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2006-06-24 10:10 Message: Logged In: YES user_id=15438 Did you read the /doc/msys/README.rtf? You'll surely have issues with other items with spaces in the path names. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1511614&group_id=2435 |