|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
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 Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: jerry at jmweb dot net
New email:
PHP Version: OS:


 [2018-08-03 22:32 UTC] jerry at jmweb dot net
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


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2018-08-04 06:45 UTC] a at b dot c dot de

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]
-Status: Open +Status: Feedback
 [2018-08-04 07:08 UTC]
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:

------- -------- *********   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:


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:

 [2018-08-04 20:38 UTC]
-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]
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]
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]
> Assuming the change was written and submitted soon, of course.

Or ever. :)
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Wed Dec 07 21:04:14 2022 UTC