php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #76702 pathinfo's $options should have a value for DIRNAME + FILENAME
Submitted: 2018-08-03 22:32 UTC Modified: 2021-08-23 14:17 UTC
From: jerry at jmweb dot net Assigned:
Status: Open Package: Filesystem function related
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: jerry at jmweb dot net
New email:
PHP Version: OS:

 

 [2018-08-03 22:32 UTC] jerry at jmweb dot net 
Description:
------------
Obtaining a file's path + filename is quite cumbersome using pathinfo() since the $options argument accept one of a discrete set of values. It would be nice if we could supply a bitmask instead.

A real-world case is caching output from .php pages. The web server routes /path/, to /path/index.php and it saves it's own output to /path/index.html. The next request is then served the contents of index.html directly by the web server.

I am not sure how difficult it would be to implement, but I see it useful.

Test script:
---------------
$path   = '/dir/file.ext';
$newExt = '.ext2';

$newPath = pathinfo( $path, PATHINFO_DIRNAME ) . '/' . pathinfo( $path, PATHINFO_FILENAME ) . $newExt; // /dir/file.ext2

// if pathinfo could accept a bitmask
$newPathBitmask = pathinfo( $path, PATHINFO_DIRNAME | PATHINFO_FILENAME ) . $newExt; // /dir/file.ext2

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-08-04 06:45 UTC] a at b dot c dot de 
How, for example, would (PATHINFO_DIRNAME | PATHINFO_EXTENSION) or (PATHINFO_BASENAME | PATHINFO_FILENAME) be handled?

I'd be more inclined to write the test script as:


$path = '/dir/file.ext';
$newExt = '.ext2';

['dirname' => $dir, 'basename' => $file] = pathinfo($path);
$newPath = "$dir/$file$newExt";


But that may just be me.
 [2018-08-04 07:08 UTC] requinix@php.net
-Status: Open +Status: Feedback
 [2018-08-04 07:08 UTC] requinix@php.net 
So instead, how about a constant for the combined DIRNAME+FILENAME?
 [2018-08-04 13:47 UTC] a at b dot c dot de 
The same way BASENAME is FILENAME+EXTENSION? It would fill a hole in the matrix:

dirname/filename.extension
------- -------- *********   EXTENSION
------- ******** ---------   FILENAME
------- ******** *********   BASENAME
******* -------- ---------   DIRNAME
******* ******** ---------   ?[ROOTNAME? STEMNAME?]
(the remaining three dirname/filename/extension combinations aren't useful).
 [2018-08-04 19:21 UTC] jerry at jmweb dot net 
The output should follow the natural order of the file's path regardless of the order the bitmask was created. So (PATHINFO_DIRNAME | PATHINFO_EXTENSION) would be identical to the concatenation of pathinfo()'s matching indexes (['dirname'] . '/.' . ['extension']). The bitmask (PATHINFO_BASENAME | PATHINFO_FILENAME) would be normalized to just (PATHINFO_BASENAME) and return only the equivalent of pathinfo()'s (['basename']).

I now see that accepting a bitmask value will make things convoluted since:

PATHINFO_FILENAME | PATHINFO_EXTENSION -> same output as PATHINFO_BASENAME
PATHINFO_FILENAME | PATHINFO_BASENAME  -> normalized to PATHINFO_BASENAME
PATHINFO_DIRNAME  | PATHINFO_EXTENSION -> not useful

Introducing a new constant for the DIRNAME + FILENAME combination sounds like a better solution. However, coming up an appropriate name escapes me at the moment. To kick-start the options, consider these:

PATHINFO_FILEPATH
PATHINFO_FILENAMEPATH
PATHINFO_NO_EXTENSION
PATHINFO_EXTENSIONLESS
PATHINFO_DIRFILENAME
 [2018-08-04 20:38 UTC] requinix@php.net
-Summary: pathinfo's $options should accept a bitmask value +Summary: pathinfo's $options should have a value for DIRNAME + FILENAME -Status: Feedback +Status: Open
 [2018-08-04 20:38 UTC] requinix@php.net 
Personally I would go for DIRFILE or DIRFILENAME - a combination of the DIRNAME and FILENAME constants (and one that fits the current naming style) which should help users remember it.
 [2018-08-04 20:42 UTC] jerry at jmweb dot net 
I vote for PATHINFO_DIRFILENAME. I see it more consistent to the existing PATHINFO_ family of constants.

What is the next step? Unfortunately, I can't submit a patch since I do not know C. Also, what release would this feature target if approved?
 [2018-08-04 21:08 UTC] requinix@php.net 
The next step would be someone with C knowledge making a patch or pull request to add the functionality. It's not a particularly difficult change to implement: a new constant and the obvious edits to pathinfo() to support it. It's also subject to approval by the devs, of course, but I see no reason why something like this would be declined.

As for when, I can't really say. Features tend to come in minor releases but 7.3 hit feature freeze earlier this week for a scheduled release this December; releases are yearly so 7.4 (or 8.0) would be out end of 2019. But I don't think there is a strict rule about minor improvements like this so it's up to the devs and RMs whether this goes with 7.3.0, or 7.3.x/7.2.y/7.1.z, or waits until 7.4. Assuming the change was written and submitted soon, of course.
 [2021-08-23 14:17 UTC] cmb@php.net 
> Assuming the change was written and submitted soon, of course.

Or ever. :)
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Dec 27 03:01:28 2024 UTC