From: Andrew B. <ab...@cs...> - 2002-04-27 08:02:06
|
So I ended up writing a really simple pwd program that simply calls _getcwd(), converts the backslashes to forward slashes and returns it. Then I modified my script to mess with the shell variables that need to be in DOS format like so: FOOBAR=/c/some/msys/path OLDDIR=`pwd`; cd $FOOBAR; FOOBAR=`mypwd.exe`; cd $OLDDIR and that seems to work fine for me. Thanks for your help. Now, when sed works, I'll truly be happy. :) Andrew On Friday, April 26, 2002, at 11:33 AM, Earnie Boyd wrote: > Andrew Begel wrote: >> >> On Friday, April 26, 2002, at 03:57 AM, Earnie Boyd wrote: >> >>> Andrew Begel wrote: >>>> >>>> I wrote a path into a bash shell var: >>>> >>>> #!/bin/sh >>>> >>>> LOADPATH=/h/foo/bar >>>> >>> >>> What happens if you LOADPATH=h:/foo/bar? >> >> If I change LOADPATH to a DOS path like that, then it works fine. >> Unfortunately, my scripts are a bit more complicated. There's a first >> script that does: >> >> export HARMONIA_HOME /h/harmonia/src (actually uses pwd and ls and >> friends to figure it out) >> >> exec $HARMONIA_HOME/second-script.sh >> >> and the second script does >> >> LOADPATH=$HARMONIA_HOME/lib/xemacs >> >> so, it's not so easy to fix without munging this (supposedly) >> platform-independent script (should act the same on windows and unix). >> > > It's not going to be easy. It sounds as if you need to provide yourself > a mingw version of pwd and disable the pwd shell builtin version. Then > the conversion would happen from the pwd command. > >>> >>>> and then I used it in an exec string: >>>> >>>> exec "/e/xemacs/xemacs-21.4/src/xemacs" -eval \ >>>> "(setq load-path (cons \"$LOADPATH\" load-path))" $rest >>>> >>>> When I look at what XEmacs shows for the value of load-path, it's in >>>> MSYS form (posix-ish), rather than Windows (drive letter, colon, >>>> path). >>>> >>>> How can I fix this? I want the path to be passed to exec as a Windows >>>> path, not an MSYS one. >>>> >>> >>> If the above suggestion doesn't work for you then I'll supply a >>> different workaround. Eventually the environment variables will be >>> converted as well. >> >> What's the other workaround? I did try (getenv "LOADPATH") from within >> XEmacs, but this got the same msys path too. >> > > It was to provide a means to translate the path, which would require > munging the script. :) The mingw version of pwd should as if it would > be the better solution. Alternatively, I'm working right now on adding > a -W option to bashes pwd builtin that'll return the Win32 path, once > that's in place you could alias pwd to `pwd -W'. > >> How will convert the env variables? theoretically, I could have a >> script >> that wants to concat two env variables together to form a new msys >> path; >> how would you know not to convert them then? or would it not matter >> unless you were messing with the / at the beginning of the first path? >> > > The environment would be munged only for the spawned win32 child process > so the result of your concatenations would have already taken place > before the conversion. However, this probably won't happen until next > year. Before that happens I need to do an msysDTK package and an > msysDVLPR package so that for one thing, others can help me develop > MSYS. After those packages are delivered I need to take a sabbatical > from MSYS. > > Earnie. > > _______________________________________________ > Mingw-msys mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-msys > ----------- Andrew Begel Ph.D. Candidate Computer Science Division University of California, Berkeley |