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]

John Smith <so*****@microsoft.com> scribbled the following:

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?

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"It was, er, quite bookish."
- Horace Boothroyd

[Ravi Uday]

"John Smith" <so*****@microsoft.com> wrote in message
news:ch**********@newstree.wise.edt.ericsson.se...

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.

Thanks
John

[John Smith]

"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:ch**********@oravannahka.helsinki.fi...

John Smith <so*****@microsoft.com> scribbled the following:

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?

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- 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]

"Ravi Uday" <ra******@gmail.com> wrote in message
news:1093953853.274269@sj-nntpcache-5...

"John Smith" <so*****@microsoft.com> wrote in message
news:ch**********@newstree.wise.edt.ericsson.se...

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.

Thanks
John

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

Thanks for the help

John

[John Smith]

"Ravi Uday" <ra******@gmail.com> wrote in message
news:1093953853.274269@sj-nntpcache-5...

"John Smith" <so*****@microsoft.com> wrote in message
news:ch**********@newstree.wise.edt.ericsson.se...

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.

Thanks
John

Yes, that was it. Thanks again.

John

[Carlos]

Joona I Palaste wrote:

John Smith <so*****@microsoft.com> scribbled the following:

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?

Apart from the namespace invasion?

[CBFalconer]

John Smith wrote:

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?

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Mike Wahler]

"John Smith" <so*****@microsoft.com> wrote in message
news:ch**********@newstree.wise.edt.ericsson.se...

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]

On Tue, 31 Aug 2004 13:18:40 +0100
"John Smith" <so*****@microsoft.com> wrote:

"Ravi Uday" <ra******@gmail.com> wrote in message
news:1093953853.274269@sj-nntpcache-5...

"John Smith" <so*****@microsoft.com> wrote in message
news:ch**********@newstree.wise.edt.ericsson.se...

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.

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.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

[John Smith]

"Flash Gordon" <sp**@flash-gordon.me.uk> wrote in message
news:fc************@brenda.flash-gordon.me.uk...

On Tue, 31 Aug 2004 13:18:40 +0100
"John Smith" <so*****@microsoft.com> wrote:

"Ravi Uday" <ra******@gmail.com> wrote in message
news:1093953853.274269@sj-nntpcache-5...

"John Smith" <so*****@microsoft.com> wrote in message
news:ch**********@newstree.wise.edt.ericsson.se...
> 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.

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.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

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]

In <ch**********@newstree.wise.edt.ericsson.se> "John Smith" <so*****@microsoft.com> writes:

"Flash Gordon" <sp**@flash-gordon.me.uk> wrote in message
news:fc************@brenda.flash-gordon.me.uk...

On Tue, 31 Aug 2004 13:18:40 +0100
"John Smith" <so*****@microsoft.com> wrote:

>
> "Ravi Uday" <ra******@gmail.com> wrote in message
> news:1093953853.274269@sj-nntpcache-5...
> >
> > "John Smith" <so*****@microsoft.com> wrote in message
> > news:ch**********@newstree.wise.edt.ericsson.se...
> > > 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.
>
> 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.

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[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]

In <pa***************************@bar.net> Mac <fo*@bar.net> writes:

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Michael Wojcik]

In article <ch***********@sunnews.cern.ch>, Da*****@cern.ch (Dan Pop) writes:

In <ch**********@newstree.wise.edt.ericsson.se> "John Smith" <so*****@microsoft.com> writes:

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 ?

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 mi************@microfocus.com

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 Fri, 03 Sep 2004 14:40:27 +0000, Dan Pop wrote:

In <pa***************************@bar.net> Mac <fo*@bar.net> writes:

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]

In <ch********@news3.newsguy.com> mw*****@newsguy.com (Michael Wojcik) writes:

In article <ch***********@sunnews.cern.ch>, Da*****@cern.ch (Dan Pop) writes:

In <ch**********@newstree.wise.edt.ericsson.se> "John Smith" <so*****@microsoft.com> writes:

>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 ?

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de