Separating directory from file name

[Joe Laughlin]

If I have a character array with "/some/file/directory/file_name", are there
any functions / libraries that I could use to separate the directory
("some/file/directory") from the file name ("file_name" ).

I looked at sscanf(), but that didn't seem to do what I wanted.

Thanks,
Joe

[Dan Pop]

In <Hy********@new s.boeing.com> "Joe Laughlin" <Jo************ ***@boeing.com> writes:

If I have a character array with "/some/file/directory/file_name", are there
any functions / libraries that I could use to separate the directory
("some/file/directory") from the file name ("file_name" ).

I looked at sscanf(), but that didn't seem to do what I wanted.

If you want to deal with strings in C, you *really* need to study the
description of <string.h> in your favourite C book.

It is obvious that what you need is the address of the last '/' character
in your character array. The standard library function that finds the
last occurrence of a character in a string is strrchr. If the function
fails to find it, the whole character array must be considered the file
name.

So, if you can overwrite your character array, after

char *fn = strrchr(array, '/');
if (fn != NULL) *fn++ = 0;
else fn = array;

fn will point to the file name and, if fn != array, array will contain the
path name.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[CBFalconer]

Martin Dickopp wrote:

.... snip ...
Your algorithm is inefficient in that it first scans the complete
string to find its end (strlen), and then scans part of the string
/again/ to find the last slash. This can be avoided by scanning the
string once and in the process remembering the last slash encountered.

Not necessarily so. The comparisons made in the combined scan can
be much less efficient, and necessarily encompass the complete
string. The second half of the separated scan starts from the
end, and may be much shorter.

--
fix (vb.): 1. to paper over, obscure, hide from public view; 2.
to work around, in a way that produces unintended consequences
that are worse than the original problem. Usage: "Windows ME
fixes many of the shortcomings of Windows 98 SE". - Hutchison

[Alan Balmer]

On Wed, 2 Jun 2004 00:15:08 GMT, "Joe Laughlin"
<Jo************ ***@boeing.com> wrote:

Tom St Denis wrote:

Joe Laughlin wrote:

If I have a character array with
"/some/file/directory/file_name", are there any
functions / libraries that I could use to separate the
directory ("some/file/directory") from the file name
("file_name" ).

I looked at sscanf(), but that didn't seem to do what I
wanted.

Homework question BEGONE!

[hint cuz I want you to fail at your job by being unable
to solve
trivial problems yourself....: scan backwards in the
string for the first /]

Tom

I'm not familar with C character array processing, sorry. Again, are there
any standard libraries that would let me scan backwards, or do I need to do
this manually?

If this is a homework question, you need to have a talk with your
instructor. If it isn't homework, I think you need to hire a
programmer.

--
Al Balmer
Balmer Consulting
re************* ***********@att .net

[nobody]

"Joe Laughlin" <Jo************ ***@boeing.com> wrote in message
news:Hy******** @news.boeing.co m...

If I have a character array with "/some/file/directory/file_name", are there any functions / libraries that I could use to separate the directory
("some/file/directory") from the file name ("file_name" ).

I looked at sscanf(), but that didn't seem to do what I wanted.

I don't know about any standard C answer to the stated problem,
but your example might imply UNIX pathname syntax (although
also acceptend on Windoze, though not on command line). So even
standard C answer (e.g. strrchr(), as suggested) may be platform specific.
If you are on UNIX, there should be basename(3C). For details
see e.g. here:
http://docs.sun.com/db/doc/805-3175/...name-3c-indx-1

My apologies to the group for an OT answer. But in this case I consider
it worth giving. It's not portable, but neither are some others. I've
already
forgotten what path looked like on VAX. Original problem was to extract
file name from the full path name, not to find last '/'.

[Mabden]

"CBFalconer " <cb********@yah oo.com> wrote in message
news:40******** *******@yahoo.c om...

Martin Dickopp wrote:

... snip ...

Your algorithm is inefficient in that it first scans the complete
string to find its end (strlen), and then scans part of the string
/again/ to find the last slash. This can be avoided by scanning the
string once and in the process remembering the last slash encountered.

Not necessarily so. The comparisons made in the combined scan can
be much less efficient, and necessarily encompass the complete
string. The second half of the separated scan starts from the
end, and may be much shorter.

I'm afraid I have to agree with Martin. (Ouch)

All algorithms I have seen in c that "start at the end" of a string,
actually scan forwards to a '/0'. If this were Pascal, where the length is
given and you could jump to the end of the string with a memory read (and a
256 byte size limit) then you might be correct. But in C you are better off
storing the slashes as you find them and only scan once through the string.
I have never found strrchr() to be very useful, as I can build a loop that
does what I want better than the standard function.

--
Mabden

[Martin Dickopp]

"Mabden" <ma****@sbcglob al.net> writes:

