Re: [Oorexx-devel] File search order in SysInterpreterInstance::resolveProgramName()

[Bill T. W. <wb...@ar...>]

Mark, I am relatively new to the world of unix (more later)
but I think that your statement:

"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."

is a perfectly valid consideration - and is my preference.

As a programmer, if I don't care about efficiency or quicker
understanding about code that "someone else" wrote or
"I wrote years ago" then I should accept whatever i get
if I depend on generic file searches.

Fully qualified names help minimize problems caused
by changes in the library "concatenation" order - especially
when the inserted library comes from somebody else.

- - -

When my windows box failed recently, I was given a very
nice Father's day present - a modern collection of hardware
with enough horsepower to run multiple operating systems.

I decided to make my base system Linux because of stability
and to run several different Windows platforms as virtual.


So far, I am not regretting that decision -  and am somewhat
unhappy that I did not make that switch about 10 years ago
when I first started working with VMware products. This
also has had the happy effect of allowing me to retire some
very underpowered hardware that I have had for years...
The power bill savings should almost make up for the
agrivation of getting things to work they way I need them
to work!!!

The learning curve has been on the interesting side, and I
have found that  many of the programming standards that
I adopted years ago are still very, very valid.

Thus my statement above about using what the programmer
specified BEFORE you start making assumptions about what
they wanted.

/s/ Bill Turner, wb4alm


Mark Miesfeld 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
> Oor...@li...
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>