On Saturday 31 March 2007 06:02, Paul Eggert wrote: > Keith Marshall <keith.d.marshall@xxxxxxxxxxxx> writes: > > While MSYS strives to provide a Unixy > > shell, it has to work within the limitations of the underlying > > Win32 OS, and that means the ability to identify a file as > > executable must rely on the file name extension, with the one > > exception of shebanged script files. > > If shebanged scripts are an exception, why can't there be others? Of course, there can be, if someone cares enough to develop a mechanism for identifying and handling them, submits patches, and champions them through to acceptance. A generalised solution is more likely to gain acceptance, than anything specific to a single case; something modelled on the misc binaries support mechanism in Linux, perhaps. > > if test -x / >/dev/null 2>&1; then > > as_test_x='test -x' > > else > > # do something frighteningly complicated and barely > > comprehensible # (my comment, not in actual code)... > > > > 1) Tests for accessibility to search within the root directory, and > > has nothing to do with executability of files; > > But as_test_x is intended to mimic test -x. Since 'test -x' succeeds > on searchable directories, as_test_x should too. Sure, but on Unix `test -x' plays two distinct roles. You test for it's applicability in one of these roles, namely testing for the ability to search within a specific directory, then deploy it in its other role, namely to test if a specific file is executable. In a general sense, the circumstances in which it will pass are distinct. In MSYS, it will pass for the latter case, only if the file being tested bears as file name extension, one of the standard executable filetype extensions, or if it is a shebanged script; in its other role, it passes if an attempt to identify files within the specified directory is allowed. In neither case, can it simply inspect permission bits in a directory entry, for there is no such bit associated with the property it is intended to test. > > would the initialisation of as_test_x > > not be better deferred, to within the actual code invoked by > > AC_PROG_CC > > But macros other than AC_PROG_CC need as_test_x. The "as_*" prefix > is a hint that this is not an Autoconf feature; it's used by > non-Autoconf code. As a user, it's not easy for me to appreciate this distinction; it isn't well documented. All I see is a report, on my project's ML, that this particular aspect, within a project with which I have no association, has been broken by a change in autoconf, introduced in version 2.61. I've provided information, from the perspective of the MinGW/MSYS project, indicating what I perceive to be the cause of the problem. I leave it to you, however you wish to address it further. Regards, Keith. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
