[Info-vax] Extended file spec support on CSWS & PHP7

[Mark Berryman]

On 8/28/20 3:36 AM, issinoho wrote:
> On Thursday, 27 August 2020 at 20:58:22 UTC+1, Mark Berryman wrote:
>> On 8/27/20 5:31 AM, issinoho wrote:
>>> On Tuesday, 25 August 2020 at 13:58:31 UTC+1, issinoho wrote:
>>>> 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