Parsing a path name

[drhowarddrfine]

I'm working with a server that will provide me the pathname to a file,
among many paths. So from getenv I may get /home/myweb/page1 but, of
course, there will be many variations of that. I'm unsure of the best
way to go about following the path. Should I read one char at a time
or use scanf? The problem could occur with something like
/home/mypage/page1/page1/page2/page2, for example.

I have not been programming in a few years so I could use a few hints,
tips, links and C functions. tia

[Richard Heathfield]

drhowarddrfine said:

I'm working with a server that will provide me the pathname to a file,
among many paths. So from getenv I may get /home/myweb/page1 but, of
course, there will be many variations of that. I'm unsure of the best
way to go about following the path. Should I read one char at a time
or use scanf? The problem could occur with something like
/home/mypage/page1/page1/page2/page2, for example.

Presumably you define "path" as "series of short steps, each of which begins
with a / character, and is followed either by another such step, or by the
end of the string".

So parse it in steps:

#include <stdio.h>

#define MAX_STEP_LEN 256 /* in your example, 8 would have done! */

int get_step(char *out, char **cur, char sep, size_t max)
{
int rc = 0;
if(**cur != '\0')
{
*out++ = **cur;
++*cur;
--max;

while(max 0 && **cur != '\0' && **cur != sep)
{
*out++ = **cur;
++*cur;
--max;
}
*out = '\0';
rc = 1;
}
return rc;
}

int main(void)
{
char path[] = "/home/mypage/page1/page1/page2/page2";
char step[MAX_STEP_LEN] = {0};

char *curstep = path;
while(get_step(step, &curstep, '/', MAX_STEP_LEN))
{
printf("[%s]\n", step);
}

return 0;
}

Output:

[/home]
[/mypage]
[/page1]
[/page1]
[/page2]
[/page2]

If that does what you want, great. If not, it should at least get you
started.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Fred Kleinschmidt]

"drhowarddrfine" <ro*******@gmail.comwrote in message
news:11********************@e3g2000cwe.googlegroup s.com...

I'm working with a server that will provide me the pathname to a file,
among many paths. So from getenv I may get /home/myweb/page1 but, of
course, there will be many variations of that. I'm unsure of the best
way to go about following the path. Should I read one char at a time
or use scanf? The problem could occur with something like
/home/mypage/page1/page1/page2/page2, for example.

What *problem* are you talking about?
What is it that you are actually trying to do?

>
I have not been programming in a few years so I could use a few hints,
tips, links and C functions. tia

--
Fred L. Kleinschmidt
Boeing Associate Technical Fellow
Technical Architect, Software Reuse Project

[Paul Connolly]

it is difficult to understand what you want to do - you might want to use
strtok to split up your string, delimited by slashes

[drhowarddrfine]

Richard may have provided the answer. As the title said, I'm trying to
parse the pathname. The web pages on this server are all dynamically
created using C but I need to find the path to the final web page so I
know what page to create. I thought of reading each char until I hit a
slash then doing a strcmp or some such to find where to go next to
continue down the path.

[Christopher Layne]

Paul Connolly wrote:

it is difficult to understand what you want to do - you might want to use
strtok to split up your string, delimited by slashes

strtok() is a POS, do not use this function. Roll your own or use an external
pre-exsting. But don't use strtok().

[kondal]

Christopher Layne wrote:

Paul Connolly wrote:

it is difficult to understand what you want to do - you might want to use
strtok to split up your string, delimited by slashes

strtok() is a POS, do not use this function. Roll your own or use an external
pre-exsting. But don't use strtok().

What is POS?

[Richard Heathfield]

Christopher Layne said:

Paul Connolly wrote:

>it is difficult to understand what you want to do - you might want to use
strtok to split up your string, delimited by slashes

strtok() is a POS, do not use this function. Roll your own or use an
external pre-exsting. But don't use strtok().

