Subject: Re: Re: mingw on x64, workaround - msg#00082

Previous Message by Date: click to view message preview

Re: Strange path transformation with Emacs

Earnie Boyd wrote, quoting me: >>>> Maybe what is required is not as simple as I suggested earlier; >>>> maybe its the case of nested quotes, as in my example, that needs >>>> attention, such that ANYTHING within INNER quotes is exempt from >>>> any form of mangling. >>>> >>> >>> I"ll keep this in mind but may require even further intraoperation >>> of bash with MSYS internals. I.E. I fear that bash strips the >>> outter quotes before passing the string as an argument. >> >> Well, since bash strips away the outermost level of enclosing quotes, >> and ONLY the outermost level at each "eval" cycle, doesn't it follow >> that any you see in path.cc's parsing routine MUST be inner quotes? >> Given this premise, would it not then be safe to assume that the user >> INTENDED that the enclosed text should passed literally, and so handle >> it accordingly, i.e. exempt it from path name transformation? >> > > I can't make that assumption. I'm not sure that I really DO get this. Why ever not? In the *nix world, quotes are ALWAYS used to suppress some special behaviour. Shells use double quotes to suppress word splitting, and single quotes to do the same, while additionally suppressing variable substitution and shell expansion. WHY should MSYS be any different -- (and you ARE saying that it MUST be, so that even its bash implementation behaves counter intuitively wrt quoting)? > However, MSYS should see c:/foo as an absolute path and not do its > magic. For some reason it is seeing c:/foo as a list; probably due to > the fact that the ':' is not the second position of the string passed. > I'll need to do some more algorithmic magic based on the ``"'' or the > ``''' before the ``:''. You already have a good understanding of the > subtleties so I don't need to explain further. I think, perhaps, that you do. As a long time *nix user, I expect that when I type any command arguments wrapped in quotes, especially SINGLE quotes, that it will get passed to the forked application verbatim. Ok, you say that MSYS should see "c:/foo" as an absolute path, and should not transform it. It's a contrived example, I know, but what if I want to pass "foo:/bar" as a literal? This doesn't look like a Win32 absolute path, so MSYS shouldn't recognise it as such, and therefore WILL transform it. Even if I type it as '"foo:/bar"', my application will end up seeing something like "foo;D:\MSYS\1.0\bar", or, if I reverse the order of quoting to "'foo:/bar'", the application will see 'foo;D:\MSYS\1.0\bar' -- definitely NOT what I intended, nor expected. I fully accept that, because bash strips the outermost level of quotes, you cannot know what type of quotes were present when the user typed his command, so there are always going to be tricky quoting examples, which MSYS will probably mishandle. However, in the cases under discussion, the presence of an inner layer of quoting is unequivocal, since bash doesn't strip them away. If you insist that you can't assume that their presence means "hands off, this string MUST be passed literally", then I am afraid that I tend to interpret that as "MSYS is BROKEN BY DESIGN" -- this doesn't fit even the minimal POSIX emulation objective that you set out to achieve, since its handling of quoted literals is entirely anomalous. Sorry to be so blunt, but that is just the way I see this, and I am rather playing the Devil's Advocate. Regards, Keith. ------------------------------------------------------- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar

Next Message by Date: click to view message preview

Re: MSYS without installer

Earnie Boyd wrote: On 10:35:58 am 2005-07-11 Neil Rashbrook <neil-V5WmbL8gJonkYMGBc/C6ZA@xxxxxxxxxxxxxxxx> wrote: I WinZipped up the whole c:\msys subtree on the source ^^^^^^^^^ This = your problem. WinZip uses \n to \r\n conversion by default. Be sure to turn off the conversion. Surely that would show up as a change in the total file sizes (as reported by dir/s)? Alternatives, use tar with gzip or bzip2 compression. Copy the tarball to diskette or USB drive with a copy of gzip.exe or bzip2.exe, tar.exe and msys-1.0.dll to a folder on the diskette (do not put msys-1.0.dll, gzip, etc at the root of the diskette). I couldn't even get tar.exe to run - same stack dump issue. In the created folder you also need to mkdir etc/. Interestingly if I remove etc/ then tar --help produces no output, but no stack dump either. us.stackdump Description: Text document

Previous Message by Thread: click to view message preview

Re: Re: mingw on x64, workaround

On 2:22:20 am 2005-07-12 Scott Duplichan <sduplichan-/E1597aS9LQAvxtiuMwx3w@xxxxxxxxxxxxxxxx> wrote: > This Win64 work-around that I stumbled onto cannot operate from > within the target process. Instead, it is part of the parent process. > So a patch is not possible. > > I confirmed that the work-around works with the latest files from > sourceforge.net. All that is needed for Win64 is to replace START > rxvt.. with createprocess.exe rxvt.. So I guess that will have to do > for the time being. -- > Scott > So the patch would be to msys.bat. Should be able to do something. Maybe changing ``start ...'' to ``%START% ...'' and set START based on win32 or win64. Is there something in the environment that identifies win64? Earnie ------------------------------------------------------- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar

Next Message by Thread: click to view message preview

Re: mingw on x64, workaround

On 12:40:27 pm 2005-07-11 Sebastien Loisel <sloisel-Re5JQEeQqe8AvxtiuMwx3w@xxxxxxxxxxxxxxxx> wrote: > Hello, > > Scott Duplichan was kind enough to resend his workaround for the > problem with msys and x64. Earnie, as you asked for a patch, I am > cc'ing you directly. Please don't cc me directly. I read the list mail and don't need an extra copy. Earnie ------------------------------------------------------- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar