Re: File found by searching load path

[Rik]

On 12/10/2018 08:32 AM, John W. Eaton wrote:
> On 12/10/18 10:11 AM, Carnë Draug wrote:
>
>> There's a third option.  There could be a variable that specifies the
>> data directory for Octave.  So someone could use:
>>
>>      load (fullfile (OCTAVE_DATA_DIR, "penny.mat"));
>>
>> And be explicit about what they want.  But since this is really only
>> for Octave's data, maybe a function instead?  Something like this:
>>
>>      load_octave_data ("penny.mat");
>>      load_demo_data ("penny.mat");
>
> The directory name is already in the struct returned by
> __octave_config_info__.  On IRC, you pointed out that it's probably bad
> form to ask users to access this info using a "private" function and I
> agree.  We recently renamed the "public" octave_config_info function to
> the "private" name __octave_config_info__ because a lot of that info is
> really internal to Octave's build configuration.  But some of it is
> useful and might be made public.  So we could split this into a public
> and private function.  That might be better than having a special
> function just for loading Octave demo data files.

I'd prefer not to have another function.  If we know OCTAVE_DATA_DIR,
couldn't we simply check whether the file we found was in that directory
and skip producing a warning in that case?  The code is in utils.cc.

        if (! local_file_ok)
          {
            load_path& lp =
              __get_load_path__ ("find_data_file_in_load_path");

            // Not directly found; search load path.
            std::string tmp
              = sys::env::make_absolute (lp.find_file (fname));

            if (! tmp.empty ())
              {
                warn_data_file_in_path (fcn, tmp);

                fname = tmp;
              }
          }

If the file is found through searching (! tmp.empty ()), add in another
test that the directory is not the same as OCTAVE_DATA_DIR.

--Rik

>
>> The warning seems fine to me.  Searching the path for a file with the
>> same name and ignoring file extension is the type of feature that I
>> think we only support for Matlab compatibility.  But it's so crazy
>> that a warning against such terrible practice is justified.
>
> Yes, this is the reason that I added this warning.  Do file reading
> functions in other languages search a path for files?  That seems like a
> strange feature to me that can lead to unpredictable results.  It also
> seemed bad to me that the path used to search for data files was the same
> as the one used for searching for program (.m) files.
>
> For those who want more faithful Matlab compatibility, there is the
> "--braindead^H^H^H^H^H^H^H^H^Htraditional" option.  This warning is
> already disabled when invoking Octave with that option.
>
> I could be persuaded that the warning should always be disabled by
> default, but please don't remove it.
>
> jwe
>
>
>