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
e certainly like to see fixes in this area.
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.
Bruno
t it would be trivial to add support for some future
operating
system that decides to use a different character (neither / nor \) as the
directory
separator.
A third reason: "a/b" looks to me like a mathematical expression, whereas
"a" DIRECTORY_SEPARATOR_STRING "b&quo
On 06/07/2012 12:19 AM, John Darrington wrote:
> Surely using a symbol instead of a literal constant makes maintenance easier
> not
> harder?
I don't see why. For example:
remove ("a/b");
is simpler and easier to maintain than:
#if DIRECTORY_SEPARATOR == '/'
#define DIRECTORY_SEPARAT
On Wed, Jun 06, 2012 at 01:07:41PM -0700, Paul Eggert wrote:
On 06/06/2012 12:43 PM, John Darrington wrote:
> If as you say, windows prefers \ is there a good reason NOT to use it?
Mostly to avoid the maintenance hassle.
Surely using a symbol instead of a literal constant mak
On 06/06/2012 12:43 PM, John Darrington wrote:
> If as you say, windows prefers \ is there a good reason NOT to use it?
Mostly to avoid the maintenance hassle.
Also, the change makes the code a bit bigger and slower
even on non-Windows platforms.
On Wed, Jun 06, 2012 at 01:10:09PM -0600, Eric Blake wrote:
On 06/06/2012 12:54 PM, John Darrington wrote:
> I'm offering this patch which ensures that the paths of tempfiles are
> created with the appropriate separator for the machine.
What platform did you need it on?
On 06/06/2012 12:54 PM, John Darrington wrote:
> I'm offering this patch which ensures that the paths of tempfiles are
> created with the appropriate separator for the machine.
What platform did you need it on? Windows understands paths with /,
even if it prefers \ as the canonical separator, an
I'm offering this patch which ensures that the paths of tempfiles are
created with the appropriate separator for the machine.
J'
--
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
See http://keys.gnupg.net or any PGP keyserver for public key.
15 matches
Mail list logo
