From: Wayne S. <ws...@bi...> - 2004-02-11 18:43:31
|
Cygwin comes with a 'cygpath' program to convert between POSIX and Windows pathnames. Does MSYS come with an equivalent. -Wayne |
From: Olaf F. <o.f...@sc...> - 2004-02-12 08:28:50
|
Hi, > Cygwin comes with a 'cygpath' program to convert between POSIX and > Windows pathnames. > > Does MSYS come with an equivalent. You should not need such a thingy, because Msys automagically translates Path names, even in the environment. If you have a problem with this translation, you should try to describe your problem in more detail. Olaf -- ________________________________creating IT solutions Dr. Olaf Flebbe science + computing ag Leiter Softwareentwicklung Hagellocher Weg 71-75 phone +49 7071 9457 254 72070 Tuebingen, Germany fax +49 7071 9457 511 www.science-computing.de ________________________________events | conferences RZ- und IT-Leiter Forum, 10.-13.02.04 http://www.science-computing.de/veranstaltungen |
From: Earnie B. <ea...@us...> - 2004-02-12 11:45:01
|
Olaf Flebbe wrote: > Hi, > >> Cygwin comes with a 'cygpath' program to convert between POSIX and >> Windows pathnames. >> >> Does MSYS come with an equivalent. > > > > You should not need such a thingy, because Msys automagically > translates Path names, even in the environment. If you have a problem > with this translation, you should try to describe your problem in more > detail. > Applause to Olaf; this is very much the correct answer. Earnie -- http://www.mingw.org http://sourceforge.net/projects/mingw https://sourceforge.net/donate/index.php?user_id=15438 |
From: Wayne S. <ws...@bi...> - 2004-02-12 22:20:48
|
From: Olaf Flebbe <o.f...@sc...> > You should not need such a thingy, because Msys automagically > translates Path names, even in the environment. If you have a > problem with this translation, you should try to describe your > problem in more detail. OK. I have been meaning to do this anyway. Allow me to introduce myself. I am one of the BitKeeper developers (http://bitmover.com) and have been working on our Windows version. BitKeeper is a commercial revision control system that allows free use by opensource developers with some restrictions. (see web page for details) On Windows, BitKeeper is a Win32 application, but some parts of it are written in Bourne shell and depends of POSIX utilities. Our current version ships Cygwin along with BitKeeper and installs it for the user. This has proven to be a pain because we have an external dependency. The user cannot upgrade to a newer version of Cygwin because they might break BitKeeper (this has happened) and you can't have two different versions of Cygwin installed. So I started writing my own port of the Cygwin tools that would use a different DLL so we could install it and use it independent of whatever shell utilities the user might be using on their box. I also wanted to change the directory mounting so it was hard coded to just contain the current drives and a /bin that is determined by the location of the DLL. And make all file access fixed in binary mode. In short remove all dependencies on the Windows registry. Then I discovered that MSYS already meets all my requirements. So we are planning on shipping an unmodified version of MSYS with BitKeeper to use when running internal scripts. Users can use Cygnus tools or whatever shell they want (including MSYS) to run BitKeeper. Before running any internal scripts BitKeeper sets a PATH so that the MSYS tools appear first. This all works really well. The problem I had is that at a couple points I want to run a command line on behalf of the user from inside the MSYS /bin/sh. To do that I need to restore that PATH to what it was before the win32 bk.exe messed with it. And in bk.exe I did the equivalent to this: sprintf(buf "BK_OLDPATH=%s", getenv("PATH")); putenv(buf); ... create a new PATH in p ... sprintf(buf "PATH=%s", p); putenv(buf); So in bash, I have the original PATH I want to use, but it is a WIN32 PATH and is not useful. So at the moment I use this code: # On Windows convert the original Windows PATH variable to # something that will map the same in the shell. test "X$OSTYPE" = "Xmsys" && { BK_OLDPATH=$(echo $BK_OLDPATH | \ sed -e 's,\(.\):,/\1,g' -e 's,;,:,g' -e 's,\\,/,g') } PATH="$BK_OLDPATH" eval $EDITOR "$@" In Cygwin, you would use the cygpath for this. There. That is a long explanation, but that is why I asked the question. But my sed solution seems to work and I don't _think_ it will break. ;-) With all that out of the way on behalf of Bitmover I would like to thank you guys for the MSYS code. We would like to contribute to the community in any way possible. If you guys would like commercial seats for BitKeeper to develop MSYS or MinGW let me know and I will talk the sales guys into it. Need some web hosting? Let me know. Something else? Certainly we will do careful testing and try to feedback any bugfixes we make to the code. Q: How confortable do people feel about the stability of 1.0.10-rc4 running non-interactive code? Or should I use 1.0.9? -Wayne |
From: Earnie B. <ea...@us...> - 2004-02-13 12:31:46
|
Wayne Scott wrote: >From: Olaf Flebbe <o.f...@sc...> > > >>You should not need such a thingy, because Msys automagically >>translates Path names, even in the environment. If you have a >>problem with this translation, you should try to describe your >>problem in more detail. >> >> > >OK. I have been meaning to do this anyway. Allow me to introduce >myself. I am one of the BitKeeper developers (http://bitmover.com) >and have been working on our Windows version. > >BitKeeper is a commercial revision control system that allows free use >by opensource developers with some restrictions. (see web page for >details) > > Perhaps I see commercial support for development activities. ;) >On Windows, BitKeeper is a Win32 application, but some parts of it are >written in Bourne shell and depends of POSIX utilities. Our current >version ships Cygwin along with BitKeeper and installs it for the >user. This has proven to be a pain because we have an external >dependency. The user cannot upgrade to a newer version of Cygwin >because they might break BitKeeper (this has happened) and you can't >have two different versions of Cygwin installed. > > > Sure you can more than one version installed, you just can't use them at the same time. :p >So I started writing my own port of the Cygwin tools that would use a >different DLL so we could install it and use it independent of >whatever shell utilities the user might be using on their box. I also >wanted to change the directory mounting so it was hard coded to just >contain the current drives and a /bin that is determined by the >location of the DLL. And make all file access fixed in binary mode. >In short remove all dependencies on the Windows registry. > > How much coding did you actually get done? >Then I discovered that MSYS already meets all my requirements. So we >are planning on shipping an unmodified version of MSYS with BitKeeper >to use when running internal scripts. Users can use Cygnus tools or >whatever shell they want (including MSYS) to run BitKeeper. Before >running any internal scripts BitKeeper sets a PATH so that the MSYS >tools appear first. > > And your version of MSYS shouldn't interfere with another installed version. The exception I've found so far is if I cd directly to the bin directory of a different version and try executing a command. The process will hang and you have to use the task manager to kill the process. The process is easily findable with the output of ps in any other window. >This all works really well. The problem I had is that at a couple >points I want to run a command line on behalf of the user from inside >the MSYS /bin/sh. To do that I need to restore that PATH to what it >was before the win32 bk.exe messed with it. And in bk.exe I did the >equivalent to this: > > Have you tried just not worrying about it? MSYS should be able to handle the win32ized PATH. It will convert it upon startup. > sprintf(buf "BK_OLDPATH=%s", getenv("PATH")); > putenv(buf); > > ... create a new PATH in p ... > sprintf(buf "PATH=%s", p); > putenv(buf); > >So in bash, I have the original PATH I want to use, but it is a WIN32 >PATH and is not useful. > >So at the moment I use this code: > > # On Windows convert the original Windows PATH variable to > # something that will map the same in the shell. > test "X$OSTYPE" = "Xmsys" && { > BK_OLDPATH=$(echo $BK_OLDPATH | \ > sed -e 's,\(.\):,/\1,g' -e 's,;,:,g' -e 's,\\,/,g') > } > > PATH="$BK_OLDPATH" > eval $EDITOR "$@" > > > But why do you need to do this? I don't understand the need. MSYS upon dll initialization in process entry will convert PATH to POSIX format and will convert it back to Win32 format when execing a non-MSYS dependent (a.k.a. native) executable. >In Cygwin, you would use the cygpath for this. > > >There. That is a long explanation, but that is why I asked the >question. But my sed solution seems to work and I don't _think_ it >will break. ;-) > > > It shouldn't break anything, but is it needed? >With all that out of the way on behalf of Bitmover I would like to >thank you guys for the MSYS code. We would like to contribute to the >community in any way possible. If you guys would like commercial >seats for BitKeeper to develop MSYS or MinGW let me know and I will >talk the sales guys into it. Need some web hosting? Let me know. >Something else? > > I don't see the need for bitkeeper for MinGW or MSYS, but send me privately info on the hosting bit. >Certainly we will do careful testing and try to feedback any bugfixes >we make to the code. > > Do you have an SF account? I would be more than happy to allow you to improve MSYS. >Q: How confortable do people feel about the stability of 1.0.10-rc4 > running non-interactive code? Or should I use 1.0.9? > > 1.0.10-rc-4 will become the 1.0.10 release version as soon as I get a little time. Earnie -- http://www.mingw.org http://sourceforge.net/projects/mingw https://sourceforge.net/donate/index.php?user_id=15438 |
From: Wayne S. <ws...@bi...> - 2004-02-13 13:19:06
|
From: Earnie Boyd <ea...@us...> > >So I started writing my own port of the Cygwin tools that would use a > >different DLL so we could install it and use it independent of > >whatever shell utilities the user might be using on their box. I also > >wanted to change the directory mounting so it was hard coded to just > >contain the current drives and a /bin that is determined by the > >location of the DLL. And make all file access fixed in binary mode. > >In short remove all dependencies on the Windows registry. > > > > > How much coding did you actually get done? Alot of the pieces. Mostly just coding around various paths. I was last stuck on the fact that I was unable to call cygwin binaries directly from my mutant cygwin. I suspect there was some optimization in the spawn code for when calling cygwin from cygwn, but I didn't find it. > >Then I discovered that MSYS already meets all my requirements. So we > >are planning on shipping an unmodified version of MSYS with BitKeeper > >to use when running internal scripts. Users can use Cygnus tools or > >whatever shell they want (including MSYS) to run BitKeeper. Before > >running any internal scripts BitKeeper sets a PATH so that the MSYS > >tools appear first. > > > > > And your version of MSYS shouldn't interfere with another installed > version. The exception I've found so far is if I cd directly to the bin > directory of a different version and try executing a command. The > process will hang and you have to use the task manager to kill the > process. The process is easily findable with the output of ps in any > other window. Very nice. That is an easy case to avoid. > >This all works really well. The problem I had is that at a couple > >points I want to run a command line on behalf of the user from inside > >the MSYS /bin/sh. To do that I need to restore that PATH to what it > >was before the win32 bk.exe messed with it. And in bk.exe I did the > >equivalent to this: > > > > > Have you tried just not worrying about it? MSYS should be able to > handle the win32ized PATH. It will convert it upon startup. > > > sprintf(buf "BK_OLDPATH=%s", getenv("PATH")); > > putenv(buf); > > > > ... create a new PATH in p ... > > sprintf(buf "PATH=%s", p); > > putenv(buf); > > > >So in bash, I have the original PATH I want to use, but it is a WIN32 > >PATH and is not useful. > > > >So at the moment I use this code: > > > > # On Windows convert the original Windows PATH variable to > > # something that will map the same in the shell. > > test "X$OSTYPE" = "Xmsys" && { > > BK_OLDPATH=$(echo $BK_OLDPATH | \ > > sed -e 's,\(.\):,/\1,g' -e 's,;,:,g' -e 's,\\,/,g') > > } > > > > PATH="$BK_OLDPATH" > > eval $EDITOR "$@" > > > > > > > But why do you need to do this? I don't understand the need. MSYS upon > dll initialization in process entry will convert PATH to POSIX format > and will convert it back to Win32 format when execing a non-MSYS > dependent (a.k.a. native) executable. I had two different PATH I needed to worry about. And internal PATH that most the scripts use, this is created by bk.exe and it puts the BitKeeper directory and the MSYS /bin at the start of the user's path. This is so that all the code that calls shell commands is sure to use the versions we ship. And we have the user's original PATH that I save in BK_OLDPATH. I only use that in a couple places when we want to run and command that the user provides. For example the path I show where I run an editor. I need to do a bunch of work to prepare files using the MSYS tools and the munged PATH, and then switch to the user's path an run 'vi'. If the user uses Cygwin, I want to run the Cygwin 'vi' and not pickup the MSYS one. Probably too much information. Oh well. > >Certainly we will do careful testing and try to feedback any bugfixes > >we make to the code. > > > Do you have an SF account? I would be more than happy to allow you to > improve MSYS. 'wscott' > >Q: How confortable do people feel about the stability of 1.0.10-rc4 > > running non-interactive code? Or should I use 1.0.9? > > > > > 1.0.10-rc-4 will become the 1.0.10 release version as soon as I get a > little time. No problem. I have had gotten other possible feedback from people on this version as well. -Wayne |
From: Earnie B. <ea...@us...> - 2004-02-13 14:08:50
|
Wayne Scott wrote: > >>But why do you need to do this? I don't understand the need. MSYS upon >>dll initialization in process entry will convert PATH to POSIX format >>and will convert it back to Win32 format when execing a non-MSYS >>dependent (a.k.a. native) executable. >> >> > >I had two different PATH I needed to worry about. And internal PATH >that most the scripts use, this is created by bk.exe and it puts the >BitKeeper directory and the MSYS /bin at the start of the user's path. >This is so that all the code that calls shell commands is sure to use >the versions we ship. And we have the user's original PATH that I >save in BK_OLDPATH. I only use that in a couple places when we want >to run and command that the user provides. For example the path I >show where I run an editor. I need to do a bunch of work to prepare >files using the MSYS tools and the munged PATH, and then switch to the >user's path an run 'vi'. If the user uses Cygwin, I want to run the >Cygwin 'vi' and not pickup the MSYS one. > >Probably too much information. Oh well. > > > Not at all too much information. I suggest that rather than munging PATH you use the location of the bk.exe binary to determine the path to your MSYS bin directory. This is how I determine the mount point path for /, /bin and /usr in MSYS itself. Check the Win32 API GetModuleFileName documentation for more on what I'm trying to say. However, you're trying to ensure that the msys /bin is first in PATH, alright I think I understand. On another note, I do warn that using Cygwin binaries from with MSYS is liable to cause you problems. I happen to know that at the moment the mount table that a Cygwin process uses if started from an MSYS process will be the one that MSYS has mapped. This should be able to fixed, I would love to have it work correctly. >>>Certainly we will do careful testing and try to feedback any bugfixes >>>we make to the code. >>> >>> >>> >>Do you have an SF account? I would be more than happy to allow you to >>improve MSYS. >> >> > >'wscott' > > > Ok, I'll add wscott to the MinGW project and ws...@bi... to the mingw-dvlpr list unless you prefer a different email for the list. Earnie. -- http://www.mingw.org http://sourceforge.net/projects/mingw https://sourceforge.net/donate/index.php?user_id=15438 |
From: Wayne S. <ws...@bi...> - 2004-02-13 14:50:36
|
From: Earnie Boyd <ea...@us...> > On another note, I do warn that using Cygwin binaries from with MSYS is > liable to cause you problems. I happen to know that at the moment the > mount table that a Cygwin process uses if started from an MSYS process > will be the one that MSYS has mapped. This should be able to fixed, I > would love to have it work correctly. Interesting. I just did some checking. I put this code in a bash script that I call using MSYS's bash from inside my bk binary. echo msys mounts mount echo cygwin mounts /c/cygwin/bin/bash -c mount PATH="$BK_OLDPATH" echo oldpath cygwin mounts /c/cygwin/bin/bash -c mount exit 0 Here is the output: msys mounts c:\bkwin\src\gnu\bin on /usr/bin type user (binmode,cygexec,noumount) c:\bkwin\src\gnu\bin on /bin type user (binmode,cygexec,noumount) c:\bkwin\src\gnu on / type user (binmode,noumount) c:\bkwin\src\gnu on /usr type user (binmode,noumount) a: on /a type user (binmode,noumount) c: on /c type user (binmode,noumount) d: on /d type user (binmode,noumount) e: on /e type user (binmode,noumount) cygwin mounts c:\bkwin\src\gnu\bin on /usr/bin type user (binmode,cygexec,noumount) c:\bkwin\src\gnu\bin on /bin type user (binmode,cygexec,noumount) c:\bkwin\src\gnu on / type user (binmode,noumount) c:\bkwin\src\gnu on /usr type user (binmode,noumount) a: on /a type user (binmode,noumount) c: on /c type user (binmode,noumount) d: on /d type user (binmode,noumount) e: on /e type user (binmode,noumount) oldpath cygwin mounts c:\cygwin\bin on /usr/bin type system (binmode) c:\cygwin\lib on /usr/lib type system (binmode) c:\cygwin on / type system (binmode) c:\foo on /mytmp type system (binmode) c: on /cygdrive/c type user (binmode,noumount) e: on /cygdrive/e type user (binmode,noumount) Notice that when I restore the PATH before calling at external program everything works correctly. So yes I see the bug you are talking about, but I appear to have dodged it. ;-) No... on further investigation, I think cygwin is restoring its mount table properly. It is just that in the second case I am running cygwin's bash, but msys's mount. This /c/cygwin/bin/bash -c /c/cygwin/bin/mount returns the expected output. It is irresponsible to run a cygwin program without restoring its directories to the path. Am I missing how to trigger the bug you are talking about? -Wayne |
From: Paul G. <pga...@co...> - 2004-02-13 00:11:59
|
Hey Wayne! This sounds great! On 12 Feb 2004 at 17:18, Wayne Scott wrote: > From: Olaf Flebbe <o.f...@sc...> > > You should not need such a thingy, because Msys automagically > > translates Path names, even in the environment. If you have a > > problem with this translation, you should try to describe your > > problem in more detail. > > OK. I have been meaning to do this anyway. Allow me to introduce > myself. I am one of the BitKeeper developers (http://bitmover.com) > and have been working on our Windows version. > > BitKeeper is a commercial revision control system that allows free use > by opensource developers with some restrictions. (see web page for > details) > > On Windows, BitKeeper is a Win32 application, but some parts of it are > written in Bourne shell and depends of POSIX utilities. Our current > version ships Cygwin along with BitKeeper and installs it for the > user. This has proven to be a pain because we have an external > dependency. The user cannot upgrade to a newer version of Cygwin > because they might break BitKeeper (this has happened) and you can't > have two different versions of Cygwin installed. > > So I started writing my own port of the Cygwin tools that would use a > different DLL so we could install it and use it independent of > whatever shell utilities the user might be using on their box. I also > wanted to change the directory mounting so it was hard coded to just > contain the current drives and a /bin that is determined by the > location of the DLL. And make all file access fixed in binary mode. > In short remove all dependencies on the Windows registry. > > Then I discovered that MSYS already meets all my requirements. So we > are planning on shipping an unmodified version of MSYS with BitKeeper > to use when running internal scripts. Users can use Cygnus tools or > whatever shell they want (including MSYS) to run BitKeeper. Before > running any internal scripts BitKeeper sets a PATH so that the MSYS > tools appear first. > > This all works really well. The problem I had is that at a couple > points I want to run a command line on behalf of the user from inside > the MSYS /bin/sh. To do that I need to restore that PATH to what it > was before the win32 bk.exe messed with it. And in bk.exe I did the > equivalent to this: > > sprintf(buf "BK_OLDPATH=%s", getenv("PATH")); > putenv(buf); > > ... create a new PATH in p ... > sprintf(buf "PATH=%s", p); > putenv(buf); > > So in bash, I have the original PATH I want to use, but it is a WIN32 > PATH and is not useful. > > So at the moment I use this code: > > # On Windows convert the original Windows PATH variable to > # something that will map the same in the shell. > test "X$OSTYPE" = "Xmsys" && { > BK_OLDPATH=$(echo $BK_OLDPATH | \ > sed -e 's,\(.\):,/\1,g' -e 's,;,:,g' -e 's,\\,/,g') > } > > PATH="$BK_OLDPATH" > eval $EDITOR "$@" > > In Cygwin, you would use the cygpath for this. > > > There. That is a long explanation, but that is why I asked the > question. But my sed solution seems to work and I don't _think_ it > will break. ;-) I think I can say that it won't break. That is the method used, if I recall correctly (corrections please!), to convert from existing "*nix" type paths to Win32 path notation in the Msys environment. > > > With all that out of the way on behalf of Bitmover I would like to > thank you guys for the MSYS code. We would like to contribute to the > community in any way possible. If you guys would like commercial > seats for BitKeeper to develop MSYS or MinGW let me know and I will > talk the sales guys into it. Need some web hosting? Let me know. > Something else? > > Certainly we will do careful testing and try to feedback any bugfixes > we make to the code. > > Q: How confortable do people feel about the stability of 1.0.10-rc4 > running non-interactive code? Or should I use 1.0.9? I feel much more comfortable about the stability of rc4 than I do about RC3. It is rc4 which I am using for my testing of Msys. RC4 seems to be responding just fine. As to Bitkeeper, I believe that, given BitKeepers inherent stability and the current BitKeeper architecture, rc4 is probably the most complimentary choice. Also, there has been little, if any mention of problems with rc4 here on the Msys mailing list. Paul G. |
From: Sam S. <sd...@gn...> - 2010-03-16 18:49:35
|
Olaf Flebbe wrote: > >> Cygwin comes with a 'cygpath' program to convert between POSIX and >> Windows pathnames. >> >> Does MSYS come with an equivalent. > > > You should not need such a thingy, because Msys automagically translates > Path names, even in the environment. If you have a problem with this > translation, you should try to describe your problem in more detail. if I have this (generated) makefile: ============== DIR=c:/a/b/c/d foo: $(DIR)/foo copy $(DIR)/foo foo ============== make barfs (multiple target patterns) because it cannot handle 2 colons on one line. the solution is to use an msys path /c/a/b/c/d instead if the windows path c:/a/b/c/d alas, there is no way to do the conversion without the ad hoc sed command (which is very easy to get wrong). |