I disagree. Whilst it is true that the circumstances in which one might find
strtok() appropriate for use are somewhat limited, they do nevertheless
exist; it is no gets() clone, I assure you. I certainly have no qualms
about using strtok() - except when it is not appropriate.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Richard Heathfield]

kondal said:

>
Christopher Layne wrote:

>Paul Connolly wrote:

it is difficult to understand what you want to do - you might want to
use strtok to split up your string, delimited by slashes

strtok() is a POS, do not use this function. Roll your own or use an
external pre-exsting. But don't use strtok().

What is POS?

Point Of Sale. :-)
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Richard Bos]

"kondal" <ko******@gmail.comwrote:

Christopher Layne wrote:

Paul Connolly wrote:

it is difficult to understand what you want to do - you might want to use
strtok to split up your string, delimited by slashes

strtok() is a POS, do not use this function. Roll your own or use an external
pre-exsting. But don't use strtok().

What is POS?

Point Of Sale?

But no, strtok() is rarely the function to use, but not never. In this
case, it _might_ work, but it probably won't be the best choice.

Richard

[drhowarddrfine]

kondal wrote:

Christopher Layne wrote:

Paul Connolly wrote:

What is POS?

Technical term meaning "Piece Of S***"

[Simon Biber]

Richard Heathfield wrote:

Christopher Layne said:

>Paul Connolly wrote:

>>it is difficult to understand what you want to do - you might want to use
strtok to split up your string, delimited by slashes

strtok() is a POS, do not use this function. Roll your own or use an
external pre-exsting. But don't use strtok().

I disagree. Whilst it is true that the circumstances in which one might find
strtok() appropriate for use are somewhat limited, they do nevertheless
exist; it is no gets() clone, I assure you. I certainly have no qualms
about using strtok() - except when it is not appropriate.

I wrote some code that parses commands (received over a network socket,
but that's irrelevant here).

The commands' names and functions that implement them are stored in an
array of structs:

struct Command
{
const char *name;
void (*function)(void);
} commands[] = {
{"help", cmd_help},
{"quit", cmd_quit},
{"foo", cmd_foo},
{"bar", cmd_bar}
};
size_t num_commands = sizeof commands / sizeof *commands;

One function starts off the strtok process, extracting the first token
to determine the command name and pass off the rest of the processing to
a specific function.

The command choice code looks like:

/* Start parsing it. Pointer q now contains the first token,
the name of the command */
char *q = strtok(p, " ");

/* Iterate through the commands, comparing names, until
we find one that matches */
size_t i;
for(i = 0; i < num_commands; i++)
{
if(!strcmp(q, commands[i]->name))
{
/* call the function that implements this command */
commands[i]->function();
break;
}
}

if(i == num_commands)
{
send_message("error no_such_command\n");
}

Whereupon the individual command's implementation function continues the
parsing process:

static void cmd_foo()
{
char *arg1 = strtok(NULL, " ");
if(arg1)
{
send_message("success foo\n");
}
else
{
send_message("error foo no_argument\n");
}
}

Different commands can take a different number of arguments.

--
Simon.

[drhowarddrfine]

Richard Heathfield wrote:

Christopher Layne said:

Paul Connolly wrote:
strtok() is a POS, do not use this function. Roll your own or use an
external pre-exsting. But don't use strtok().

I disagree. Whilst it is true that the circumstances in which one might find
strtok() appropriate for use are somewhat limited, they do nevertheless
exist; it is no gets() clone, I assure you. I certainly have no qualms
about using strtok() - except when it is not appropriate.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

So what's wrong with strtok?

[Robert Latest]

On 4 Oct 2006 07:59:05 -0700,
drhowarddrfine <ro*******@gmail.comwrote
in Msg. <11**********************@k70g2000cwa.googlegroups .com>

So what's wrong with strtok?

Nothing at all as long as you know what it does and doesn't do and use
it appropriately.

Which can be said about damn near anything, even gets().

robert

[Default User]

drhowarddrfine wrote:

So what's wrong with strtok?

The main problem is that it modifies the string it acts on. In the
particular case, you're getting it from getenv(). The standard says
about that function:

Returns

[#4] The getenv function returns a pointer to a string
associated with the matched list member. The string pointed
to shall not be modified by the program, but may be
overwritten by a subsequent call to the getenv function. If
the specified name cannot be found, a null pointer is
returned.

So to use strtok() in a defined manner, you would have to make a copy
of the string first, which might be an unnecessary step. Without more
details on what you mean by "parse" and what you will do with the
resultant parsed information, it's hard to say what will be most useful.


Brian

[Keith Thompson]

"Default User" <de***********@yahoo.comwrites:

drhowarddrfine wrote:

>So what's wrong with strtok?

The main problem is that it modifies the string it acts on.

The other problem is that it's not reentrant; it depends on static
internal state, so you can't process a string with strtok() in the
middle of processing another string with strtok().

Some implementations provide a non-standard strtok_r() function
(defined by POSIX) that avoids the reentrancy problem, but it still
modifies the string.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Default User]

Keith Thompson wrote:

"Default User" <de***********@yahoo.comwrites:

drhowarddrfine wrote:

So what's wrong with strtok?

The main problem is that it modifies the string it acts on.

The other problem is that it's not reentrant; it depends on static
internal state, so you can't process a string with strtok() in the
middle of processing another string with strtok().

Some implementations provide a non-standard strtok_r() function
(defined by POSIX) that avoids the reentrancy problem, but it still
modifies the string.

Yes. It's not all that difficult to write a safer tokenizer, provided
you don't want to use of the fine examples already out there. I believe
some have been posted here in the past, otherwise they can found on the
web.


Brian

[Andrew Poelstra]

On Wed, 2006-10-04 at 07:24 +0000, Richard Heathfield wrote:

kondal said:

Christopher Layne wrote:

Paul Connolly wrote:

it is difficult to understand what you want to do - you might want to
use strtok to split up your string, delimited by slashes

strtok() is a POS, do not use this function. Roll your own or use an
external pre-exsting. But don't use strtok().

What is POS?

Point Of Sale. :-)