"CBFalconer " <cb********@yah oo.com> wrote in message
news:40******** *******@yahoo.c om...

Martin Dickopp wrote:

>

... snip ...

>
> Your algorithm is inefficient in that it first scans the complete
> string to find its end (strlen), and then scans part of the string
> /again/ to find the last slash. This can be avoided by scanning the
> string once and in the process remembering the last slash encountered.

Not necessarily so. The comparisons made in the combined scan can
be much less efficient, and necessarily encompass the complete
string. The second half of the separated scan starts from the
end, and may be much shorter.

I'm afraid I have to agree with Martin. (Ouch)

Chuck does have a point. I think the important message is that my
implementation is not guaranteed to be more efficient than the original
one, but neither vice versa. If it matters, some benchmarking for
typical input strings must be done.

Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/

[Mabden]

Hey, Martin! I thought you killfiled me over some comedy I posted once! Did
you grow a sensual humor?

--
Mabden

[CBFalconer]

Mabden wrote:

"CBFalconer " <cb********@yah oo.com> wrote in message

Martin Dickopp wrote:

... snip ...

Your algorithm is inefficient in that it first scans the complete
string to find its end (strlen), and then scans part of the string
/again/ to find the last slash. This can be avoided by scanning the
string once and in the process remembering the last slash encountered.

Not necessarily so. The comparisons made in the combined scan can
be much less efficient, and necessarily encompass the complete
string. The second half of the separated scan starts from the
end, and may be much shorter.

I'm afraid I have to agree with Martin. (Ouch)

All algorithms I have seen in c that "start at the end" of a string,
actually scan forwards to a '/0'. If this were Pascal, where the length is
given and you could jump to the end of the string with a memory read (and a
256 byte size limit) then you might be correct. But in C you are better off
storing the slashes as you find them and only scan once through the string.
I have never found strrchr() to be very useful, as I can build a loop that
does what I want better than the standard function.

The difference lies in the complexity of the initial scan. The
two scan looks something like:

p = ptr;
while (*p++) continue;
p--;
while (('/' != *p) && (p > ptr)) p--;

while the complex single scan is something like:

pp = NULL; p = ptr;
while (*p) {
if ('/' == *p) pp = p;
p++;
}

--
fix (vb.): 1. to paper over, obscure, hide from public view; 2.
to work around, in a way that produces unintended consequences
that are worse than the original problem. Usage: "Windows ME
fixes many of the shortcomings of Windows 98 SE". - Hutchison

[Chris McDonald]

CBFalconer <cb********@yah oo.com> writes:

The difference lies in the complexity of the initial scan. The
two scan looks something like: p = ptr;
while (*p++) continue;
p--;
while (('/' != *p) && (p > ptr)) p--; while the complex single scan is something like: pp = NULL; p = ptr;
while (*p) {
if ('/' == *p) pp = p;
p++;
}

Is there something inherently wrong with using standard functions, here,
or is this just a macho contest? Such as:

argv0 = (argv0 = strrchr(argv[0],'/')) ? argv0+1 : argv[0];

and assuming that the standard functions will be reasonably implemented
and tested?

_______________ _______________ _______________ _______________ _______________ ____
Dr Chris McDonald EMAIL: ch***@csse.uwa. edu.au
School of Computer Science & Software Engineering
The University of Western Australia WWW: http://www.csse.uwa.edu.au/~chris
Crawley, Western Australia, 6009 PH: [phone], FAX: [phone]

[Dan Pop]

In <4n************ *******@newssvr 25.news.prodigy .com> "Mabden" <ma****@sbcglob al.net> writes:

"CBFalconer " <cb********@yah oo.com> wrote in message
news:40******* ********@yahoo. com...

Martin Dickopp wrote:

> ... snip ...

>
> Your algorithm is inefficient in that it first scans the complete
> string to find its end (strlen), and then scans part of the string
> /again/ to find the last slash. This can be avoided by scanning the
> string once and in the process remembering the last slash encountered.

Not necessarily so. The comparisons made in the combined scan can
be much less efficient, and necessarily encompass the complete
string. The second half of the separated scan starts from the
end, and may be much shorter.

I'm afraid I have to agree with Martin. (Ouch)

All algorithms I have seen in c that "start at the end" of a string,
actually scan forwards to a '/0'. If this were Pascal, where the length is
given and you could jump to the end of the string with a memory read (and a
256 byte size limit) then you might be correct. But in C you are better off

^^^^^^^^^^^^^^^ ^^^^^^^^^^^^storing the slashes as you find them and only scan once through the string. ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^I have never found strrchr() to be very useful, as I can build a loop that
does what I want better than the standard function.

What makes you think that strrchr() doesn't work exactly as you have
described above? All the generic C implementations of strrchr() I am
familiar with do a single scan, until they find the null character and
"remember" the last address of the target character.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de