Front page | perl.perl5.porters |
Postings from January 2005
Re: [perl #33948] configure checking echo
From:
Stephen
Date:
January 28, 2005 15:09
Subject:
Re: [perl #33948] configure checking echo
Message ID:
BAY0-SMTP0948D489041B0138E182599C790@phx.gbl
Maybe I could rename the file '/bin/echo.exe', Remember, I am still running
it from bash, so it should not matter that bash is running in Windows. The
version of echo is a part of msys and won't run outside of bash. I mean why
doesn't Configure get confused if someone is running Linux or Unix with only
a built-in echo and no executable? Mmmm, I'm gettng it now. Flex compiled
fine on msys without adding an extension. It still works when I call it from
bash. Anyone running a bash environment can get away with not using an
extention whether or not he is using Windows. The problem with msys may be
that it is the first program to embrace normal bash rules in a WIN env. When
would ignoring the ext cause problems?
Stephen
----- Original Message -----
From: "Andy Dougherty via RT" <perlbug-followup@perl.org>
To: <stecmccarthy@hotpop.com>
Sent: Friday, January 28, 2005 11:11 AM
Subject: Re: [perl #33948] configure checking echo
> On Fri, 28 Jan 2005, Stephen wrote:
>
>> Good point, if Configure excepts the existence of an echo file in /bin
>> for
>> the first test, but looks explicitly for /bin/echo.exe for the second
>> test,
>> Configure might be confusing itself by changing the criteria.
>
> Yes indeed. That's why I asked for the output of (that part of) Configure
> so I could see what it thought it found.
>
>> /bin/echo, if that helps to clarify things below. By the way isn't it
>> standard in Unix that an executable does not have to have an extention to
>> work, unlike in Windows?
>
> Yes, but on Windows the extension does matter, at least sometimes. If
> you are running a Unix-ish environment under Windows (which I now
> understand is the case here), then Configure tries to helpfully guess
> whether or not to append an .exe to the command names. This guess is
> stored in the Configure variable $_exe. That's apparently getting set
> to '.exe' in your case, probably due to this code in Configure:
>
> elif test -d c:/. -o -n "$is_os2" ; then
> : OS/2 or cygwin
> _exe=".exe"
>
> Then, later on, when Configure has found '/bin/echo', it unconditionally
> does
>
> eval $file=$xxx$_exe
>
> (where file='echo' and xxx=/bin/echo). In short, since you're on
> Windows, Configure expects the 'echo' command to be called echo.exe,
> not just a plain 'echo'.
>
> fine for everyone else all these years. I don't really know if that
> $_exe is really required, nor do I know what would happen if we dropped
> the $_exe there. I suppose we could try it and see, but the current
> version has been working well for many years for at least some users,
> so we do have to be careful.
>
> I suppose we could put in some sort of additional test -f $xxx$_exe
> before unconditionally setting the variable. That would
> probably be safe and wouldn't break anything.
>
> --
> Andy Dougherty doughera@lafayette.edu
>
>