get_filenames() behavior

The Filesystem helper defines the get_filenames($source_dir[, $include_path = FALSE]) function, described in the User Guide:

Takes a server path as input and returns an array containing the names of all files contained within it. The file path can optionally be added to the file names by setting the second parameter to TRUE.

The function has two different return types contingent on its second parameter. The first (default) is a flat list of all files in all subdirectories:

Code:

document.txt
cat.jpg
rainbow.exe

And the second is the same files by their absolute paths:

Code:

/var/www/html/mysite/document.txt
/var/www/html/mysite/assets/cat.jpg
/var/www/html/mysite/downloads/cached/rainbow.exe

My question to you all: why would the first return type ever be useful? I keep coming back to this function forgetting its "flattening" effect and being disappointed that I can't get the relative paths:

Code:

document.txt
assets/cat.jpg
downloads/cached/rainbow.exe

The default return case is never used in the framework itself, and my opinion is that it should return the relative path instead of just the filename. With the relative path it would still be easy to acquire the flat filename, e.g. with pathinfo() and array_map().

Anyone with experience of the Filesystem helper have input?

I wrote a similar function for use in CI3 that are based on Recursive Iterators that return the relative path. So that I could keep a folder hidden (outside public_html) but still be able to access it, with a PHP-reader if you have enough permissions.

I can't think of any use case you need to have a list of just the filenames, if you do, you can use pathinfo like you stated.

@MGatener,
> Anyone with experience of the Filesystem helper have input?

I am not familiar with the fileSystem and don't want to "rain on your parade" but these helpers do remind me of helpers which were dropped quite some time ago in favour of the HTML, CSS and PHP standard features.

I think one of the helper features dropped was making text bold or italic. Seems an extra effort to learn how to use a CI Helper and the additional functionality can usually be found by searching.

I would far prefer to keep CodeIgniter mean and slim without adding extra bloat.

@John_Betong I agree with that approach, but I do think the Filesystem helped has a lot of functionality that is hard to do with native PHP. A quick search when I was going to write my own version made me realize that this is a common need (recursive directory searches) and there are some slick new tools in 7.2+ to help with it but no ready-to-go solution.

I don't recall ever using the file helper mostly because it contains a bunch of code that, for the given job, was of no interest. So rather than including ~500 lines of code, I would grab just the function or two needed or write the code myself.

From CI v3 the url and form helpers were the only ones I ever used.

With regard to file listing, my need has almost always been to present the user with a file names list. Usually, in these cases, the paths are of no interest to the user. At the moment I cannot recall ever needing to show them subfolders or, for that matter, the associated paths. But it's not hard to see how the full path info would be very useful in other situations.

I'm not positive I understand what you mean when you say "it should return the relative path instead of just the filename". What does that look like?

@dafriend thanks for the feedback! Sorry if my examples were unclear. See the third code block for what I mean by "relative" - it includes the portion of the path between the $source_dir you passed in and the filename. So if I pass in /foo/bar and the only file in there is nested at /foo/bar/bat/baz/file.txt the current behavior would return ['file.txt'], with $include_source it would return ['/foo/bar/bat/baz/file.txt'], and my proposed "relative" return would be ['bat/baz/file.txt'].