I'm of two minds on this one. That *could* be the appropriate place
to insert the search, but then I'm reminded of the problem that Mike
Cowlishaw encountered when I first implemented the (more)
case-insensitive searches on Linux. Suddenly, we started picking up
real binary executables that happened to have the same names as Rexx
programs, with fairly disastrous results. That would sort of argue it
should be the option of LAST choice, to ensure the appropriate Rexx
programs are located first.
And, the more I think about it, if you are writing an application that
is using ooRexx as a macro language and have a list of extensions you
wish to have picked up, then those should be checked BEFORE an
extensionless file to ensure the version for your targetted
environment gets used. That, I think, is enough to convince me it
should be last in the order.
Rick
On Thu, Jun 26, 2008 at 10:29 AM, Mark Miesfeld <[EMAIL PROTECTED]> wrote:
> Rick has done a great job of improving the search order algorithm for
> external files. There was a case that accidentally got dropped in
> reworking the code. That case is when the program file has no
> extension.
>
> I'm wondering where in the search order we should stick that in. I
> already committed a fix to the Windows code, but before I update the
> Unix code, I thought we might want to discuss where in the order is
> the proper place.
>
> I stuck it immediately after the case where the program file already
> has the extension. Maybe though it should be last in the search?
>
> My theory is that: before trying to search for a program file by
> artificially adding an extension, you should try the file name as
> given. But, if most people don't use that case in the code they
> write, maybe it should be the last case to search for?
>
> Right now the Windows code is as below. If we decide where in the
> search order the case should go, I'll clean up the comment and add the
> fix to the Unix code base.
>
>
> // if the file already has an extension, this dramatically reduces
> the number
> // of searches we need to make.
> if (hasExtension(name))
> {
> if (searchName(name, searchPath.path, NULL, resolvedName))
> {
> return new_string(resolvedName);
> }
> return OREF_NULL;
> }
>
> // The file may purposefully have no extension. Whether this search should
> // come here, or last is debatable.
> if (searchName(name, searchPath.path, NULL, resolvedName))
> {
> return new_string(resolvedName);
> }
>
> // if we have a parent extension provided, use that in preference
> to any default searches
> if (parentExtension != NULL)
> {
> if (searchName(name, searchPath.path, parentExtension, resolvedName))
> {
> return new_string(resolvedName);
> }
>
> }
>
> // ok, now time to try each of the individual extensions along the way.
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Oorexx-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
