stripping newline from input

[John Smith]

Hi all

Why doesn't this seem to work?

void stripnl(char *sz)
{
char *nl;
nl = strchr(sz, '\n');
if (nl)
{
*nl = '\0';
}
}

The string fed in still has the newline after calling this function.

Thanks
John

 

[Joona I Palaste]

Hi all

Why doesn't this seem to work?

void stripnl(char *sz)
{
char *nl;
nl = strchr(sz, '\n');
if (nl)
{
*nl = '\0';
}
}

The string fed in still has the newline after calling this function.

It looks like it should work. How are you calling this function? How are
you checking the results?

 

[Ravi Uday]

Hi all

Why doesn't this seem to work?

void stripnl(char *sz)
{
char *nl;
nl = strchr(sz, '\n');
if (nl)
{
*nl = '\0';
}
}

The string fed in still has the newline after calling this function.

How do you know that ? There might be a '\r' (CR- if file is taken from
windows) otherwise the function is fine.

 

[John Smith]

It looks like it should work. How are you calling this function? How are
you checking the results?

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"It was, er, quite bookish."
- Horace Boothroyd

Hi Joona

char szLine[MAX_LINE]; /* this is big enough.. */
char *szToken;

while (fgets(szLine, MAX_LINE, *file) != NULL)
{
szToken = strtok(szLine, " \t:"); /* split by space, tab or colon
characters */
stripnl(szToken);
}

If the line I read in contained say "one_word\n" then the strip newline
doesn't seem to do its thing. Of course if the line contained "two_words
second_word\n", then the token doesn't have a newline to strip out.

I'm sure this stuff worked last week, and I haven't touched it, but now it
isn't happy.
I just needed to check my sanity that the stripnl was ok.

Thanks
J

 

[John Smith]

How do you know that ? There might be a '\r' (CR- if file is taken from
windows) otherwise the function is fine.

Hey, that might be it! I'll remove '\r' also.

Thanks for the help

John

 

[John Smith]

How do you know that ? There might be a '\r' (CR- if file is taken from
windows) otherwise the function is fine.

Yes, that was it. Thanks again.

John

 

[Carlos]

It looks like it should work. How are you calling this function? How are
you checking the results?

Apart from the namespace invasion?

 

[CBFalconer]

Why doesn't this seem to work?

void stripnl(char *sz)
{
char *nl;
nl = strchr(sz, '\n');
if (nl)
{
*nl = '\0';
}
}

The string fed in still has the newline after calling this function.

AFAICS it does work. Why do you think it doesn't?

 

[Mike Wahler]

char szLine[MAX_LINE]; /* this is big enough.. */
char *szToken;

while (fgets(szLine, MAX_LINE, *file) != NULL)
{
szToken = strtok(szLine, " \t:"); /* split by space, tab or colon
characters */
stripnl(szToken);
}

If the line I read in contained say "one_word\n" then the strip newline
doesn't seem to do its thing. Of course if the line contained "two_words
second_word\n", then the token doesn't have a newline to strip out.

I'm sure this stuff worked last week, and I haven't touched it, but now it
isn't happy.
I just needed to check my sanity that the stripnl was ok.

Are you aware that if 'strtok()' finds what it's looking for,
it replaces it with '\0'? So of course after that, the
newline is no longer part of your string. Try doing the
newline strip *before* calling 'strtok()'.

-Mike

 

[Flash Gordon]

Yes, that was it. Thanks again.

In that case, are you sure you are not opening a text file as a binary
file? If you open a text file as a text file (and I'm guessing you are
dealing with a text file) then whatever the OS uses as a line
termination (CR/LF on Windows) will be converted to a '\n' by the
system for you.

 

[John Smith]

In that case, are you sure you are not opening a text file as a binary
file? If you open a text file as a text file (and I'm guessing you are
dealing with a text file) then whatever the OS uses as a line
termination (CR/LF on Windows) will be converted to a '\n' by the
system for you.

That may be it: someone else has written wrappers for basic things like
fopen (to give support for off-system storage, so don't shoot it down just
yet...) which I've had to start using. They may be opening it as binary, I
don't know (but will check, and then reach for the shotgun).

Thanks for the insight.

J

 

[Dan Pop]

That may be it: someone else has written wrappers for basic things like
fopen (to give support for off-system storage, so don't shoot it down just
yet...) which I've had to start using. They may be opening it as binary, I
don't know (but will check, and then reach for the shotgun).

