File globbing in the standard library

[Morwenn]

The C++17 standard filesystem library would benefit from a generic file globbing utility, which is a really common operation when dealing with files.
Here is a brief description of how I would envision it:

• Add a glob dialect to the regular expression libraries (with standard jokers, including **).
• Add a glob function to path (or somewhere else) taking an std::regex.
• Add overloads to glob for std::string, std::string_view, const char* that default to the newly introduced glob dialect.

I guess that the string types mentioned above would use std::filesystem::path::value_type for their value type.

I believe that using std::regex allows to have a truly generic globbing interface, while defaulting to a regular glob dialect provides the behaviour people expect by default for a glob function.

Any thoughts about such a design?


[Tony V E]

Do you want cross-platform behaviour or platform-native behaviour?

"*.*" is not the same under dos/windows vs unix/mac/linux. 

‎Cross platform seems nice, but if a user tpes "*.*" into a custom Open File dialog, I might want (as the user probably expects) per-platform behaviour. 

Sent from my BlackBerry portable Babbage Device

From: Morwenn Sent: Wednesday, June 8, 2016 4:53 AM To: ISO C++ Standard - Future Proposals Reply To: std-pr...@isocpp.org Subject: [std-proposals] File globbing in the standard library

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/860ea5e8-d2f7-46d1-b1e0-e5493195fa28%40isocpp.org.

[Morwenn]

To be honest, I don't know. I don't think that a platform-native behaviour without a choice would be a good idea, but whether it is platform-native or not could be a parameter somewhere.

I had Python's glob in mine, which seems to work fine and is platform-agnostic if I'm not mistaken.

[Jim Porter]

On 6/8/2016 7:57 AM, Morwenn wrote:
> To be honest, I don't know. I don't think that a platform-native
> behaviour without a choice would be a good idea, but whether it is
> platform-native or not could be a parameter somewhere.
>
> I had Python's glob in mine, which seems to work fine and is
> platform-agnostic if I'm not mistaken.

From Python's documentation[1]:

> The glob module finds all the pathnames matching a specified pattern
> according to the rules used by the Unix shell"

Personally, this seems like something with enough behavioral variance
that I'd expect this to go in Boost or something similar.

- Jim

[1] https://docs.python.org/2/library/glob.html

[Beman Dawes]

On Wed, Jun 8, 2016 at 8:47 AM, Tony V E <tvan...@gmail.com> wrote:

Do you want cross-platform behaviour or platform-native behaviour?

"*.*" is not the same under dos/windows vs unix/mac/linux. 

‎Cross platform seems nice, but if a user tpes "*.*" into a custom Open File dialog, I might want (as the user probably expects) per-platform behaviour.

Seems to me the context for wanting globbing is directory iteration, so the first step would be to add an additional constructor to directory_iterator and recursive_directory_iterator that takes a predicate function object. The function object would passed each candidate path and would returns a bool indicating if the path is to be accepted or skipped.

The library could provide both a portable (i.e. POSIX) globbing function and a native globbing function, or the user could write their own.

I started to prototype that approach a few years ago, but got side tracked and never got back to it. It is a bit tricky for recursive_directory_iteration because of the need to keep track of where the file system recursion is in relation to the globbing elements.

It would be great if someone stepped forward with a formal proposal with supporting implementation.

--Beman

[Sean Middleditch]

Could/should this be resolved the same way we handle regex, e.g. glob_constants::POSIX, glob_constants::DOS, glob_constants::NATIVE, etc.?

[Moritz Klammler]

Sean Middleditch <sean.mid...@gmail.com> writes:

> Could/should this be resolved the same way we handle regex, e.g.
> glob_constants::POSIX, glob_constants::DOS, glob_constants::NATIVE, etc.?

I think that this is a good way to handle this. It allows the
application -- and therefore eventually the user -- to decide what their
idea of "portable behavior" is. It is also open to potential future
extensions such as a hypothetical ISO globing standard.

> On Wednesday, June 8, 2016 at 5:47:19 AM UTC-7, Tony V E wrote:
>>
>> Do you want cross-platform behaviour or platform-native behaviour?
>>
>> "*.*" is not the same under dos/windows vs unix/mac/linux.
>>
>> ‎Cross platform seems nice, but if a user tpes "*.*" into a custom Open
>> File dialog, I might want (as the user probably expects) per-platform
>> behaviour.
>>
>>
>>
>> Sent from my BlackBerry portable Babbage Device

>> *From: *Morwenn
>> *Sent: *Wednesday, June 8, 2016 4:53 AM
>> *To: *ISO C++ Standard - Future Proposals
>> *Reply To: *std-pr...@isocpp.org <javascript:>
>> *Subject: *[std-proposals] File globbing in the standard library

>>
>> The C++17 standard filesystem library would benefit from a generic file
>> globbing utility, which is a really common operation when dealing with
>> files.
>> Here is a brief description of how I would envision it:
>>

>> - Add a glob dialect to the regular expression libraries (with
>> standard jokers, including **).
>> - Add a glob function to path (or somewhere else) taking an std::regex.
>> - Add overloads to glob for std::string, std::string_view, const char*

>> that default to the newly introduced glob dialect.
>>
>> I guess that the string types mentioned above would use
>> std::filesystem::path::value_type for their value type.
>>
>> I believe that using std::regex allows to have a truly generic globbing
>> interface, while defaulting to a regular glob dialect provides the
>> behaviour people expect by default for a glob function.
>>
>> Any thoughts about such a design?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.

>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/860ea5e8-d2f7-46d1-b1e0-e5493195fa28%40isocpp.org

>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/860ea5e8-d2f7-46d1-b1e0-e5493195fa28%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>>

--
OpenPGP:

Public Key: http://openpgp.klammler.eu
Fingerprint: 2732 DA32 C8D0 EEEC A081 BE9D CF6C 5166 F393 A9C0