Plattform independent basename function

[Markus Litz]

Hi,

are there functions for platform independent basename/dirname
stripping? For windows (msvc), there is _splitpath() in <stdio.h>, and
with linux I can use basename()/dirname() from <libgen.h>.

I couldn't find some kind of posix functions for that. Am I missing
something?

Thanks
Markus

 

[Nelu]

Hi,

are there functions for platform independent basename/dirname
stripping? For windows (msvc), there is _splitpath() in <stdio.h>, and
with linux I can use basename()/dirname() from <libgen.h>.
No.

I couldn't find some kind of posix functions for that. Am I missing
something?

My man page on basename, dirname in libgen.h says:
CONFORMING TO:
POSIX.1-2001

You should ask on a POSIX group as you'll get a better answer to this
question there (comp.unix.programmer, maybe).

 

[Nelu]

Hey, buddy!

Those *are* the POSIX functions and header.

Where's the redirection?

You're probably going to get flamed, so keep in mind that some people
on this newsgroup think only ISO C should be on-topic, whereas many of
us (and not just the people called "trolls", mind you) are willing to
discuss POSIX functions instead of rudely kicking you off to another
newsgroup.

To the OP:
Han is a troll.

 

[Lew Pitcher]

Hi,

are there functions for platform independent basename/dirname
stripping? For windows (msvc), there is _splitpath() in <stdio.h>, and
with linux I can use basename()/dirname() from <libgen.h>.

Given that disparate platforms implement path strings differently (or not at
all[1]), there doesn't seem to be /standard/ platform independent
basename/dirname functions.

I couldn't find some kind of posix functions for that. Am I missing
something?

basename() and dirname() /are/ POSIX functions.

Thanks
Markus

[1] Some platforms don't implement "paths". Some implement files with a
path-like non-hierarchical file naming convention (vis S/370 and later
systems, where filenames have multiple components, but no "directory"
structure), while others don't even provide that degree of flexibility.
--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------

 

[Nelu]

Idiot. If you're going to rear your sockpuppet head on here, at least give
the correct answers.

There was a yes/no question. No is the answer.

Yes, I noticed you've been checking your man page a lot in the
last day. That should tell everyone all they need to know about
your real-world programming experience.

One would think you wouldn't have to check a man page for such
basic and commonly known POSIX functions.

I don't know when the functions became available in POSIX and I don't
care. The man page is a very good reference. I am using N1124 as a
reference for the standard. That says nothing about my real world
experience and that shouldn't even matter. If I'm making mistakes
correct me and try to leave insults aside. Can you do that?

 

[Keith Thompson]

I am using N1124 as a reference for the standard.

[...]

N1256 is more up to date.

<http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf>

 

[Nelu]

I am using N1124 as a reference for the standard.

[...]

N1256 is more up to date.

<http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf>

Thank you.

 

[jameskuyper]

Nelu wrote:
....

care. The man page is a very good reference. I am using N1124 as a
reference for the standard. That says nothing about my real world
experience and that shouldn't even matter.

I've been using Unix-like systems and C on and off since 1978, and
continually since 1994. I still routinely refer to man pages for
standard library functions I use infrequently (oddly enough, because
of the peculiar environment I work in, that includes most of the
unformatted I/O functions). It's no dishonor to rely on the manual;
the important thing is to know what you're looking for when you go to
the manual, and to know how to read it once you've found it.

 

[Kaz Kylheku]

Where's the redirection?

Here:

echo $(dirname $(basename topicality/flamewar)) > /dev/null

 

[Antoninus Twink]

are there functions for platform independent basename/dirname
stripping? For windows (msvc), there is _splitpath() in <stdio.h>, and
with linux I can use basename()/dirname() from <libgen.h>.

If GPL code is OK for you, the GNU implementation of basename is highly
portable (including to Windows):


#if defined _WIN32 || defined __WIN32__ || defined __EMX__ || defined __DJGPP__
/* Win32, OS/2, DOS */
# define HAS_DEVICE(P) \
((((P)[0] >= 'A' && (P)[0] <= 'Z') || ((P)[0] >= 'a' && (P)[0] <= 'z')) \
&& (P)[1] == ':')
# define FILESYSTEM_PREFIX_LEN(P) (HAS_DEVICE (P) ? 2 : 0)
# define ISSLASH(C) ((C) == '/' || (C) == '\\')
#endif

#ifndef FILESYSTEM_PREFIX_LEN
# define FILESYSTEM_PREFIX_LEN(Filename) 0
#endif

#ifndef ISSLASH
# define ISSLASH(C) ((C) == '/')
#endif

