Cannot find *.sav files from the path

[tueda]

In #240 I assumed FORM tries to find also *.sav files (for a library) from the path, but actually not.

ls -R

.:
foo/  test.frm

./foo:
TablesX.sav

cat test.frm

Load TablesX.sav;
.end

Then all of the following commands fail:

FORMPATH=foo form test.frm
form -p foo test.frm
form -I foo test.frm

FORM 4.2.0 (Oct 26 2017, v4.2.0-22-g954024f) 64-bits  Run: Thu Nov 23 14:55:22 2017
    Load TablesX.sav;
Cannot open file TablesX.sav
    .end
Program terminating at test.frm Line 1 --> 
  0.00 sec out of 0.00 sec

Is this intended behavour?

[vermaseren]

The philosophy behind this is that libraries are rather general things and .sav files belong to a specific project or calculation. Hence those would typically be in the directory of a project. Otherwise one can indicate them with an absolute pathname etc. If it is decided that this is not a good argument, it can of course be changed….

Jos

On 23 Nov 2017, at 14:58, Takahiro Ueda notifications@github.com wrote:

In #240 https://github.com/vermaseren/form/issues/240 I assumed FORM tries to find also *.sav files (for a library) from the path, but actually not.

ls -R .: foo/ test.frm

./foo: TablesX.sav cat test.frm Load TablesX.sav; .end Then all of the following commands fail:

FORMPATH=foo form test.frm form -p foo test.frm form -I foo test.frm FORM 4.2.0 (Oct 26 2017, v4.2.0-22-g954024f) 64-bits Run: Thu Nov 23 14:55:22 2017 Load TablesX.sav; Cannot open file TablesX.sav .end Program terminating at test.frm Line 1 --> 0.00 sec out of 0.00 sec Is this intended behavour?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/vermaseren/form/issues/241, or mute the thread https://github.com/notifications/unsubscribe-auth/AFLxEpIzA3HRAcN7rzxR8g2rVcBaOCYwks5s5XnpgaJpZM4Qoyuf.

[tueda]

The philosophy behind this is that libraries are rather general things and .sav files belong to a specific project or calculation.

It makes sense.

Then the question would be how a library can find its absolute path to the directory where it is sitting. If this could be possible, then a library can specify the absolute file names of binary *.sav files belonging to the library, which is generated during the installation (e.g., make).

[vermaseren]

If a path has been defined, its ‘value’ is in a preprocessor variable. The main obstacle at the moment is that it defines potentially more than one directory. Maybe we can make a $path_ in ‘factorized’ form to indicate the various elements of the path. Together with the suggested fileexists that should solve the problem. We may need a special dictionary for this because the factors of a $ variable cannot be strings. I’ll have to think this over.

Jos

On 23 Nov 2017, at 17:30, Takahiro Ueda notifications@github.com wrote:

The philosophy behind this is that libraries are rather general things and .sav files belong to a specific project or calculation.

It makes sense.

Then the question would be how a library can find its absolute path to the directory where it is sitting. If this could be possible, then a library can specify the absolute file names of binary *.sav files belonging to the library, which is generated during the installation (e.g., make).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/vermaseren/form/issues/241#issuecomment-346660628, or mute the thread https://github.com/notifications/unsubscribe-auth/AFLxEgVi7u8QNsW01ILggl7OejZ0C0tNks5s5Z2rgaJpZM4Qoyuf.