You mean you have used a plain "r" in your fopen call and ended up with
input lines terminated in \r\n ? In this case, your C programming
environment is hopelessly broken.

Long ago, certain MSDOS implementations allowed the user to decide
whether a plain "r" or "w" means text stream or binary stream. To be
sure that you get a text stream you had to use the 't' extension: "rt"
or "wt". For all I know, this might be still the case with the current
Windows implementations.

Dan

 

[Mac]

On Wed, 01 Sep 2004 13:42:01 +0000, Dan Pop wrote:
[snip]

You mean you have used a plain "r" in your fopen call and ended up with
input lines terminated in \r\n ? In this case, your C programming
environment is hopelessly broken.

Well, either that or he somehow created a Windows style text file on a
unix style machine, either by editing it with a windows (or DOS)
application via samba or NFS or something, or by extracting from an
archive of some sort without performing the correct conversion.

If that is the case, then technically it is not a text file on the
platform where he is reading it, I guess. So there might not necessarily
be anything wrong with the C programming environment.

This happens often enough that it is worthwhile to deal with it
intelligently, in my opinion.

--Mac

 

[Dan Pop]

On Wed, 01 Sep 2004 13:42:01 +0000, Dan Pop wrote:
[snip]

You mean you have used a plain "r" in your fopen call and ended up with
input lines terminated in \r\n ? In this case, your C programming
environment is hopelessly broken.

Well, either that or he somehow created a Windows style text file on a
unix style machine, either by editing it with a windows (or DOS)
application via samba or NFS or something, or by extracting from an
archive of some sort without performing the correct conversion.

If that is the case, then technically it is not a text file on the
platform where he is reading it, I guess. So there might not necessarily
be anything wrong with the C programming environment.

This happens often enough that it is worthwhile to deal with it
intelligently, in my opinion.

In my, admitedly, limited experience, Windows implementations return \n
when encountering a \n character in the input file. The missing \r
doesn't make any difference.

Dan

 

[Michael Wojcik]

You mean you have used a plain "r" in your fopen call and ended up with
input lines terminated in \r\n ?

I took his comment to mean that someone wrote the code that calls
fopen ("someone else has written wrappers for basic things like
fopen"), and that someone may have used "rb" ("They may be opening it
as binary"). Indeed, that continues to strike me as the most likely
interpretation of what John wrote.

--
Michael Wojcik (e-mail address removed)

Every allegiance to some community eventually involves such a fetish,
which functions as the disavowal of its founding crime: is not 'America'
the fetish of an infinitely open space enabling every individual to
pursue happiness in his or her own way? -- Slavoj Zizek

 

[Mac]

On Wed, 01 Sep 2004 13:42:01 +0000, Dan Pop wrote:
[snip]

You mean you have used a plain "r" in your fopen call and ended up with
input lines terminated in \r\n ? In this case, your C programming
environment is hopelessly broken.

Well, either that or he somehow created a Windows style text file on a
unix style machine, either by editing it with a windows (or DOS)
application via samba or NFS or something, or by extracting from an
archive of some sort without performing the correct conversion.

If that is the case, then technically it is not a text file on the
platform where he is reading it, I guess. So there might not necessarily
be anything wrong with the C programming environment.

This happens often enough that it is worthwhile to deal with it
intelligently, in my opinion.

In my, admitedly, limited experience, Windows implementations return \n
when encountering a \n character in the input file. The missing \r
doesn't make any difference.

Dan

I don't know anything to the contrary, although I have noticed that some
(maybe all?) versions of notepad don't handle \n only lines very well.
Wordpad does handle these lines just fine, though.

The case I was thinking of was when you read a windows text file in unix
land. If you are parsing the file, you should deal with the \r gracefully,
somehow. I think it should be safe to just ignore it, in this case.

--Mac

 

[Dan Pop]

I took his comment to mean that someone wrote the code that calls
fopen ("someone else has written wrappers for basic things like
fopen"), and that someone may have used "rb" ("They may be opening it
as binary"). Indeed, that continues to strike me as the most likely
interpretation of what John wrote.

Yet, these wrappers must be called, in order to have the file opened.
And I would expect such a wrapper to also take a mode parameter, in order
to be of any real use to the programmer.

Dan