char *
basename (char const *name)
{
char const *base = name += FILESYSTEM_PREFIX_LEN (name);
int all_slashes = 1;
char const *p;

for (p = name; *p; p++)
{
if (ISSLASH (*p))
base = p + 1;
else
all_slashes = 0;
}

/* If NAME is all slashes, arrange to return `/'. */
if (*base == '\0' && ISSLASH (*name) && all_slashes)
--base;

/* Make sure the last byte is not a slash. */
assert (all_slashes || !ISSLASH (*(p - 1)));

return (char *) base;
}

 

[Antoninus Twink]

are there functions for platform independent basename/dirname
stripping? For windows (msvc), there is _splitpath() in <stdio.h>, and
with linux I can use basename()/dirname() from <libgen.h>.

If GPL code is OK for you, the GNU implementation of basename is highly
portable (including to Windows):


#if defined _WIN32 || defined __WIN32__ || defined __EMX__ || defined __DJGPP__
/* Win32, OS/2, DOS */
# define HAS_DEVICE(P) \
((((P)[0] >= 'A' && (P)[0] <= 'Z') || ((P)[0] >= 'a' && (P)[0] <= 'z')) \
&& (P)[1] == ':')
# define FILESYSTEM_PREFIX_LEN(P) (HAS_DEVICE (P) ? 2 : 0)
# define ISSLASH(C) ((C) == '/' || (C) == '\\')
#endif

#ifndef FILESYSTEM_PREFIX_LEN
# define FILESYSTEM_PREFIX_LEN(Filename) 0
#endif

#ifndef ISSLASH
# define ISSLASH(C) ((C) == '/')
#endif

char *
basename (char const *name)
{
char const *base = name += FILESYSTEM_PREFIX_LEN (name);
int all_slashes = 1;
char const *p;

for (p = name; *p; p++)
{
if (ISSLASH (*p))
base = p + 1;
else
all_slashes = 0;
}

/* If NAME is all slashes, arrange to return `/'. */
if (*base == '\0' && ISSLASH (*name) && all_slashes)
--base;

/* Make sure the last byte is not a slash. */
assert (all_slashes || !ISSLASH (*(p - 1)));

return (char *) base;
}

 

[user923005]

Hi,

are there functions for platform independent basename/dirname
stripping? For windows (msvc), there is _splitpath() in <stdio.h>, and
with linux I can use basename()/dirname() from <libgen.h>.

Maybe this can help you:
http://svn.musepack.net/libmpc/trunk/win32/

I couldn't find some kind of posix functions for that. Am I missing
something?

The Windows Posix layer is hard to use. You download a couple hundred
MB of stuff and then none of your makefiles work because the
configuration is not recognized by most of the projects I have seen
(IOW forget about ./configure working).

So use an emulation layer if you need it.

 

[user923005]

On January 21, 2009 08:32, in comp.lang.c, Markus Litz
([email protected]) wrote:

Given that disparate platforms implement path strings differently (or not at
all[1]), there doesn't seem to be /standard/ platform independent
basename/dirname functions.

I suspect that where it gets  tricky is that there are some
implementations that don't have these concepts. Whats the basename for
these files for instance? Do you include the version number or not?

FOO:RA0:[000000.HELLO.MUM]myfile.txt;99

basename = myfile.txt;99

FOO:RA0:[000000.HELLO.MUM]myfile.txt;98

basename = myfile.txt;98

FOO:RA0:[000000.HELLO.MUM]myfile.txt;97

basename = myfile.txt;97

If C++ is acceptable, you can use the ACE Api, which works on lots of
operating systems (including OpenVMS):
http://www.cs.wustl.edu/~schmidt/ACE-versions-i.html

Interface:
/**
* Returns the "basename" of a @a pathname separated by @a delim.
* For instance, the basename of "/tmp/foo.cpp" is "foo.cpp" when
* @a delim is @a '/'.
*/
extern ACE_Export const ACE_TCHAR *basename (const ACE_TCHAR
*pathname,
ACE_TCHAR delim =

ACE_DIRECTORY_SEPARATOR_CHAR);

 

[Markus Litz]

Maybe this can help you:http://svn.musepack.net/libmpc/trunk/win32/


The Windows Posix layer is hard to use.  You download a couple hundred
MB of stuff and then none of your makefiles work because the
configuration is not recognized by most of the projects I have seen
(IOW forget about ./configure working).

So use an emulation layer if you need it.

Thanks, there were a lot of good answers. Sorry for posting in the
wrong group.

 

[Guest]

There was a yes/no question. No is the answer.

it's up to you of course but HfC is best ignored. Responses just
encourage him.

<snip>

 

[Guest]

Lew Pitcher wrote:

