From: <mai...@we...> - 2006-02-08 08:15:19
|
Hi, I installed a new version of msys (1.0.11) and suddenly my shell and the commands like sed append a .exe to filenames automatically. There is one line in libtool that checks with sed if some string is contained in the wrapper: $ /bin/sed -e '4q' idl #! /bin/sh # idl - temporary wrapper script for .libs/idl.exe # Generated by ltmain.sh - GNU libtool 1.5.18 (1.1220.2.246 2005/05/16 10:00:18) The file "idl" is not existing, but the file "idl.exe". This leads to an error because libtool now starts configuring itself to append a dot to the filename for some reason. It does not find idl.exe any more. The behavior of the msys version 1.0.10 is the following: $ /mingw/bin/sed -e '4q' idl /mingw/bin/sed: can't read idl: No such file or directory This makes libtool doing nothing and work properly. Can I configure msys 1.0.11 to behave as 1.0.10? Marc |
From: Earnie B. <ea...@us...> - 2006-02-08 13:04:52
|
Quoting Marc H=C3=B6per <mai...@we...>: > > Hi, > > I installed a new version of msys (1.0.11) and suddenly my shell and the > commands like sed append a .exe to filenames automatically. > This is always done, regardless of the version of MSYS. > There is one line in libtool that checks with sed if some string is > contained in the wrapper: > > $ /bin/sed -e '4q' idl > #! /bin/sh > > # idl - temporary wrapper script for .libs/idl.exe > # Generated by ltmain.sh - GNU libtool 1.5.18 (1.1220.2.246 2005/05/16 > 10:00:18) > > The file "idl" is not existing, but the file "idl.exe". This leads to an > error because libtool now starts configuring itself to append a dot to > the filename for some reason. It does not find idl.exe any more. > > The behavior of the msys version 1.0.10 is the following: > > $ /mingw/bin/sed -e '4q' idl > /mingw/bin/sed: can't read idl: No such file or directory > And this is what I get with 1.0.11. > This makes libtool doing nothing and work properly. > > Can I configure msys 1.0.11 to behave as 1.0.10? > I don't believe this to be an MSYS issue. It is something in your environment or build that isn't working? What else did you upgrade? Did you reexecute configure after upgrading? The 1.0.11 snapshot is over a year old. I use it daily and if something were wrong, I would know by now. Earnie Boyd ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: <mai...@we...> - 2006-02-08 14:38:17
|
Hi Earnie Earnie Boyd schrieb: >> The behavior of the msys version 1.0.10 is the following: >> >> $ /mingw/bin/sed -e '4q' idl >> /mingw/bin/sed: can't read idl: No such file or directory >> > > And this is what I get with 1.0.11. I just installed MSys 1.0.11 into another directory with the exe-installer from the download page. I did no configuration and skipped the postinstall. And this happens: $ sed -e '4q' /bin/md5sum MZÿÿ¸@€º´ Í!¸LÍ!This program cannot be run in DOS mode. $PELpD<à p@ X.text4^` `.dataXpd@À.bss<€€À.idataXf@ÀU‰åƒìƒ=p@tÌÙ}þ·Eþ%Àðÿÿf‰Eþ·?f‰EþÙmþƒÄôhH"@è[ÉÃû@bõ@cî@ç@â@tÝ@wØ@úÐ@ûversionhelpwarntextstringstatuscheckbinaryTry `%s --help' for more information. Usage: %s [OPTION] [FILE]... or: %s [OPTION] --check [FILE] sed obviously found md5sum although it has an .exe suffix. I wonder why our installations differ in this case. > I don't believe this to be an MSYS issue. It is something in your > environment or build that isn't working? What else did you upgrade? > Did you reexecute configure after upgrading? The 1.0.11 snapshot is > over a year old. I use it daily and if something were wrong, I would > know by now. Is there some msys environment switch that I should tune? Marc |
From: <mai...@we...> - 2006-02-08 19:48:43
|
Marc Höper schrieb: > Earnie Boyd schrieb: >>> The behavior of the msys version 1.0.10 is the following: >>> >>> $ /mingw/bin/sed -e '4q' idl >>> /mingw/bin/sed: can't read idl: No such file or directory >>> >> >> And this is what I get with 1.0.11. > > I just installed MSys 1.0.11 into another directory with the > exe-installer from the download page. I did no configuration and skipped > the postinstall. And this happens: > > $ sed -e '4q' /bin/md5sum > MZÿÿ¸@€º´ Í!¸LÍ!This program cannot be run in DOS mode. > $PELpD<à > > p@ > X.text4^` `.dataXpd@À.bss<€€À.idataXf@ÀU‰åƒìƒ=p@tÌÙ}þ·Eþ%Àðÿÿf‰Eþ·?f‰EþÙmþƒÄôhH"@è[ÉÃû@bõ@cî@ç@â@tÝ@wØ@úÐ@ûversionhelpwarntextstringstatuscheckbinaryTry > > `%s --help' for more information. > Usage: %s [OPTION] [FILE]... > or: %s [OPTION] --check [FILE] > > sed obviously found md5sum although it has an .exe suffix. I wonder why > our installations differ in this case. > I tried the same with MSys 1.0.10. Installed it into a new directory with the exe-installer and I did no configuration and skipped the post install. This is what happens with the command I used above: $ /bin/sed -e '4q' /bin/md5sum /bin/sed: can't read /bin/md5sum: No such file or directory sed did not find the executable, because it's name actually is md5sum.exe. Using sed is only an example. /bin/sh behaves in the same manner. Marc |
From: Earnie B. <ea...@us...> - 2006-02-08 22:59:51
|
Quoting Marc H=C3=B6per <mai...@we...>: > > Hi Earnie > Hi Marc, If you want personal help we can discuss a contract; otherwise keep your posts on the list. > Earnie Boyd schrieb: >>> The behavior of the msys version 1.0.10 is the following: >>> >>> $ /mingw/bin/sed -e '4q' idl >>> /mingw/bin/sed: can't read idl: No such file or directory >>> >> >> And this is what I get with 1.0.11. > > I just installed MSys 1.0.11 into another directory with the > exe-installer from the download page. I did no configuration and > skipped the postinstall. And this happens: > > $ sed -e '4q' /bin/md5sum MZ=C2=90=C3=BF=C3=BF=C2=B8@=E2=82=AC=C2=BA= =C2=B4 =C3=8D!=C2=B8L=C3=8D!This > program cannot be run in DOS mode. > $PELpD<=C3=A0 > p@ =C2=90X.text4^` > `.dataXpd@=C3=80.bss<=E2=82=AC=E2=82=AC=C3=80.idataX=C2=90f@=C3=80U=E2=80= =B0=C3=A5=C6=92=C3=AC=C6=92=3Dp@t=C3=8C=C3=99}=C3=BE=C2=B7E=C3=BE%=C3=80=C3= =B0=C3=BF=C3=BFf=E2=80=B0E=C3=BE=C2=B7?f=E2=80=B0E=C3=BE=C3=99m=C3=BE=C6=92= =C3=84=C3=B4hH"@=C3=A8[=C3=89=C3=83=C2=90=C3=BB@b=C3=B5@c=C3=AE@=C3=A7@=C3= =A2@t=C3=9D@w=C3=98@=C3=BA=C3=90@=C3=BBversionhelpwarntextstringstatuscheck= binary=C2=90=C2=90=C2=90=C2=90=C2=90=C2=90=C2=90=C2=90=C2=90=C2=90=C2=90=C2= =90=C2=90=C2=90=C2=90=C2=90=C2=90=C2=90=C2=90=C2=90=C2=90=C2=90=C2=90=C2=90= =C2=90=C2=90=C2=90=C2=90=C2=90=C2=90Try `%s --help' for more > information. > =C2=90=C2=90=C2=90=C2=90=C2=90=C2=90=C2=90=C2=90=C2=90=C2=90=C2=90=C2=90= =C2=90=C2=90=C2=90=C2=90=C2=90=C2=90=C2=90=C2=90=C2=90=C2=90=C2=90=C2=90=C2= =90Usage: %s [OPTION] [FILE]... > or: %s [OPTION] --check [FILE] > > sed obviously found md5sum although it has an .exe suffix. I wonder > why our installations differ in this case. > And it would have done this in any version of MSYS. The Cygwin base code I used for MSYS treats /bin/md5sum as a symlink to /bin/md5sum.exe. >> I don't believe this to be an MSYS issue. It is something in your >> environment or build that isn't working? What else did you upgrade? >> Did you reexecute configure after upgrading? The 1.0.11 snapshot >> is over a year old. I use it daily and if something were wrong, I >> would know by now. > > Is there some msys environment switch that I should tune? > No. But if you add a period as the last character of the file e.g. sed -e '4q' /bin/md5sum. then it will not find /bin/md5sum.exe. Earnie Boyd ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: <mai...@we...> - 2006-02-09 08:00:19
|
Earnie Boyd schrieb: > If you want personal help we can discuss a contract; otherwise keep > your posts on the list. Sorry. Didn't sent the mail to your private account by intention. I will take care that I keep my posts on the list in the future. >> Earnie Boyd schrieb: >>>> The behavior of the msys version 1.0.10 is the following: >>>> >>>> $ /mingw/bin/sed -e '4q' idl >>>> /mingw/bin/sed: can't read idl: No such file or directory >>>> >>> >>> And this is what I get with 1.0.11. >> >> I just installed MSys 1.0.11 into another directory with the >> exe-installer from the download page. I did no configuration and >> skipped the postinstall. And this happens: >> >> $ sed -e '4q' /bin/md5sum MZÿÿ¸@€º´ Í!¸LÍ!This program >> cannot be run in DOS mode. >> $PELpD<à >> p@ X.text4^` `.dataXpd@À.bss<€€À.idataXf@ÀU‰åƒìƒ=p@tÌÙ}þ·Eþ%Àðÿÿf‰Eþ·?f‰EþÙmþƒÄôhH"@è[ÉÃû@bõ@cî@ç@â@tÝ@wØ@úÐ@ûversionhelpwarntextstringstatuscheckbinaryTry >> `%s --help' for more information. >> Usage: %s [OPTION] [FILE]... >> or: %s [OPTION] --check [FILE] >> >> sed obviously found md5sum although it has an .exe suffix. I wonder >> why our installations differ in this case. >> > > And it would have done this in any version of MSYS. The Cygwin base > code I used for MSYS treats /bin/md5sum as a symlink to /bin/md5sum.exe. And this is not the case. As I wrote my last installation for which I have just used the MSys installer 1.0.10 did not find this file: $ /bin/sed -e '4q' /bin/md5sum /bin/sed: can't read /bin/md5sum: No such file or directory Can somebody verify this behaviour? Marc |
From: Keith M. <kei...@to...> - 2006-02-09 10:28:33
|
Marc H=F6per wrote: > $ /bin/sed -e '4q' /bin/md5sum > /bin/sed: can't read /bin/md5sum: No such file or directory > > Can somebody verify this behaviour? Marc, Confirmed. This is exactly what I see, with msys-1.0.10. Also, like you, I see broken behaviour with msys-1.0.11. Earnie, This is definitely a bug in msys-1.0.11. It is correct that `.exe' should be appended while seeking a match for argv[0] *only*; it should *never* be appended to argv[n] for n > 0. Repeating Marc's sample sed command, it is clear that /bin/md5sum.exe is found to match argv[2], in msys-1.0.11, but it isn't considered in msys-1.0.10. The msys-1.0.10 behaviour is correct; the msys-1.0.11 behaviour is inappropriate. BTW, I have never felt the need to upgrade from msys-1.0.10 on my main working system; v1.0.10 does everything I need, and is stable. The only change I have made is to replace msys.bat with the current CVS version, (to get the `-norxvt' feature). Otherwise, `if it ain't broke, don't fix it'! Regards, Keith. |
From: <mai...@we...> - 2006-02-09 11:50:23
|
Keith, Keith MARSHALL schrieb: > Marc Höper wrote: > >> $ /bin/sed -e '4q' /bin/md5sum >> /bin/sed: can't read /bin/md5sum: No such file or directory >> >> Can somebody verify this behaviour? >> > Confirmed. This is exactly what I see, with msys-1.0.10. Also, like > you, I see broken behaviour with msys-1.0.11. > Very good. I already felt like being unable to run an exe installer :-) > BTW, I have never felt the need to upgrade from msys-1.0.10 on my main > working system; v1.0.10 does everything I need, and is stable. The only > change I have made is to replace msys.bat with the current CVS version, > (to get the `-norxvt' feature). Otherwise, `if it ain't broke, don't > fix it'! > Actually, I only updated because of the resize freeze problem. Is the update of msys.bat sufficient to work around the bug? Marc |
From: Earnie B. <ea...@us...> - 2006-02-09 12:11:53
|
Quoting Marc H=F6per <mai...@we...>: > > Actually, I only updated because of the resize freeze problem. Is the > update of msys.bat sufficient to work around the bug? > No. You would need the libW11.dll from the 1.0.11 package to fix that. Earnie Boyd ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Keith M. <kei...@to...> - 2006-02-09 14:33:10
|
Marc H=F6per wrote, quoting me: >> BTW, I have never felt the need to upgrade from msys-1.0.10 on my main >> working system; v1.0.10 does everything I need, and is stable. The=20 only >> change I have made is to replace msys.bat with the current CVS version, >> (to get the `-norxvt' feature). Otherwise, `if it ain't broke, don't >> fix it'! >=20 > Actually, I only updated because of the resize freeze problem. Is the=20 > update of msys.bat sufficient to work around the bug? As Earnie has already pointed out: > No. You would need the libW11.dll from the 1.0.11 package to fix that. Note that my reason for using the more recent msys.bat is to have the `-norxvt' feature. MSYS rxvt has some known problems, which unfortunately make it too unreliable for my use; therefore, I have not used MSYS rxvt for some time now. This particular extension bug in msys-1.0.11 is evident, regardless of whether sh.exe is run in a native Win32 console, or via rxvt. Regards, Keith. |
From: Earnie B. <ea...@us...> - 2006-02-09 22:02:01
|
Quoting Keith MARSHALL <kei...@to...>: > > This is definitely a bug in msys-1.0.11. It is correct that `.exe' > should be appended while seeking a match for argv[0] *only*; it should > *never* be appended to argv[n] for n > 0. > So you think it is wrong for ``ls /bin/ls'' to return a positive result? Earnie Boyd ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Keith M. <kei...@to...> - 2006-02-10 10:11:29
|
Earnie Boyd wrote, quoting me: >> This is definitely a bug in msys-1.0.11. It is correct that `.exe' >> should be appended while seeking a match for argv[0] *only*; it should >> *never* be appended to argv[n] for n > 0. > > So you think it is wrong for ``ls /bin/ls'' to return a positive result? Yes, actually I do. There is no such file, and ls should not lie about this. The name of the file is /bin/ls.exe, and ls should be required to report it, only when searching for a prototype which will match that in full. cmd.exe's `dir ls', (in the native path equivalent of /bin), will say "File not found", and ls itself should do likewise. IMHO, the only place for automatic extension of a file name, by addition of the `.exe' suffix, is when searching for a command to execute; that is restricted to the processing of argv[0], and when searching the PATH for potential matches for the arguments of `type -p ...'. At the moment, I can't think of any other place where it might be appropriate. And, on this basis, msys-1.0.10 is also broken, for $ test -f /bin/ls && echo yes yes is a downright lie; (I *should* need `test -f /bin/ls.exe'). Regards, Keith. |
From: Earnie B. <ea...@us...> - 2006-02-10 14:22:11
|
Quoting Keith MARSHALL <kei...@to...>: > Earnie Boyd wrote, quoting me: >>> This is definitely a bug in msys-1.0.11. It is correct that `.exe' >>> should be appended while seeking a match for argv[0] *only*; it should >>> *never* be appended to argv[n] for n > 0. >> >> So you think it is wrong for ``ls /bin/ls'' to return a positive result? > > Yes, actually I do. There is no such file, and ls should not lie about > this. The name of the file is /bin/ls.exe, and ls should be required to > report it, only when searching for a prototype which will match that in > full. cmd.exe's `dir ls', (in the native path equivalent of /bin), will > say "File not found", and ls itself should do likewise. > Well, it ain't changin` soon. It is a part of the meat of the Cygwin base code for the stat function. There would be a lot of rewrite to get that accomplished. I've already looked at the pieces of code that would need to change and know that it is more work that I want to take on. I've heavily documented some of the pieces of code I've tried to remove and caused a broken MSYS. > IMHO, the only place for automatic extension of a file name, by addition > of the `.exe' suffix, is when searching for a command to execute; that is > restricted to the processing of argv[0], and when searching the PATH for > potential matches for the arguments of `type -p ...'. At the moment, I > can't think of any other place where it might be appropriate. > > And, on this basis, msys-1.0.10 is also broken, for > > $ test -f /bin/ls && echo yes > yes > > is a downright lie; (I *should* need `test -f /bin/ls.exe'). > The Cygwin code treats foo as a symlink to foo.exe if foo.exe exists. Although I was able to disable symlink emulation, the pseudo symlink of foo points to foo.exe isn't easy to get rid of. Earnie Boyd ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Keith M. <kei...@to...> - 2006-02-10 16:01:21
|
Earnie Boyd wrote, quoting me: >>> So you think it is wrong for ``ls /bin/ls'' to return a >>> positive result? >> >> Yes, actually I do. There is no such file, and ls should not lie >> about this. The name of the file is /bin/ls.exe, and ls should be >> required to report it, only when searching for a prototype which >> will match that in full. cmd.exe's `dir ls', (in the native path >> equivalent of /bin), will say "File not found", and ls itself >> should do likewise. > > Well, it ain't changin` soon. Pity, for it does give rise to some seriously odd behaviour. > It is a part of the meat of the Cygwin base code for the > stat function. And indeed, it is broken in Cygwin too. >> $ test -f /bin/ls && echo yes >> yes >> >> is a downright lie; (I *should* need `test -f /bin/ls.exe'). > > The Cygwin code treats foo as a symlink to foo.exe if foo.exe > exists. Although I was able to disable symlink emulation, the > pseudo symlink of foo points to foo.exe isn't easy to get rid of. Hmm. Cygwin *doesn't* misbehave like this: $ PATH=.:$PATH $ mkdir junk $ type -p junk ./junk And this could be *really* troublesome: $ gcc -o hello hello.c $ ls -dF hello* hello.c hello.exe* $ type -ap hello ./hello $ type -p hello ./hello $ hello Hello world. $ mkdir hello $ ls -dF hello* hello/ hello.c hello.exe* $ type -ap hello $ type -p hello ./hello $ hello sh: ./hello: is a directory $ rmdir hello $ hello Hello world. $ echo 'echo hello.exe is hidden' > hello $ ls -dF hello* hello hello.c hello.exe* $ type -ap hello $ type -p hello ./hello $ hello hello.exe is hidden Note how, when *both* `hello' and `hello.exe' exist, even when `hello' is a directory, `type -ap hello' incorrectly produces no output. Also, when `hello' exists as a directory, the shell still tries to execute it, instead of just executing `hello.exe'; this cannot be right. Even treating the `hello' text file as executable, without requiring it to be shebanged, is probably questionable, and indeed `ls -dF hello*' doesn't flag it as such, (but it *does*, when the shebang is inserted). BTW, Cygwin isn't faultless either; in the version I have: $ bash --version GNU bash, version 2.05b.0(2)-release (i686-pc-cygwin) Copyright (C) 2002 Free Software Foundation, Inc. $ ls --version ls (fileutils) 4.1 : $ ls -dF hello* hello* hello.c* hello.exe* $ type -ap hello ./hello $ rm hello $ ls -dF hello* hello.c* hello.exe* $ type -ap hello ./hello Although Cygwin's `type -ap hello' does produce output when both `hello' and `hello.exe' are present, it fails to recognise that the two are distinct. Furthermore, neither in Cygwin nor in MSYS does `type -p hello' correctly report the name of the executable, when it is actually `hello.exe'. And what's the deal with Cygwin's `ls' flagging `hello.c' as an executable? (But the Cygwin I have installed is really quite old -- perhaps some of this has been fixed in a more recent release). Regards, Keith. |
From: Keith M. <kei...@us...> - 2006-02-11 15:48:53
|
Yesterday I wrote, quoting Earnie Boyd: > > The Cygwin code treats foo as a symlink to foo.exe if foo.exe > > exists. Although I was able to disable symlink emulation, the > > pseudo symlink of foo points to foo.exe isn't easy to get rid of. Actually, the behaviour is much closer to that which would be observed with a *hard* link, rather than with a symlink. > [examples of improper `type -[a]p ...' behaviour snipped] > > Note how, when *both* `hello' and `hello.exe' exist, even when > `hello' is a directory, `type -ap hello' incorrectly produces no > output. Also, when `hello' exists as a directory, the shell still > tries to execute it, instead of just executing `hello.exe'; this > cannot be right. Even treating the `hello' text file as executable, > without requiring it to be shebanged, is probably questionable, and > indeed `ls -dF hello*' doesn't flag it as such, (but it *does*, > when the shebang is inserted). As a consequence of my experimentation with this, I've provided a new version of the MSYS `which' command: http://cvs.sourceforge.net/viewcvs.py/mingw/msys/dvlpr/bin/which?rev=1.2&view=log 2006.02.11 Keith Marshall <keithmarshall@address.hidden> * bin/which: Rewritten to:-- Handle `-a' and equivalent `--all' options; Provide `missing argument' and `usage' diagnostics; Preserve `.exe' extensions on matched command file names; Avoid matching directory names as possible command names; Provide `unknown command' diagnostic; Set explicit status code on exit. I've tested it under Win2K-SP4, and -- believe it or not -- under GNU/Linux, (which is where I observe the hard link like behaviour, rather than symlink like). If anyone would like to test it under other flavours of Win32, I'd appreciate the feedback. Regards, Keith. |
From: Greg C. <chi...@co...> - 2006-02-11 16:49:11
|
On 2006-2-11 15:56 UTC, Keith Marshall wrote: > Yesterday I wrote, quoting Earnie Boyd: > >>[examples of improper `type -[a]p ...' behaviour snipped] >> >>Note how, when *both* `hello' and `hello.exe' exist, even when >>`hello' is a directory, `type -ap hello' incorrectly produces no >>output. Also, when `hello' exists as a directory, the shell still >>tries to execute it, instead of just executing `hello.exe'; this >>cannot be right. Even treating the `hello' text file as executable, >>without requiring it to be shebanged, is probably questionable, and >>indeed `ls -dF hello*' doesn't flag it as such, (but it *does*, >>when the shebang is inserted). > > As a consequence of my experimentation with this, I've provided a new > version of the MSYS `which' command: > http://cvs.sourceforge.net/viewcvs.py/mingw/msys/dvlpr/bin/which?rev=1.2&view=log I downloaded that, replacing the original here. > I've tested it under Win2K-SP4, and -- believe it or not -- under > GNU/Linux, (which is where I observe the hard link like behaviour, rather > than symlink like). If anyone would like to test it under other flavours > of Win32, I'd appreciate the feedback. OS Name Microsoft Windows XP Home Edition Version 5.1.2600 Service Pack 1 Build 2600 Tests adapted from Keith's posting of 2006-02-10T16:00Z. ~[0]$echo $PS1 \w[$?]$ ~[0]$ls hello* hello.c ~[0]$gcc -o hello hello.c ~[0]$which hello* ./hello.c ./hello.exe ~[0]$hello Hello, world! ~[0]$mkdir hello ~[0]$which hello which: hello: unknown command ~[1]$which hello* which: hello: unknown command ./hello.c ./hello.exe ~[1]$type -p hello ./hello ~[0]$./hello sh: ./hello: is a directory ~[127]$hello sh: ./hello: is a directory ~[127]$type -ap hello ~[1]$rmdir hello ~[0]$hello Hello, world! ~[0]$echo 'echo hello.exe is hidden' > hello ~[0]$which hello ./hello ~[0]$./hello hello.exe is hidden ~[0]$hello hello.exe is hidden ~[0]$ [I have renamed 'rxvt.exe'] ~[0]$msysinfo msysinfo-1.3: Send this to the MSYS support list: MSYS 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown; targ=MINGW32 GNU bash, version 2.04.0(1)-release (i686-pc-msys); ENV=.profile GNU Make version 3.79.1,Built for i686-pc-msys; MAKE_MODE=unix gcc.exe (GCC) 3.4.5 (mingw special); targ=MINGW32 GNU ld version 2.16.91 20060119 789320 Tue Mar 16 17:32:49 2004 /bin/msys-1.0.dll 52064 Thu Jan 02 12:05:27 2003 /bin/msysltdl-3.dll 135680 Tue Mar 16 17:32:48 2004 /bin/make.exe 89600 Wed Jan 18 19:06:00 2006 /mingw/bin/gcc.exe 685568 Fri Jan 20 05:41:43 2006 /mingw/bin/ld.exe HOME=/home/chicares Sysname=MINGW32_NT-5.1 OSTYPE=msys TERM=cygwin PATH=.:/usr/local/bin:/mingw/bin:/bin:/c/usr/bin:/c/usr/local/bi n:/c/usr/local/lib:/c/WINDOWS/system32:/c/WINDOWS $ ls -tx /home/chicares hello hello.exe* hello.c .bash_history lmi/ .profile boost_path_test.exe* boost_filesystem.dll* libboost_filesystem_dll.a boost_path_test.cpp .inputrc .bak eraseme-.bak inputrc.bak rcs2log* rcs2log.sh* .xyz/ .ssh/ ~[0]$ |
From: Keith M. <kei...@us...> - 2006-02-11 18:54:50
|
On Saturday 11 February 2006 4:48 pm, Greg Chicares wrote: > OS Name Microsoft Windows XP Home Edition > Version 5.1.2600 Service Pack 1 Build 2600 > > Tests adapted from Keith's posting of 2006-02-10T16:00Z. [results snipped] Thanks for testing this, Greg. Your results agree with mine. One possible contention: the presence of a directory with the same base name as an executable hides the executable, yielding an `unknown command' diagnostic from this `which' implementation. It would not be too difficult to extend the implementation, to detect this anomaly and display the `.exe' name, (but perhaps only when `which --all ...' is specified). However, I wonder if it would be really worthwhile, given that the command could not be executed anyway, without fully specifying the executable name. Any thoughts? Preferences? Regards, Keith. |
From: Luke D. <cod...@ho...> - 2006-02-08 14:12:57
|
----- Original Message ----- From: "Marc Höper" <mai...@we...> To: <min...@li...> Sent: Wednesday, February 08, 2006 4:15 PM Subject: [Mingw-msys] Automatic append of .exe in msys 1.0.11 > > Hi, > > I installed a new version of msys (1.0.11) and suddenly my shell and the > commands like sed append a .exe to filenames automatically. > > There is one line in libtool that checks with sed if some string is > contained in the wrapper: > > $ /bin/sed -e '4q' idl > #! /bin/sh > > # idl - temporary wrapper script for .libs/idl.exe > # Generated by ltmain.sh - GNU libtool 1.5.18 (1.1220.2.246 2005/05/16 > 10:00:18) > > The file "idl" is not existing, but the file "idl.exe". This leads to an > error because libtool now starts configuring itself to append a dot to > the filename for some reason. It does not find idl.exe any more. > > The behavior of the msys version 1.0.10 is the following: > > $ /mingw/bin/sed -e '4q' idl > /mingw/bin/sed: can't read idl: No such file or directory Why "/mingw/bin/sed"? Clearly that is not MSYS /bin/sed so I don't think it tells us anything. Luke > > This makes libtool doing nothing and work properly. > > Can I configure msys 1.0.11 to behave as 1.0.10? > > Marc |
From: <mai...@we...> - 2006-02-08 14:33:36
|
Luke Dunstan schrieb: >> The behavior of the msys version 1.0.10 is the following: >> >> $ /mingw/bin/sed -e '4q' idl >> /mingw/bin/sed: can't read idl: No such file or directory > > Why "/mingw/bin/sed"? Clearly that is not MSYS /bin/sed so I don't > think it tells us anything. Oops. But the result when using the MSYS /bin/sed is the same: $ /bin/sed -e '4q' /bin/md5sum /bin/sed: can't read /bin/md5sum: No such file or directory Marc |
From: Earnie B. <ea...@us...> - 2006-02-09 21:58:49
|
Quoting Marc H=C3=B6per <mai...@we...>: > > Hi, > > I installed a new version of msys (1.0.11) and suddenly my shell and the > commands like sed append a .exe to filenames automatically. > > There is one line in libtool that checks with sed if some string is > contained in the wrapper: > Please give me the package name and a download link that you are building. Earnie Boyd ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Earnie B. <ea...@us...> - 2006-02-10 13:17:30
|
Quoting Marc H=C3=B6per <mai...@we...>: > > Hi, > > I installed a new version of msys (1.0.11) and suddenly my shell and the > commands like sed append a .exe to filenames automatically. > This isn't your problem at all. > There is one line in libtool that checks with sed if some string is > contained in the wrapper: > > $ /bin/sed -e '4q' idl > #! /bin/sh > > # idl - temporary wrapper script for .libs/idl.exe > # Generated by ltmain.sh - GNU libtool 1.5.18 (1.1220.2.246 2005/05/16 > 10:00:18) > > The file "idl" is not existing, but the file "idl.exe". This leads to an > error because libtool now starts configuring itself to append a dot to > the filename for some reason. It does not find idl.exe any more. > > The behavior of the msys version 1.0.10 is the following: > > $ /mingw/bin/sed -e '4q' idl > /mingw/bin/sed: can't read idl: No such file or directory > Sed isn't your problem either. > This makes libtool doing nothing and work properly. > The problem is that the make/libtool relationships for shared libraries cause an issue. During the ``make'' process libtool causes make to create src/.libs/foo.exe and src/foo if shared libraries are enabled. During the ``make install'' process make doesn't see src/foo.exe and thinks it needs to make it again. The result is that the previous src/foo becomes src/foo.exe and libtool want's src/foo to exist for the install command. The result is that you do not get your foo.exe installed. An ugly workaround is to copy the src/.libs/foo.exe to src/ before executing ``make install''. This is ok for a simple tree but sucks beyond one or two binaries being installed. Earnie Boyd ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: <mai...@we...> - 2006-02-10 22:18:58
|
Earnie Boyd schrieb: > Quoting Marc Höper <mai...@we...>: >> I installed a new version of msys (1.0.11) and suddenly my shell and the >> commands like sed append a .exe to filenames automatically. >> > > This isn't your problem at all. [...] > Sed isn't your problem either. > >> This makes libtool doing nothing and work properly. >> > > The problem is that the make/libtool relationships for shared > libraries cause an issue. Agreed. The make/libtool is the problem why I started debugging the scripts. But this is off-topic here. I wrote to this list, because I found the difference in the behaviour between MSys 1.0.10 and 1.0.11 while looking for the failure. > During the ``make'' process libtool causes make to create > src/.libs/foo.exe and src/foo if shared libraries are enabled. During > the ``make install'' process make doesn't see src/foo.exe and thinks > it needs to make it again. The result is that the previous src/foo > becomes src/foo.exe and libtool want's src/foo to exist for the > install command. The result is that you do not get your foo.exe > installed. > > An ugly workaround is to copy the src/.libs/foo.exe to src/ before > executing ``make install''. This is ok for a simple tree but sucks > beyond one or two binaries being installed. Thank you for the hint. I'll first go back to MSys 1.0.10 where everything but the window resize worked fine and update libW11.dll. Thank you all for your support. Marc |