Filename.{Unix,Win32,Cygwin} should be exported

[vicuna]

Original bug ID: 6287 Reporter: furuse Status: confirmed (set by @damiendoligez on 2014-07-16T12:56:43Z) Resolution: open Priority: normal Severity: feature Version: 4.01.0 Category: standard library Tags: patch, junior_job Monitored by: @dra27

Bug description

stdlib's Filename provides filename handling functions specific for the current OS, but actually it defines for the 3 main flavors: Unix, Win32 and Cygwin. But they are hidden. They should be exported, probably with a small tweak to have the same signatures (for example, has_drive is only defined in Win32.)

I got some bug reports about my software that it does not run under Win32, and it was due to a typical failure of ignoring the drive name. I wrote a fix but it was lousy to test it since Filename.Win32 is not accessible. So far I copied filename.ml since its license matches with one of my software. But it is just a workaround.

File attachments

• filename.diff
• filename_2.diff
• filename_3.diff

[vicuna]

Comment author: @damiendoligez

Indeed, when running a program under cygwin that also launches native Windows executables, you need both Filename.Unix.quote and Filename.Win32.quote.

[vicuna]

Comment author: nevor

I have attached a patch that expose the common set of functions augmented with the concat function.

[vicuna]

Comment author: @damiendoligez

Re: filename.mli

Ouch. If we want to export them with the same signature (and I agree we do), we should define one "module type" for this signature and then declare the three modules with this signature, instead of triplicating the declarations.

So don't apply the patch as-is.

[vicuna]

Comment author: nevor

Indeed, I thought about this but didn't know how detailed the documentation had to be (w.r.t. differences between implementations). I have attached a new proposition.

[github-actions[bot]]

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

[nojb]

What do people think about this request? The current implementation of Filename already defines the modules for each system, it would be just a matter of exposing them in the interface.

[nojb]

(my own personal opinion is that indeed there are some cases where having these modules available would be useful, but it is not something that comes up very often).

[hcarty]

I'd like to have access to these submodules as well!

[dra27]

I've a branch and even a document about it from around when #9719 was opened. Hopefully at some point post-5.0 it might even become a PR (trying to expose this properly revealed several subtle issues certainly with Cygwin's filename handling).