Makes sense. I used the function in these gnulib modules that currently do
not have a dependency on basename (i believe): exclude, fts, glob, link,
progname.I noticed for some, like link, they reimplement the basename
functionality (although slightly lacking):
https://github.com/coreutils/gnul
Mitch Capper wrote:
> Right now filename has no
> dependencies but doing this adds basename. I understand circular
> dependencies can be handled, but am I fine to just add a new dependency on
> a core module like this?
No, it's better if 'filename' stays as a module without dependencies.
Therefor
Not thinking of the bigger picture, rather than looking to replicate the
string functionality originally there I should have considered the end goal
before evaluating possible gnulib modules. Will update. This does bring
me back to part of the original question. Right now filename has no
depend
Mitch Capper wrote:
> there is no gnulib module for strrpbrk or strrcspn.
Indeed, such functions are non-standard and not in gnulib.
> This was used for
> the LAST_SLASH_IN_PATH macro I added. I temporarily just added a static
> implementation to the header along the lines of:
> ```
> static con
That was my mistake, missed an r in there which also means there is no
gnulib module for strrpbrk or strrcspn. This was used for
the LAST_SLASH_IN_PATH macro I added. I temporarily just added a static
implementation to the header along the lines of:
```
static const char* strrpbrk(const char* s,
Mitch Capper wrote:
> I did implement most of the shared path code in lib/filename.h but for
> windows I do need strpbrk. Am I ok to just add that as a dependency for
> the filename module?
You don't even need this dependency, since native Windows has strpbrk
and since the doc (doc/posix-functio
> If I have understood it correctly, the best way to handle file names on
native
> Windows is to
> - use '\\' as a directory separator when composing file names,
> - allow both '/' and '\\' when inspecting file names.
Yes, that is largely what I implemented. There is a platform
specific DIR_SEPA
Mitch Capper wrote:
> *With Path accidental separator detection*
> The windows path branch tries to add either forward or backward path
> separator support in windows. Clearly \ is also the escape char so it is
> possible that there are places that A) windows paths that have escape chars
> used w