You can use Google and the Urban Dictionary to get the right definition
in this context.

I had to ask my dad... it's really been that long since I was on
MSN. :-}

--
Andrew Poelstra <http://www.wpsoftware.net/projects/>

[CBFalconer]

Keith Thompson wrote:

"Default User" <de***********@yahoo.comwrites:

drhowarddrfine wrote:

>>So what's wrong with strtok?

The main problem is that it modifies the string it acts on.

The other problem is that it's not reentrant; it depends on static
internal state, so you can't process a string with strtok() in the
middle of processing another string with strtok().

Some implementations provide a non-standard strtok_r() function
(defined by POSIX) that avoids the reentrancy problem, but it still
modifies the string.

A third problem is that it doesn't detect null tokens, as signified
by two continuous occurences of the token delimiting char. If
these things matter, you can use the following routine:

/* ------- file toksplit.c ----------*/
#include "toksplit.h"

/* copy over the next token from an input string, after
skipping leading blanks (or other whitespace?). The
token is terminated by the first appearance of tokchar,
or by the end of the source string.

The caller must supply sufficient space in token to
receive any token, Otherwise tokens will be truncated.

Returns: a pointer past the terminating tokchar.

This will happily return an infinity of empty tokens if
called with src pointing to the end of a string. Tokens
will never include a copy of tokchar.

A better name would be "strtkn", except that is reserved
for the system namespace. Change to that at your risk.

released to Public Domain, by C.B. Falconer.
Published 2006-02-20. Attribution appreciated.
Revised 2006-06-13
*/

