Discussion:
Extended file spec support on CSWS & PHP7
(too old to reply)
issinoho
2020-08-25 12:58:28 UTC
Permalink
Hi,

Can anyone tell me how to enable extended file support in CSWS and PHP7 (berrymans build) ?

This is specifically to allow PHP to find files with e.g. double dots in the name.

In the old days it used to involve logicals being defined in PHP_SETUP.COM but that doesn't exist now (by the looks of it).

TIA

VSI AXPVMS VMS V8.4-2L1
VSI AXPVMS SSL111 V1.1-1GB
VSI AXPVMS CSWS V2.4-38D
PHP 7.2.29
issinoho
2020-08-27 11:31:13 UTC
Permalink
Post by issinoho
Hi,
Can anyone tell me how to enable extended file support in CSWS and PHP7 (berrymans build) ?
This is specifically to allow PHP to find files with e.g. double dots in the name.
In the old days it used to involve logicals being defined in PHP_SETUP.COM but that doesn't exist now (by the looks of it).
TIA
VSI AXPVMS VMS V8.4-2L1
VSI AXPVMS SSL111 V1.1-1GB
VSI AXPVMS CSWS V2.4-38D
PHP 7.2.29
Update...

Firstly, I was using an older version of unzip so the filenames were not being created correctly. Solved by grabbing latest unzip (6.00) from VSI.

Secondly, I've re-created the old php_setup.com and tied it into apache$setup.com -- which doesn't seem to have made a difference.

Next, I tried accessing a multi-dotted filename directly with CSWS and that works fine, so CSWS is not the problem here.

So, conclusion, it's the PHP parser which is not honoring extended parsing of ODS-5 files. Any thoughts? Is there a way to contact Mark Berryman for queries like this beyond posting here?

TIA
Mark Berryman
2020-08-27 19:58:18 UTC
Permalink
Post by issinoho
Post by issinoho
Hi,
Can anyone tell me how to enable extended file support in CSWS and PHP7 (berrymans build) ?
This is specifically to allow PHP to find files with e.g. double dots in the name.
In the old days it used to involve logicals being defined in PHP_SETUP.COM but that doesn't exist now (by the looks of it).
TIA
VSI AXPVMS VMS V8.4-2L1
VSI AXPVMS SSL111 V1.1-1GB
VSI AXPVMS CSWS V2.4-38D
PHP 7.2.29
Update...
Firstly, I was using an older version of unzip so the filenames were not being created correctly. Solved by grabbing latest unzip (6.00) from VSI.
Secondly, I've re-created the old php_setup.com and tied it into apache$setup.com -- which doesn't seem to have made a difference.
Next, I tried accessing a multi-dotted filename directly with CSWS and that works fine, so CSWS is not the problem here.
So, conclusion, it's the PHP parser which is not honoring extended parsing of ODS-5 files. Any thoughts? Is there a way to contact Mark Berryman for queries like this beyond posting here?
It is not PHP. A specific example of a failure to access to the file
would be very helpful. The way I read your current message, you can
access the file via a web browser when it is served up by your web
server but you can't access it via PHP directly, which I assume to mean
interactively. If that is the case, have you verified that SET
PROCESS/PARSE_STYLE=EXTENDED has been set? If it is something else,
please provide an example.

Mark Berryman
issinoho
2020-08-28 09:36:30 UTC
Permalink
Post by issinoho
Post by issinoho
Hi,
Can anyone tell me how to enable extended file support in CSWS and PHP7 (berrymans build) ?
This is specifically to allow PHP to find files with e.g. double dots in the name.
In the old days it used to involve logicals being defined in PHP_SETUP.COM but that doesn't exist now (by the looks of it).
TIA
VSI AXPVMS VMS V8.4-2L1
VSI AXPVMS SSL111 V1.1-1GB
VSI AXPVMS CSWS V2.4-38D
PHP 7.2.29
Update...
Firstly, I was using an older version of unzip so the filenames were not being created correctly. Solved by grabbing latest unzip (6.00) from VSI.
Secondly, I've re-created the old php_setup.com and tied it into apache$setup.com -- which doesn't seem to have made a difference.
Next, I tried accessing a multi-dotted filename directly with CSWS and that works fine, so CSWS is not the problem here.
So, conclusion, it's the PHP parser which is not honoring extended parsing of ODS-5 files. Any thoughts? Is there a way to contact Mark Berryman for queries like this beyond posting here?
It is not PHP. A specific example of a failure to access to the file
would be very helpful. The way I read your current message, you can
access the file via a web browser when it is served up by your web
server but you can't access it via PHP directly, which I assume to mean
interactively. If that is the case, have you verified that SET
PROCESS/PARSE_STYLE=EXTENDED has been set? If it is something else,
please provide an example.
Mark Berryman
Thanks for replying, Mark.

