Re: [PATCH 2/4] AC_SITE_LOAD: add OS/2-specific initialization

KO Myung-Hun <[email protected]>
Newsgroups gmane.comp.sysutils.autoconf.patches
Message-ID <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Eric Blake wrote:
> On 09/22/2014 08:39 PM, KO Myung-Hun wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> Hi/2.
>> 
>> Eric Blake wrote:
>>> On 09/22/2014 12:59 AM, KO Myung-Hun wrote:
>>>> \ may be recognized as an escape character on some shells
>>>> such as pdksh. And the executables on OS/2 have .exe as an
>>>> extension.
>>> 
>>> Umm, \ is an escape character on ALL sh-related shells.  And
>>> .exe handling on OS/2 should behave as it does on mingw.
>>> 
>> 
>> Sorry, my change log was not enough somewhat. I meant 'echo'. At 
>> least, echo of pdksh treats \ as an escape char without -E.
> 
> Yes, passing \ through echo is non-portable, and you must use
> printf instead of echo if the string to be echoed is likely to
> contain a backslash (in addition to the shell quoting rules that
> backslash has outside of echo).
> 

I know, too. Using echo is not me but many projects using autotools.
Frankly, I did not look into autotools itself whether or not it uses
echo. But it seems that many projects using autotools assumes a path
does not include '\'. To avoid this, this patch is reasonable.

>> 
>> How does mingw handle .exe ?
> 
> Configure probes early on if .exe is produced when compiling an 
> executable, and sets $EXEEXT accordingly.  But in many cases,
> executing '/bin/sh' is automatically translated into '/bin/sh.exe'
> without the user having to explicitly request .exe as part of the
> executable name. Maybe I'm missing a subtlety of OS/2 and what is
> automated vs. manually required, but giving more details will only
> make your case for this patch stronger.
> 

Ah, OK. Unfortunately, however, a compiler itself cannot be located
without ac_executable_extensions. Therefore, $EXEEXT cannot be set as
well. I know, '/bin/sh' to /bin/sh.exe' translation also depends on
ac_executable_extensions or $EXEEXT.


>> 
>> 
>>>> 
>>>> * lib/autoconf/general.m4 (AC_SITE_LOAD): Convert \ in PATH
>>>> to /. Add .exe to ac_executable_extensions.
>>> 
>>> This says what you changed, but not why.  A good commit
>>> message gives rationale on WHY the change is important, such as
>>> a demonstration of what goes wrong without the patch.
>>> 
>> 
>> I thought I explained WHY above message.
> 
> But you never mentioned that 'echo' was at fault.
> 

I admit. ^^

>> 
>>>> --- lib/autoconf/general.m4 |   28
>>>> ++++++++++++++++++++++++++++ 1 files changed, 28
>>>> insertions(+), 0 deletions(-)
>>>> 
>>>> diff --git a/lib/autoconf/general.m4
>>>> b/lib/autoconf/general.m4 index 77f71d2..5a87d5e 100644 ---
>>>> a/lib/autoconf/general.m4 +++ b/lib/autoconf/general.m4 @@
>>>> -1951,6 +1951,34 @@ do || AC_MSG_FAILURE([failed to load site
>>>> script $ac_site_file]) fi done + +if test -n "$OS2_SHELL";
>>>> then +  # Backslashes into forward slashes: +  # The
>>>> following OS/2 specific code is performed AFTER config.site +
>>>> # has been loaded to allow users to change their environment
>>>> there. +  # This strange code is necessary to deal with
>>>> handling of backslashes by +  # ksh. + ac_save_IFS="$IFS" +
>>>> IFS="\\" +  ac_TEMP_PATH= +  for ac_dir in $PATH; do +
>>>> IFS=$ac_save_IFS +    if test -z "$ac_TEMP_PATH"; then +
>>>> ac_TEMP_PATH="$ac_dir" +    else + 
>>>> ac_TEMP_PATH="$ac_TEMP_PATH/$ac_dir" +    fi +  done +
>>>> export PATH="$ac_TEMP_PATH" +  unset ac_TEMP_PATH
> 
> Your email client is horribly botching quoting.
> 

Ooops... That's too bad in my point of view. Hmm...

>>> 
>>> It looks like this is an (overly-complex) way of converting all
>>> \ in $PATH into / before proceeding.  But why is it necessary?
>>> 
>> 
>> As I said above, without this, echoing components of PATH may be 
>> corrupted. For examples, x:\usr\bin will be x:\usin on pdksh.
> 
> Only if you do something non-portable like 'echo "$PATH"'.  If you
> do 'printf %s\\n "$PATH"', the problem goes away.
> 

As I said above, it's not me who using echo. ^^

>> 
>>>> + +  # add .exe to ac_executable_extensions +  if test -z 
>>>> "$ac_executable_extensions"; then + 
>>>> AC_MSG_WARN([ac_executable_extensions not set, assuming
>>>> .exe]) + fi +
>>>> ac_executable_extensions="$ac_executable_extensions .exe" + 
>>>> export ac_executable_extensions
>>> 
>>> Why is the existing code that sets ac_executable_extensions not
>>>  sufficient?
>> 
>> What is the existing code ? Anyway without this, 
>> ac_executable_extensions is not set at all.
>> 
>>> And why do you have to export it into the environment of child 
>>> processes?
>> 
>> I just preserved the old codes from OS/2 fork if possible. If it
>> is not needed, I'll remove it.
> 
> Well, just reposting an old patch calls into play other questions -
> are you the original author of the patch, and if not, are there
> any copyright restrictions that would prevent us from applying the
> patch?

Frankly, I don't know who is the original author. I know, the last
porter is Andreas Buening. So I just guess he would be the author of
this patch. He opened the patches. I think, copyright restriction is
none. But I'm not sure.

> Also, just because a downstream fork wrote a patch does not mean it
> was the ideal patch; discussing the issues in the open can often
> lead to a better understanding of the real issue and a better
> patch.
> 

Yes, this is exactly one of the reasons why I submit these patches.

>> 
>> This might be better as two separate patches, since it
>>> is doing two unrelated changes.
>>> 
>> 
>> I thought both these were OS/2 init codes. Anyway, I'll split.
> 
> They are both related to OS/2, but tackling different items.
> 

Ok.

- -- 
KO Myung-Hun

Using Mozilla SeaMonkey 2.7.2
Under OS/2 Warp 4 for Korean with FixPak #15
In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM

Korean OS/2 User Community : http://www.ecomstation.co.kr

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (OS/2)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFUIPewE9YstvghgroRAnzvAJ9Gjp8V7CQrbLNV9f11y7apJ4mDMACfR4XO
3hhxJ7Zcjr7BgzVwtsyfUbA=
=gGgs
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.