const char *toksplit(const char *src, /* Source of tokens */
char tokchar, /* token delimiting char */
char *token, /* receiver of parsed token */
size_t lgh) /* length token can receive */
/* not including final '\0' */
{
if (src) {
while (' ' == *src) src++;

while (*src && (tokchar != *src)) {
if (lgh) {
*token++ = *src;
--lgh;
}
src++;
}
if (*src && (tokchar == *src)) src++;
}
*token = '\0';
return src;
} /* toksplit */

#ifdef TESTING
#include <stdio.h>

#define ABRsize 6 /* length of acceptable token abbreviations */

/* ---------------- */

static void showtoken(int i, char *tok)
{
putchar(i + '1'); putchar(':');
puts(tok);
} /* showtoken */

/* ---------------- */

int main(void)
{
char teststring[] = "This is a test, ,, abbrev, more";

const char *t, *s = teststring;
int i;
char token[ABRsize + 1];

puts(teststring);
t = s;
for (i = 0; i < 4; i++) {
t = toksplit(t, ',', token, ABRsize);
showtoken(i, token);
}

puts("\nHow to detect 'no more tokens' while truncating");
t = s; i = 0;
while (*t) {
t = toksplit(t, ',', token, 3);
showtoken(i, token);
i++;
}

puts("\nUsing blanks as token delimiters");
t = s; i = 0;
while (*t) {
t = toksplit(t, ' ', token, ABRsize);
showtoken(i, token);
i++;
}
return 0;
} /* main */

#endif
/* ------- end file toksplit.c ----------*/

--
Some informative links:
<news:news.announce.newusers
<http://www.geocities.com/nnqweb/>
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/>

[Paul Connolly]

"Default User" <de***********@yahoo.comwrote in message
news:4o************@individual.net...

drhowarddrfine wrote:

>So what's wrong with strtok?

The main problem is that it modifies the string it acts on. In the
particular case, you're getting it from getenv(). The standard says
about that function:

Returns