Given that disparate platforms implement path strings differently (or
not at all[1]), there doesn't seem to be /standard/ platform
independent basename/dirname functions.
[1] Some platforms don't implement "paths". Some implement files with
a path-like non-hierarchical file naming convention (vis S/370 and

Hideous isn't it?  I dislike pretty much everything about IBM architecture,
but I tried not to expect allot from a company that implements access
controls thru a separate running process.  Once you toss in EBCDIC, it's all
too weird for me.

this is abit unfair. I think much of this stuff preceeded
what we now regard as obvious. Unix-like file systems
anly seem obvious with 20/20 hindsight

There's a quote along the lines of

"programing an IBM mainframe is akin to kicking a dead whale
down a beach"

 

[James Kuyper]

Lew Pitcher wrote: ....

Given that disparate platforms implement path strings differently (or not at
all[1]), there doesn't seem to be /standard/ platform independent
basename/dirname functions.

I suspect that where it gets tricky is that there are some
implementations that don't have these concepts. Whats the basename for
these files for instance? Do you include the version number or not?

FOO:RA0:[000000.HELLO.MUM]myfile.txt;99

basename = myfile.txt;99

FOO:RA0:[000000.HELLO.MUM]myfile.txt;98

basename = myfile.txt;98

FOO:RA0:[000000.HELLO.MUM]myfile.txt;97

basename = myfile.txt;97

Obviously, you've made a choice. The point is, the other choice is also
defensible.

 

[Kenny McCormack]

Han from China - Master Troll <[email protected]> summed
things up well thusly:
....

This newsgroup has the potential to become the best in the comp.lang.*
hierarchy again, but at present, it's a laughing stock. The arrogance,
nitpicking, Net Nannying, and overall unfriendliness are beyond belief.

Again, I have to ask: Why does this group (and no other technical group
[AFAIK]) get trolled? So routinely, and so well.

It has to boil down to one or more of the following:

1) Because (as we suspect) the people involved (the "regs") really are
the sick, sad, pathetic losers that we think they are. This
newsgroup is their whole life, and (as I stated in a previous post),
the notion that countable minutes might go by in their lives with an
"off topic" post going unanswered fills them with fear and dread. I
mean, I can just see it: KT out at a wedding or something and
suddenly falling ill, writhing on the ground in agony, repeating
over and over: Must get to computer. Must check for OT posts in CLC.

or

2) That, and let's grant that their definition of "What is C?" is valid
(which it isn't), that the idea of a C newsgroup just isn't relevant
(any more). On this theory, it may well be that the setting of a
Usenet newsgroup just isn't compatible with "C as they define it".
Well, the first rule of anything is that you have to stay relevant
(or die). So, I suggest that we either do what's necessary to make
CLC relevant (again), or we accept that it is dying/dead.

 

[user923005]

Lew Pitcher wrote: ...
Given that disparate platforms implement path strings differently (or not at
all[1]), there doesn't seem to be /standard/ platform independent
basename/dirname functions.
I suspect that where it gets  tricky is that there are some
implementations that don't have these concepts. Whats the basename for
these files for instance? Do you include the version number or not?
FOO:RA0:[000000.HELLO.MUM]myfile.txt;99 basename = myfile.txt;99
FOO:RA0:[000000.HELLO.MUM]myfile.txt;98 basename = myfile.txt;98
FOO:RA0:[000000.HELLO.MUM]myfile.txt;97

basename = myfile.txt;97

Obviously, you've made a choice. The point is, the other choice is also
defensible.

I think that my definition follows naturally from the Posix definition
of basename:
"The functions dirname() and basename() break a null-terminated
pathname string into directory and filename components."

However, a more interesting question might be:
DALLAS"SAM SECReturn":ISK0:[MODEL.TEST]TEST.DAT;-1
This one seems a bit more ambiguous to me.
Dirname isn't really a directory, and the -1 indicates "the previous
version from the latest" which I am not sure would be clearly
specified by the Posix definition.

 

[jameskuyper]

On Jan 21, 3:29 pm, Mark McIntyre <[email protected]>
wrote:
Lew Pitcher wrote: ...
Given that disparate platforms implement path strings differently (or not at
all[1]), there doesn't seem to be /standard/ platform independent
basename/dirname functions.
I suspect that where it gets tricky is that there are some
implementations that don't have these concepts. Whats the basename for
these files for instance? Do you include the version number or not?

FOO:RA0:[000000.HELLO.MUM]myfile.txt;99
basename = myfile.txt;99

FOO:RA0:[000000.HELLO.MUM]myfile.txt;98
basename = myfile.txt;98

FOO:RA0:[000000.HELLO.MUM]myfile.txt;97
basename = myfile.txt;97

Obviously, you've made a choice. The point is, the other choice is also
defensible.

I think that my definition follows naturally from the Posix definition
of basename:
"The functions dirname() and basename() break a null-terminated
pathname string into directory and filename components."

And it can be argued that the ';97' at the end isn't part of the
filename, it's a version specifier, recognized as such at a very
fundamental level by the VMS operating system.