I've done some more testing and I now DON'T think this is restricted to extended file names, as I renamed the file and the code to a traditional format and it still can't find it.

Running from the command line gives me the exact same error...

$ php www$root:[phpmyadmin.scripts]setup.php
PHP Warning: require_once(./libraries/common.inc.php): failed to open stream: n
o such file or directory in /www$root/phpmyadmin/scripts/setup.php on line 20

Warning: require_once(./libraries/common.inc.php): failed to open stream: no suc
h file or directory in /www$root/phpmyadmin/scripts/setup.php on line 20
PHP Fatal error: require_once(): Failed opening required './libraries/common.in
c.php' (include_path='.:/php_root/000000') in /www$root/phpmyadmin/scripts/setup
.php on line 20

Fatal error: require_once(): Failed opening required './libraries/common.inc.php
' (include_path='.:/php_root/000000') in /www$root/phpmyadmin/scripts/setup.php
on line 20

I am completely stumped by this. My 2 lines of thought are: permissions (I'm almost certain these are good), and relative paths (something to do with that include_path?)

I found a blog post by Willem Grooters with this exact issue, but unfortunately there is no resolution posted, http://www.grootersnet.nl/sysblog/?p=916

TIA (again)
Mark Berryman
2020-08-28 15:20:15 UTC
Permalink
Post by issinoho
Post by issinoho
Post by issinoho
Hi,
Can anyone tell me how to enable extended file support in CSWS and PHP7 (berrymans build) ?
This is specifically to allow PHP to find files with e.g. double dots in the name.
In the old days it used to involve logicals being defined in PHP_SETUP.COM but that doesn't exist now (by the looks of it).
TIA
VSI AXPVMS VMS V8.4-2L1
VSI AXPVMS SSL111 V1.1-1GB
VSI AXPVMS CSWS V2.4-38D
PHP 7.2.29
Update...
Firstly, I was using an older version of unzip so the filenames were not being created correctly. Solved by grabbing latest unzip (6.00) from VSI.
Secondly, I've re-created the old php_setup.com and tied it into apache$setup.com -- which doesn't seem to have made a difference.
Next, I tried accessing a multi-dotted filename directly with CSWS and that works fine, so CSWS is not the problem here.
So, conclusion, it's the PHP parser which is not honoring extended parsing of ODS-5 files. Any thoughts? Is there a way to contact Mark Berryman for queries like this beyond posting here?
It is not PHP. A specific example of a failure to access to the file
would be very helpful. The way I read your current message, you can
access the file via a web browser when it is served up by your web
server but you can't access it via PHP directly, which I assume to mean
interactively. If that is the case, have you verified that SET
PROCESS/PARSE_STYLE=EXTENDED has been set? If it is something else,
please provide an example.
Mark Berryman
Thanks for replying, Mark.
I've done some more testing and I now DON'T think this is restricted to extended file names, as I renamed the file and the code to a traditional format and it still can't find it.
Running from the command line gives me the exact same error...
$ php www$root:[phpmyadmin.scripts]setup.php
PHP Warning: require_once(./libraries/common.inc.php): failed to open stream: n
o such file or directory in /www$root/phpmyadmin/scripts/setup.php on line 20
Warning: require_once(./libraries/common.inc.php): failed to open stream: no suc
h file or directory in /www$root/phpmyadmin/scripts/setup.php on line 20
PHP Fatal error: require_once(): Failed opening required './libraries/common.in
c.php' (include_path='.:/php_root/000000') in /www$root/phpmyadmin/scripts/setup
.php on line 20
Fatal error: require_once(): Failed opening required './libraries/common.inc.php
' (include_path='.:/php_root/000000') in /www$root/phpmyadmin/scripts/setup.php
on line 20
I am completely stumped by this. My 2 lines of thought are: permissions (I'm almost certain these are good), and relative paths (something to do with that include_path?)
I found a blog post by Willem Grooters with this exact issue, but unfortunately there is no resolution posted, http://www.grootersnet.nl/sysblog/?p=916
With that syntax, your current default directory would have to be
www$root:[phpmyadmin.scripts] in order to find the file. You need to
add :/www$root/phpmyadmin/scripts to your include_path in php.ini if you
want PHP to find the file using a relative reference.

Mark Berryman
Stephen Hoffman
2020-08-28 15:29:23 UTC
Permalink
Post by issinoho
I've done some more testing and I now DON'T think this is restricted to
extended file names, as I renamed the file and the code to a
traditional format and it still can't find it.
Guess...

Smells vaguely like C RTL logical names. One of my favorite code
smells, performing app settings management via an unbounded list of
arcanely-named logical names.

For reproducible app startups, we are seemingly intended to add ~forty
logical name definitions into our app startup logic or app startup
files, either in associated DCL or in a screwy initialization program
section (lib$initialize psect) needed during app launch, this for
reproducible app launches, because of compatibility. And new logical
names can and occasionally get added to the list of what we should
configure on launch. Bad idea this design, but here we are.

And for those of you that think you're immune to this because not using
C, are you sure there's not a C dependency underneath your app
somewhere, and are you sure that a dependency will never be added?

Here's what was once suggested specifically for using CSWS php on OpenVMS:

$ DEFINE /NoLog DECC$EFS_CASE_PRESERVE ENABLED
$ DEFINE /NoLog DECC$EFS_CASE_SPECIAL ENABLED
$ DEFINE /NoLog DECC$EFS_CHARSET ENABLED
$ DEFINE /NoLog DECC$FILE_SHARING ENABLED

The C manual suggests the following be defined (though oddly doesn't
provide recommended settings!):
DECC$EFS_CHARSET, DECC$DISABLE_TO_VMS_LOGNAME_TRANSLATION,
DECC$FILENAME_UNIX_NO_VERSION, DECC$FILENAME_UNIX_REPORT,
DECC$READDIR_DROPDOTNOTYPE, DECC$RENAME_NO_INHERIT

Details:
https://vmssoftware.com/docs/VSI_OpenVMS_BaseOS/VSI_C_RTL_REF_MAN.pdf

Pragmatically, defining all ~40 feature logical names is probably the
safest approach. That will avoid feature-related surprises. At least
until a new feature is invented. Either in the app startup, or in
lib$initialize psect "fun". (And yes, lib$initialize reportedly can't
fix everything here, due to the details of the app launch sequencing.)

Poke around in the depths of Apache startup or maybe in the available
Apache source code, and you may well be able to find the list of
logical names that's using at run-time.

This whole logical-names-for-management idea can't be tossed in the
memory hole soon enough, but the hypothetical eventual replacement of
this scheme means updating the OpenVMS image activator, and hopefully
also adding room for if not support for code-signing and code
entitlements and related checks and related functions currently missing
on OpenVMS. Which is obviously a larger product than adding and
translating logical names.
--
Pure Personal Opinion | HoffmanLabs LLC
hb
2020-08-28 16:42:28 UTC
Permalink
(And yes, lib$initialize reportedly can't fix everything here, due to
the details of the app launch sequencing.)
It depends on where the lib$initialize is, in the main or in a shareable
image. You very likely can always ensure with linker options that your
lib$initialize in your shareable image is called before any other code
runs. That should fix any problem, here, that I can think of.
Craig A. Berry
2020-08-28 18:37:14 UTC
Permalink
Post by hb
(And yes, lib$initialize reportedly can't fix everything here, due to
the details of the app launch sequencing.)
It depends on where the lib$initialize is, in the main or in a shareable
image. You very likely can always ensure with linker options that your
lib$initialize in your shareable image is called before any other code
runs. That should fix any problem, here, that I can think of.
But you can't set extended parse in lib$initialize,[1] and without that,
DECC$ARGV_PARSE_STYLE doesn't do you any good.

[1] You can set it, but it doesn't have any effect on the
already-running image.
Stephen Hoffman
2020-08-28 19:34:45 UTC
Permalink
Post by Craig A. Berry
Post by hb
(And yes, lib$initialize reportedly can't fix everything here, due to
the details of the app launch sequencing.)
It depends on where the lib$initialize is, in the main or in a
shareable image. You very likely can always ensure with linker options
that your lib$initialize in your shareable image is called before any
other code runs. That should fix any problem, here, that I can think of.
But you can't set extended parse in lib$initialize,[1] and without
that, DECC$ARGV_PARSE_STYLE doesn't do you any good.
[1] You can set it, but it doesn't have any effect on the
already-running image.
Ayup. That's the one I was thinking of. Wouldn't surprise me there
might or can or will be other cases arising here, given the relative
volatility of the whole morass-of-an-API here.

OpenVMS has far too many of these legacy-encumbered API designs around,
too. Alas, the development effort involved in resolving these cases is
likely insurmountable, without also selectively eliminating
compatibility.

I like compatibility. I do. But I recognize that compatibility has its
limits. And that compatibility adds development costs, both for VSI
developers, and for end-user and third-party app developers. And having
to explain to folks that you need ~40 settings in a startup file can be
an interesting discussion with new-to-OpenVMS developers. Or explaining
cases where establishing the run-time defaults was ignored, and
something (else) then blows up. Later. Mysteriously. (Long-standing
parallel to these C RTL downstream app failures: it should not be
permissible to default the $crembx mailbox size and buffer quota
arguments in any new code. That defaulting never ends well.)

Getting a charter for and budget to actually fix some of the larger
design holes here would be entertaining for all. But that's not
happening until after the completion of the OpenVMS x86-64 port, and
that at the very earliest. But fixing this stuff will break stuff.
--
Pure Personal Opinion | HoffmanLabs LLC
hb
2020-08-28 19:50:01 UTC
Permalink
Ayup.  That's the one I was thinking of. Wouldn't surprise me there
might or can or will be other cases arising here, given the relative
volatility of the whole morass-of-an-API here.
Sorry, I didn't know what you were thinking of, this was the context I saw:

Pragmatically, defining all ~40 feature logical names is probably the
safest approach. That will avoid feature-related surprises. At least
until a new feature is invented. Either in the app startup, or in
lib$initialize psect "fun". (And yes, lib$initialize reportedly can't
fix everything here, due to the details of the app launch sequencing.)
Stephen Hoffman
2020-08-29 17:14:21 UTC
Permalink
Post by Stephen Hoffman
Ayup.  That's the one I was thinking of. Wouldn't surprise me there
might or can or will be other cases arising here, given the relative
volatility of the whole morass-of-an-API here.
Pragmatically, defining all ~40 feature logical names is probably the
safest approach. That will avoid feature-related surprises. At least
until a new feature is invented. Either in the app startup, or in
lib$initialize psect "fun". (And yes, lib$initialize reportedly can't
fix everything here, due to the details of the app launch sequencing.)
Thanks for the hack workaround for the hack workaround for the hack.
It'll get some use.
--
Pure Personal Opinion | HoffmanLabs LLC
hb
2020-08-28 19:44:52 UTC
Permalink
Post by Craig A. Berry
But you can't set extended parse in lib$initialize,[1] and without that,
DECC$ARGV_PARSE_STYLE doesn't do you any good.
I know, but extended parsing is not a DECC feature (and that was the
context) and ...
Post by Craig A. Berry
[1] You can set it, but it doesn't have any effect on the
already-running image.
because parsing of the command line was done before the image was
activated, ahem the app was launched. I don't know of any way to ask DCL
to re-parse the command line with the new setting and to re-launch the app.

At least on Alpha and C++ images there are known problems setting the
DECC features in lib$initialize in main, which can be avoided with
lib$initialize in a shareable image.
Stephen Hoffman
2020-08-29 17:06:00 UTC
Permalink
Post by hb
At least on Alpha and C++ images there are known problems setting the
DECC features in lib$initialize in main, which can be avoided with
lib$initialize in a shareable image.
So the (documented) hack requires additional (undocumented) hacks?

Okay; thanks for that workaround. That might just be very useful.

That workaround-on-a-workaround will be "fun" to document in the next
project that I need deploy these workarounds within.

But then nobody hopefully need defend this logical name miasma.

OpenVMS developers are certainly not alone in having expected tech
writers to cover for design or implementation omissions,
incompleteness, or errors.

Dancing around the actual reasons tends to lead to twisted prose. Kind
of like learning about and spotting the use of passive voice, too.

Once you recognize the twisted prose or the passive voice or such, you
do start to see the same writing techniques applied elsewhere.

There've been some useful and well-done and well-received OpenVMS
presentations repeated over the years that long left me wondering "why
just fix the bug/flaw/confusion, and stop presenting the way 'round
it?", though.

ACME LDAP has been one such area. That did see one recent
simplification, though more work there is needed. These C logical names
are another. 32-/64-bit is another. Areas either assiduously ignored,
or defensively documented.

Here? The whole C logical name mess is a mess, and it's not going to
get better until it gets replaced. Which isn't happening anytime soon.

So... this means more twisted proses, I expect. Twisted prose in my
next project, and (looks around) in any currently-open projects using
the lib$initialize workarounds, in my case.

Hacking is such sweet sorrow.
--
Pure Personal Opinion | HoffmanLabs LLC
Loading...