[#4] The getenv function returns a pointer to a string
associated with the matched list member. The string pointed
to shall not be modified by the program, but may be
overwritten by a subsequent call to the getenv function. If
the specified name cannot be found, a null pointer is
returned.

So to use strtok() in a defined manner, you would have to make a copy
of the string first, which might be an unnecessary step. Without more
details on what you mean by "parse" and what you will do with the
resultant parsed information, it's hard to say what will be most useful.


Brian

why doesn't getenv return a const char *?

[Keith Thompson]

"Paul Connolly" <pg********@blueyonder.co.ukwrites:

"Default User" <de***********@yahoo.comwrote in message
news:4o************@individual.net...

[...]

>The main problem is that it modifies the string it acts on. In the
particular case, you're getting it from getenv(). The standard says
about that function:

Returns

[#4] The getenv function returns a pointer to a string
associated with the matched list member. The string pointed
to shall not be modified by the program, but may be
overwritten by a subsequent call to the getenv function. If
the specified name cannot be found, a null pointer is
returned.

So to use strtok() in a defined manner, you would have to make a copy
of the string first, which might be an unnecessary step. Without more
details on what you mean by "parse" and what you will do with the
resultant parsed information, it's hard to say what will be most useful.

why doesn't getenv return a const char *?

Probably for historical reasons. My guess is that the getenv()
function predates the introduction of "const" to the C language.
Existing code that did something like this:

char *foo = getenv("FOO");

would have been broken by such a change. It's similar to the fact
that string literals aren't const; ideally they should be, but it
would have broken existing code.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Ian Collins]

Paul Connolly wrote:

"Default User" <de***********@yahoo.comwrote in message
news:4o************@individual.net...

>>drhowarddrfine wrote:

>>>So what's wrong with strtok?

The main problem is that it modifies the string it acts on. In the
particular case, you're getting it from getenv(). The standard says
about that function:

Returns

[#4] The getenv function returns a pointer to a string
associated with the matched list member. The string pointed
to shall not be modified by the program, but may be
overwritten by a subsequent call to the getenv function. If
the specified name cannot be found, a null pointer is
returned.

So to use strtok() in a defined manner, you would have to make a copy
of the string first, which might be an unnecessary step. Without more
details on what you mean by "parse" and what you will do with the
resultant parsed information, it's hard to say what will be most useful.

why doesn't getenv return a const char *?

Because it predates the widespread use of const char*. Existing code
would break if it where changed.

--
Ian Collins.

[Ian Collins]

Ian Collins wrote:

Because it predates the widespread use of const char*. Existing code
would break if it where changed.

Oops "were changed."

--
Ian Collins.

[Paul Connolly]

"Keith Thompson" <ks***@mib.orgwrote in message

[...]
Probably for historical reasons. My guess is that the getenv()
function predates the introduction of "const" to the C language.
Existing code that did something like this:

char *foo = getenv("FOO");

would have been broken by such a change. It's similar to the fact
that string literals aren't const; ideally they should be, but it
would have broken existing code.

Haven't literal strings been treated more strictly? (and justly so) -
vaguely remember having to set a "rewritable-strings" option on old code
with gcc - the new versions of gcc says this will no longer be supported.

[Keith Thompson]

"Paul Connolly" <pg********@blueyonder.co.ukwrites:

"Keith Thompson" <ks***@mib.orgwrote in message

>[...]
Probably for historical reasons. My guess is that the getenv()
function predates the introduction of "const" to the C language.
Existing code that did something like this:

char *foo = getenv("FOO");

would have been broken by such a change. It's similar to the fact
that string literals aren't const; ideally they should be, but it
would have broken existing code.

Haven't literal strings been treated more strictly? (and justly so) -
vaguely remember having to set a "rewritable-strings" option on old code
with gcc - the new versions of gcc says this will no longer be supported.

String literals aren't const in C (for historical reason), but
attempting to modify one invokes undefined behavior.

If I recall correctly, gcc has (had?) an option to treat string
literals as writable. For example:

char *s = "Hello";
s[0] = 'J';
puts(s);

would print "Jello". (The assignment invokes undefined behavior so
anything the compiler chooses to do with it is ok as far as the
standard is concerned.)

gcc also has an option to treat string literals as const, even though
the standard says they aren't. This does affect some strictly
conforming code, but only by producing some additional warnings, some
of which are confusingly worded, so it's not a conformance violation
for gcc. I have some thoughts about how this could have been done
better, but this is straying off-topic as it is.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Paul Connolly]

"Ian Collins" <ia******@hotmail.comwrote in message
news:4o*************@individual.net...

Because it predates the widespread use of const char*. Existing code
would break if it where changed.
--
Ian Collins.

It would be better if the standard defined getenv to return const char * (to
tell idiots like me that we cannot mutilate the return value) and have a
compiler switch -old-char-ptr-getenv for old code.

[Ian Collins]

Paul Connolly wrote:

"Ian Collins" <ia******@hotmail.comwrote in message
news:4o*************@individual.net...

>>Because it predates the widespread use of const char*. Existing code
would break if it where changed.

It would be better if the standard defined getenv to return const char * (to
tell idiots like me that we cannot mutilate the return value) and have a
compiler switch -old-char-ptr-getenv for old code.

The standard doesn't define compiler options.

I'm afraid we are stuck with a great deal of historical baggage in the C
world. You just have to learn to live with it and read your man pages!

--
Ian Collins.

[Default User]

Paul Connolly wrote:

"Ian Collins" <ia******@hotmail.comwrote in message
news:4o*************@individual.net...

Because it predates the widespread use of const char*. Existing
code would break if it where changed.

It would be better if the standard defined getenv to return const
char * (to tell idiots like me that we cannot mutilate the return
value)

There's tons of legacy code, including many large and sometimes
arcanely written operating systems that people would like to be able to
compile with newer compilers and not have to hack up trying to fix such
things.

and have a compiler switch -old-char-ptr-getenv for old code.

The standard doesn't define such "compiler switches". Therefore there
would be no particular reason for compiler writers to include such
functionality.


Brian

[Paul Connolly]

"Default User" <de***********@yahoo.comwrote in message
news:4o************@individual.net...

Paul Connolly wrote:

>"Ian Collins" <ia******@hotmail.comwrote in message
news:4o*************@individual.net...

Because it predates the widespread use of const char*. Existing
code would break if it where changed.

>It would be better if the standard defined getenv to return const
char * (to tell idiots like me that we cannot mutilate the return
value)

There's tons of legacy code, including many large and sometimes
arcanely written operating systems that people would like to be able to
compile with newer compilers and not have to hack up trying to fix such
things.

>and have a compiler switch -old-char-ptr-getenv for old code.

The standard doesn't define such "compiler switches". Therefore there
would be no particular reason for compiler writers to include such
functionality.

I do not lie to the compiler - but without a const the compiler lies to me.
I didn't vote for the government but that does not negate my right to
criticize - sometimes "the most patriotic thing you can do is dissent."
I am suggesting that the C standard should have made the best decision for
code going forward (and indicate problems in existing code), but compiler
writers should have a mind to pragmatically support old (and dangerous)
definitions - don't organisations that write operating systems tend to
writer compilers too? - for other users the old behaviour is easy to
replicate in a mygetenv function - which keeps a list of copies of the
getenv values that it has been asked for - and looks them up and else
getenvs then into the list and returns the copy allowing it to be mangle as
before.
Also "hack up" is the wrong description of the process required to rewrite
code to compile with a newer compiler - "improve" is a better description.

[Paul Connolly]

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

"Paul Connolly" <pg********@blueyonder.co.ukwrites:

>"Keith Thompson" <ks***@mib.orgwrote in message

>>[...]
Probably for historical reasons. My guess is that the getenv()
function predates the introduction of "const" to the C language.
Existing code that did something like this:

char *foo = getenv("FOO");

would have been broken by such a change. It's similar to the fact
that string literals aren't const; ideally they should be, but it
would have broken existing code.

Haven't literal strings been treated more strictly? (and justly so) -
vaguely remember having to set a "rewritable-strings" option on old code
with gcc - the new versions of gcc says this will no longer be supported.

String literals aren't const in C (for historical reason), but
attempting to modify one invokes undefined behavior.

If I recall correctly, gcc has (had?) an option to treat string
literals as writable. For example:

char *s = "Hello";
s[0] = 'J';
puts(s);

would print "Jello". (The assignment invokes undefined behavior so
anything the compiler chooses to do with it is ok as far as the
standard is concerned.)

In code compiled without the "rewritable-strings" option and an ANSI
compiler which produces an executable that follows the standard's permission
to put string literals in read-only memory, this would cause an access
violation during run time. It is my understanding that in old pre-ANSI code
compiled under a pre-ANSI compiler that string literals were rewritable as
in your example, and the behaviour pre-ANSI was not undefined - is that
correct?

[CBFalconer]

Paul Connolly wrote:

>

.... snip ...

>
I do not lie to the compiler - but without a const the compiler
lies to me. I didn't vote for the government but that does not
negate my right to criticize - sometimes "the most patriotic
thing you can do is dissent." I am suggesting that the C standard
should have made the best decision for code going forward (and
indicate problems in existing code), but compiler writers should
have a mind to pragmatically support old (and dangerous)
definitions - don't organisations that write operating systems
tend to writer compilers too? - for other users the old behaviour
is easy to replicate in a mygetenv function - which keeps a list
of copies of the getenv values that it has been asked for - and
looks them up and else getenvs then into the list and returns the
copy allowing it to be mangle as before.

No pragmas (which are a sinkhole) needed. You can have just what
you want with gcc and the -Wwritestrings option. This doesn't
apply to getenv, however. No compiler will survive when it
arbitrarily makes legacy source erroneous.

--
Some informative links:
<news:news.announce.newusers
<http://www.geocities.com/nnqweb/>
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/>