warning : no new line at end of file

Hi,
when i compile my C programs (even 2 line progs) give the warning, no
new line at end of file.
What does this mean ?
-Regards,
Sameer

Hi,

Can you please type the program you are trying to compile.

It would be helpful for us if you tell us the compilation environment.
for e.g. OS used and compiler version used.

Rahul

"Sameer" <ensameer@gmail.com> writes:[color=blue]
> when i compile my C programs (even 2 line progs) give the warning, no
> new line at end of file.
> What does this mean ?[/color]

It means there's no newline at the end of the file. What do you think
it means?

In your text editor, add a newline to the end of the file you're
trying to compile. (Some editors do this automatically; yours
apparently doesn't.)

--
Keith Thompson (The_Other_Keith) kst-u@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.

"Sameer" <ensameer@gmail.com> wrote:
[color=blue]
> when i compile my C programs (even 2 line progs) give the warning, no
> new line at end of file.[/color]

It means, surprise, surprise, that there is no new-line at the end of
your source file. Quoth the Standard:

# A source file that is not empty shall end in a new-line character

Richard

this is the source code :

#include <stdio.h>

main()
{
printf("hi\n") ;

}
when i compile it i get
warning: no new line at end of file
I am using madrake linux and compiling it with gcc

thanks a lot. now it is working fine.

> It means, surprise, surprise, that there is no new-line at the end of[color=blue]
> your source file. Quoth the Standard:
>
> # A source file that is not empty shall end in a new-line character[/color]

So the next obvious question is to ask why it is this way?

I personally think it's one of the most dumb restrictions ever made. Does it
change anything about how the program is compiled? No! I mean, who cares
about blank lines. It's the code which is important.

Apple also seems to have disabled this in their version of gcc on Mac OS X.

-- John

[Followups set to comp.lang.c]

John Smith said:
[color=blue][color=green]
>> It means, surprise, surprise, that there is no new-line at the end of
>> your source file. Quoth the Standard:
>>
>> # A source file that is not empty shall end in a new-line character[/color]
>
> So the next obvious question is to ask why it is this way?[/color]

Presumably because a source file is intended to be a text file, and a text
file comprises zero or more lines, and a line comprises zero or more
characters terminated by a newline character.

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

"John Smith" <js@x-formation.com> wrote:
[color=blue][color=green]
> > It means, surprise, surprise, that there is no new-line at the end of
> > your source file. Quoth the Standard:
> >
> > # A source file that is not empty shall end in a new-line character[/color]
>
> So the next obvious question is to ask why it is this way?[/color]

Because there are OSes where a text file is stranger even than the
mindset of a Unix-head.
[color=blue]
> I personally think it's one of the most dumb restrictions ever made. Does it
> change anything about how the program is compiled? No! I mean, who cares
> about blank lines.[/color]

The restriction is not on blank lines; the restriction is that the final
line, like all the others, must be properly terminated.

Not all the world is a toy OS from Berzerkeley, you know.

Richard

could it be that you forgot void main()?!

Afifov said:
[color=blue]
> could it be that you forgot void main()?![/color]

I hope that was intended ironically. In C, main returns int.

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

Thu, Dec 29, 2005 at 10:48:30, js (John Smith) wrote about "warning : no new line at end of file":
[color=blue][color=green]
>> # A source file that is not empty shall end in a new-line character[/color][/color]
JS> So the next obvious question is to ask why it is this way?

Because unterminated text line isn't proper text line.

JS> I personally think it's one of the most dumb restrictions ever made. Does it
JS> change anything about how the program is compiled? No! I mean, who cares
JS> about blank lines. It's the code which is important.
JS> Apple also seems to have disabled this in their version of gcc on Mac OS X.

Stock gcc doesn't require termination of last line, but warns for
its.

-netch-

Sameer wrote:[color=blue]
>
> Hi, when i compile my C programs (even 2 line progs) give the
> warning, no new line at end of file. What does this mean ?[/color]

It means that there was no newline character at the end of the
source file. You must be failing to hit <ret> (or <enter>) after
typing the last source line in your editor.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

you must declare main to be int and return 0. The person with the first
post excluded the return statement, which i was referring to.

Afifov wrote:[color=blue]
>
> you must declare main to be int and return 0. The person with
> the first post excluded the return statement, which i was
> referring to.[/color]

Who is 'you'? The first post in this newsgroup occurred something
like 40 years ago, and I don't think it is available anywhere.
Some people cooperate and include proper context and attributions
in their reply articles. Other rude ones don't bother and just
waste everybodies time and bandwidth.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

"Afifov" <afifov@yahoo.com> wrote:
[color=blue]
> you must[/color]

_Who_ must? Learn to quote context! This is not a web board where
anything goes.

Richard

In article <43b3e375.100691519@news.xs4all.nl>,
Richard Bos <rlb@hoekstra-uitgeverij.nl> wrote:[color=blue]
>"Afifov" <afifov@yahoo.com> wrote:
>[color=green]
>> you must[/color]
>
>_Who_ must? Learn to quote context! This is not a web board where
>anything goes.[/color]

From his point of view, it *is*.

In article <8vqdnbm426CofC7enZ2dnUVZ_tednZ2d@maineline.net> ,
Chuck F. <cbfalconer@maineline.net> wrote:[color=blue]
>Afifov wrote:[color=green]
>>
>> you must declare main to be int and return 0. The person with
>> the first post excluded the return statement, which i was
>> referring to.[/color]
>
>Who is 'you'? The first post in this newsgroup occurred something
>like 40 years ago, and I don't think it is available anywhere.
>Some people cooperate and include proper context and attributions
>in their reply articles. Other rude ones don't bother and just
>waste everybodies time and bandwidth.[/color]

You (and others, such as Keith) are wasting your breath. They'll never get
it. And I'll tell you why.

Imagine that there's a mouse - and the mouse is the Usenet. You and I can
see that it is a mouse and we behave accordingly. But now there is a class
of users (we'll call them "googlers") that are wearing these funny weird
glasses that make them see not a mouse, but an elephant. Seeing an
elephant (i.e., the Usenet as a web page), they also behave accordingly.
And no amount of verbiage from us is going to convince them that it's not
an elephant - that it is only a mouse.

To make this more clear, to a googler, it doesn't make any sense to "quote"
(whatever the heck that is...), in fact, to do so would be absurd, when all
the rest of the articles in the thread are right there in front of their
faces (just as clear as the trunk on that mouse, er, elephant). And no
amount of verbiage from us is going to convince them not to believe what
they see. The point is you can *never* convince someone that what they see
isn't reality. The only way you can address the problem is to help them
fix their eyesight (or help them remove their funny glasses).

In article <dp0cma$gj4$1@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com>,
Richard Heathfield <invalid@invalid.invalid> wrote:[color=blue]
>[Followups set to comp.lang.c]
>
>John Smith said:
>[color=green][color=darkred]
>>> It means, surprise, surprise, that there is no new-line at the end of
>>> your source file. Quoth the Standard:
>>>
>>> # A source file that is not empty shall end in a new-line character[/color]
>>
>> So the next obvious question is to ask why it is this way?[/color]
>
>Presumably because a source file is intended to be a text file, and a text
>file comprises zero or more lines, and a line comprises zero or more
>characters terminated by a newline character.[/color]

Let's see... How does one spell "pedant" ?

P.S. To Mr. Smith, the reason is that it doesn't matter on Unix and other
well-behaved OS's, but it might matter elsewhere. Or, to put it another
way, it should be possible to write the compiler front-end in (100%)
standard C, and standard C requires that text files be well-behaved.

gazelle@yin.interaccess.com (Kenny McCormack) wrote:
[color=blue]
> In article <43b3e375.100691519@news.xs4all.nl>,
> Richard Bos <rlb@hoekstra-uitgeverij.nl> wrote:[color=green]
> >"Afifov" <afifov@yahoo.com> wrote:
> >[color=darkred]
> >> you must[/color]
> >
> >_Who_ must? Learn to quote context! This is not a web board where
> >anything goes.[/color]
>
> From his point of view, it *is*.[/color]

Since when is that any excuse? From my POV, Google is a parasite, but
that doesn't justify me taking bugspray to its owners.

Richard

In article <43b3fe3b.107546884@news.xs4all.nl>,
Richard Bos <rlb@hoekstra-uitgeverij.nl> wrote:
....[color=blue][color=green][color=darkred]
>> >_Who_ must? Learn to quote context! This is not a web board where
>> >anything goes.[/color]
>>
>> From his point of view, it *is*.[/color]
>
>Since when is that any excuse?[/color]

It is not an excuse. I really don't see where you (and others) get the idea
that I am excusing anyone.

It is, rather, an *explanation*, and a suggestion to you, the regulars,
that you find other ways to deal with it. The point is, as I explain every
time I post my little treatise on the subject, you simply *cannot* convince
someone that what they see isn't reality.
[color=blue]
>From my POV, Google is a parasite, but
>that doesn't justify me taking bugspray to its owners.[/color]

I think we'd all be much happier if you did.

On Thu, 29 Dec 2005 14:57:10 GMT, gazelle@yin.interaccess.com (Kenny
McCormack) wrote:
[color=blue]
>In article <dp0cma$gj4$1@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com>,
>Richard Heathfield <invalid@invalid.invalid> wrote:[color=green]
>>[Followups set to comp.lang.c]
>>
>>John Smith said:
>>[color=darkred]
>>>> It means, surprise, surprise, that there is no new-line at the end of
>>>> your source file. Quoth the Standard:
>>>>
>>>> # A source file that is not empty shall end in a new-line character
>>>
>>> So the next obvious question is to ask why it is this way?[/color]
>>
>>Presumably because a source file is intended to be a text file, and a text
>>file comprises zero or more lines, and a line comprises zero or more
>>characters terminated by a newline character.[/color]
>
>Let's see... How does one spell "pedant" ?[/color]

It's spelled "computer program" or "parser." Computers tend to be very
pedantic, and not recognize even trivial deviations from the rules
they live by.[color=blue]
>
>P.S. To Mr. Smith, the reason is that it doesn't matter on Unix and other
>well-behaved OS's, but it might matter elsewhere. Or, to put it another
>way, it should be possible to write the compiler front-end in (100%)
>standard C, and standard C requires that text files be well-behaved.[/color]

It's not the OS, but whether the compiler accepts EOF as equivalent to
newline in that context.

Whether the compiler can reliably do that may depend on the OS, or
more exactly, the file system.

--
Al Balmer
Sun City, AZ

"Sameer" <ensameer@gmail.com> writes:
[color=blue]
> Hi,
> when i compile my C programs (even 2 line progs) give the warning, no
> new line at end of file.
> What does this mean ?[/color]

It means that there isn't a newline at the end of the file.

/Niklas Norrthon

Samer wrote earlier in the thread:
[color=blue][color=green]
>> Hi,
>> when i compile my C programs (even 2 line progs) give the warning, no
>> new line at end of file.
>> What does this mean ?[/color][/color]

"Afifov" <afifov@yahoo.com> writes:
[color=blue]
> could it be that you forgot void main()?![/color]

Please provide context!!!

May I ask why you think a warning about a missing newline would
have anything to do with "void main()" whatever that is?

By the way in C main returns int. Always!

/Niklas Norrthon

Afifov wrote:[color=blue]
> could it be that you forgot void main()?![/color]

What the hell is this about?

If you mean that someone should delare main to have a return type of
void, then you are severely in error.

If you mean he should void such code into the porcelon throne, then you
are probalby right.

Afifov wrote:[color=blue]
> you must declare main to be int and return 0. The person with the first
> post excluded the return statement, which i was referring to.[/color]

main may also return EXIT_FAILURE and EXIT_SUCCESS. For
implemetation-specific non-portable code, other implementation-defined
values are possible. It is not true that main must return 0.

rlb@hoekstra-uitgeverij.nl (Richard Bos) writes:[color=blue]
> gazelle@yin.interaccess.com (Kenny McCormack) wrote:[color=green]
>> In article <43b3e375.100691519@news.xs4all.nl>,
>> Richard Bos <rlb@hoekstra-uitgeverij.nl> wrote:[color=darkred]
>> >"Afifov" <afifov@yahoo.com> wrote:
>> >
>> >> you must
>> >
>> >_Who_ must? Learn to quote context! This is not a web board where
>> >anything goes.[/color]
>>
>> From his point of view, it *is*.[/color]
>
> Since when is that any excuse? From my POV, Google is a parasite, but
> that doesn't justify me taking bugspray to its owners.[/color]

Please don't feed the troll. Thank you.

--
Keith Thompson (The_Other_Keith) kst-u@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.

Martin Ambuhl wrote:[color=blue]
> main may also return EXIT_FAILURE and EXIT_SUCCESS. For
> implemetation-specific non-portable code, other implementation-defined
> values are possible. It is not true that main must return 0.[/color]

I know that EXIT_SUCCESS==0 on all the platforms I've used C on and I
used to write return 0 in main all the time but since the C standard
defines EXIT_SUCCESS and EXIT_FAILURE in <stdlib.h> and they should be
used by 'exit' is it correct (not program correctness, but C standard)
to ever explicitly return 0?
I got used to 0 from Visual C++ 5, I think, and I noticed that the
KDevelop template for the main function in a C program terminates with
'return EXIT_SUCCESS'.

"John Smith" <js@x-formation.com> wrote in message
news:43b3b125$0$1791$edfadb0f@dread11.news.tele.dk ...
[color=blue][color=green]
>> It means, surprise, surprise, that there is no new-line at the end of
>> your source file. Quoth the Standard:[/color][/color]
[color=blue][color=green]
>> # A source file that is not empty shall end in a new-line character[/color][/color]
[color=blue]
> So the next obvious question is to ask why it is this way?[/color]

So that you can concatenate files together without lines merging.
[color=blue]
> I personally think it's one of the most dumb restrictions ever made. Does
> it change anything about how the program is compiled? No! I mean, who
> cares about blank lines. It's the code which is important.[/color]

It does change things about how the program is compiled. Your assumption
is erroneous. Failure to end a file with a newline could result in
concatenating two files, causing the last symbol in one to merge with the
first symbol in the next.

The other reason is simply for logical consistency. A line is defined to
end with a specific line ending character. A source file is defined to
consist of lines.
[color=blue]
> Apple also seems to have disabled this in their version of gcc on Mac OS
> X.[/color]

They are not required to issue a warning.

DS

>Martin Ambuhl wrote:[color=blue][color=green]
>> main may also return EXIT_FAILURE and EXIT_SUCCESS. For
>> implemetation-specific non-portable code, other implementation-defined
>> values are possible. It is not true that main must return 0.[/color][/color]

In article <1135884194.337162.297730@g49g2000cwa.googlegroups .com>
nelu <tandauioan@gmail.com> wrote:[color=blue]
>I know that EXIT_SUCCESS==0 on all the platforms I've used C on ...[/color]

It happens to be defined as 1 on VMS (where 1 is the general-purpose
OS "success" code).
[color=blue]
>... is it correct (not program correctness, but C standard)
>to ever explicitly return 0?[/color]

It is valid to do so. A Standard C system must convert an exit(0),
or the (mostly) equivalent "return 0" from initial call to main, into
(one of) the OS's "success" code(s). On VMS in particular, this
means that exit(0) and exit(1) do the same thing.

(Older, pre-ANSI-C-standard versions of VMS fail to convert 0 to 1,
so that in VMS 3.0, returning 0 from a C program causes the system
to claim the program failed.)

If the OS happens to have two or more different "kinds" of "success",
a C implementation for that OS is allowed to have EXIT_SUCCESS
produce one of them and 0 produce another (different) one.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

nelu wrote:[color=blue]
> Martin Ambuhl wrote:[color=green]
>> main may also return EXIT_FAILURE and EXIT_SUCCESS. For
>> implemetation-specific non-portable code, other implementation-defined
>> values are possible. It is not true that main must return 0.[/color]
>
> I know that EXIT_SUCCESS==0 on all the platforms I've used C on[/color]

It is not required to be, but it is not surprising. See below...
[color=blue]
> and I
> used to write return 0 in main all the time[/color]

This is perfectly valid.
[color=blue]
> but since the C standard
> defines EXIT_SUCCESS and EXIT_FAILURE in <stdlib.h> and they should be
> used by 'exit' is it correct (not program correctness, but C standard)
> to ever explicitly return 0?[/color]

<snip>

The standard defines returning 0 from the initial call to main (or doing
exit(0)) indicates success. It also defines EXIT_SUCCESS and
EXIT_FAILURE which can also be used either returning from the initial
call to main or when calling exit and they have the obvious meanings.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

On Thu, 29 Dec 2005 15:18:59 GMT, rlb@hoekstra-uitgeverij.nl (Richard
Bos) wrote in comp.lang.c:
[color=blue]
> gazelle@yin.interaccess.com (Kenny McCormack) wrote:
>[color=green]
> > In article <43b3e375.100691519@news.xs4all.nl>,
> > Richard Bos <rlb@hoekstra-uitgeverij.nl> wrote:[color=darkred]
> > >"Afifov" <afifov@yahoo.com> wrote:
> > >
> > >> you must
> > >
> > >_Who_ must? Learn to quote context! This is not a web board where
> > >anything goes.[/color]
> >
> > From his point of view, it *is*.[/color]
>
> Since when is that any excuse? From my POV, Google is a parasite, but
> that doesn't justify me taking bugspray to its owners.
>
> Richard[/color]

I've asked you before not to respond to this particular troll, whom I
would not see at all if it were not those, like you, who feed him.

Sorry, but *plonk*.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

Flash Gordon wrote:[color=blue]
> nelu wrote:[color=green]
> > Martin Ambuhl wrote:[color=darkred]
> >> main may also return EXIT_FAILURE and EXIT_SUCCESS. For
> >> implemetation-specific non-portable code, other implementation-defined
> >> values are possible. It is not true that main must return 0.[/color]
> >
> > I know that EXIT_SUCCESS==0 on all the platforms I've used C on[/color]
>
> It is not required to be, but it is not surprising. See below...[/color]

I know it is not required, it was 0 on the systems I worked with. I
didn't know that return 0 should be transformed into success. Thanks!

On Thu, 29 Dec 2005 10:48:30 +0100, in comp.lang.c , "John Smith"
<js@x-formation.com> wrote:
[color=blue][color=green]
>> It means, surprise, surprise, that there is no new-line at the end of
>> your source file. Quoth the Standard:
>>
>> # A source file that is not empty shall end in a new-line character[/color]
>
>So the next obvious question is to ask why it is this way?[/color]

I suspect its to do with how some machines store files, and more
specifically how they know they've reached the end of a line.
[color=blue]
>I personally think it's one of the most dumb restrictions ever made. Does it
>change anything about how the program is compiled? No! I mean, who cares
>about blank lines. It's the code which is important.[/color]

Its not a /blank/ line thats required, its a newline character.
[color=blue]
>Apple also seems to have disabled this in their version of gcc on Mac OS X.[/color]

Try setting warning levels a little higher.
Mark McIntyre
--

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

gazelle@yin.interaccess.com (Kenny McCormack) wrote:
[color=blue]
> In article <43b3fe3b.107546884@news.xs4all.nl>,
> Richard Bos <rlb@hoekstra-uitgeverij.nl> wrote:
> ...[color=green]
> >From my POV, Google is a parasite, but
> >that doesn't justify me taking bugspray to its owners.[/color]
>
> I think we'd all be much happier if you did.[/color]

Be grateful for small mercies: trolls would take precedence.

Richard

i am amazed how some of u have so much time for these long posts. some of
us have to work.

On 2005-12-29, Richard Bos <rlb@hoekstra-uitgeverij.nl> wrote:[color=blue]
> gazelle@yin.interaccess.com (Kenny McCormack) wrote:
>[color=green]
>> In article <43b3e375.100691519@news.xs4all.nl>,
>> Richard Bos <rlb@hoekstra-uitgeverij.nl> wrote:[color=darkred]
>> >"Afifov" <afifov@yahoo.com> wrote:
>> >
>> >> you must
>> >
>> >_Who_ must? Learn to quote context! This is not a web board where
>> >anything goes.[/color]
>>
>> From his point of view, it *is*.[/color]
>
> Since when is that any excuse? From my POV, Google is a parasite, but
> that doesn't justify me taking bugspray to its owners.
>
> Richard[/color]

And besides, quoting is common on web boards. It's generally done with a
blockquote-like bbcode tag, but is still done nonetheless.

On 2005-12-29, John Smith <js@x-formation.com> wrote:[color=blue][color=green]
>> It means, surprise, surprise, that there is no new-line at the end of
>> your source file. Quoth the Standard:
>>
>> # A source file that is not empty shall end in a new-line character[/color]
>
> So the next obvious question is to ask why it is this way?
>
> I personally think it's one of the most dumb restrictions ever made. Does it
> change anything about how the program is compiled? No! I mean, who cares
> about blank lines. It's the code which is important.
>
> Apple also seems to have disabled this in their version of gcc on Mac OS X.[/color]

What is your evidence for this claim?

note that this does not mean that it should end with a blank line.
Traditionally, every line of a text file ends in a newline character. I
suspect the editors you are using on OSX provide it. This doesn't mean
there is a blank line

There is a newline at the end of this post [technically a carriage
return and a linefeed, since that's how text-based network protocols
tend to do things.]

Jordan Abel <random832@gmail.com> writes:[color=blue]
> On 2005-12-29, John Smith <js@x-formation.com> wrote:[color=green][color=darkred]
>>> It means, surprise, surprise, that there is no new-line at the end of
>>> your source file. Quoth the Standard:
>>>
>>> # A source file that is not empty shall end in a new-line character[/color]
>>
>> So the next obvious question is to ask why it is this way?
>>
>> I personally think it's one of the most dumb restrictions ever
>> made. Does it change anything about how the program is compiled?
>> No! I mean, who cares about blank lines. It's the code which is
>> important.
>>
>> Apple also seems to have disabled this in their version of gcc on Mac OS X.[/color]
>
> What is your evidence for this claim?
>
> note that this does not mean that it should end with a blank line.
> Traditionally, every line of a text file ends in a newline character. I
> suspect the editors you are using on OSX provide it. This doesn't mean
> there is a blank line
>
> There is a newline at the end of this post [technically a carriage
> return and a linefeed, since that's how text-based network protocols
> tend to do things.][/color]

Whether a text file includes a proper newline on its last line can
depend on which text editor you used to create it.

Discussion of questionable topicality follows (it's topical in
comp.unix.programmer, but at best marginally so in comp.lang.c).

On Unix-like systems, most or all versions of vi (vi, nvi, vim, etc.)
add a newline automatically. If you edit a file that lacks a trailing
newline, it will add one when you update the file. As far as I know,
it's nearly impossible to create a mal-formed text file with vi.

The behavior of emacs, on the other hand, can be configured by setting
the "require-final-newline" variable. By default, emacs will silently
create a file with no trailing newline. It can also be configured
either to silently add a newline, or to ask what to do. I have the
line
(setq require-final-newline 'ask)
in my $HOME/.emacs file.

Other systems and other editors will have different ways of handling
this.

--
Keith Thompson (The_Other_Keith) kst-u@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.

On Fri, 30 Dec 2005 10:21:35 -0500, in comp.lang.c , "Afifov"
<afifov@yahoo.com> wrote:
[color=blue]
>i am amazed how some of u have so much time for these long posts. some of
>us have to work.[/color]

Perhaps some of yuo ought to consider a job that allows you to take
paid holidays, and doesn't require you to work evenings and weekends.
:-)

Mark McIntyre
--

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

Keith Thompson wrote:[color=blue]
> On Unix-like systems, most or all versions of vi (vi, nvi, vim, etc.)
> add a newline automatically. If you edit a file that lacks a trailing
> newline, it will add one when you update the file. As far as I know,
> it's nearly impossible to create a mal-formed text file with vi.
>
> The behavior of emacs, on the other hand, can be configured by setting
> the "require-final-newline" variable. By default, emacs will silently
> create a file with no trailing newline. It can also be configured
> either to silently add a newline, or to ask what to do. I have the
> line
> (setq require-final-newline 'ask)
> in my $HOME/.emacs file.
>
> Other systems and other editors will have different ways of handling
> this.[/color]

Excuse me for being off-topic, just for a second, but, just out of
curiosity, what editor is the most used on clc?

> What is your evidence for this claim?[color=blue]
>
> note that this does not mean that it should end with a blank line.
> Traditionally, every line of a text file ends in a newline character. I
> suspect the editors you are using on OSX provide it. This doesn't mean
> there is a blank line
>[/color]

Evidence? How about my eyes and fingers to type with? I've been using OS X
10.3 for the last year and also 10.4 for some months. I initially ported
some software for OS X and didn't even know about the new line issue until I
went on porting it to linux. So this behaviour is the same for both gcc 3.x
and 4.x provided on OS X.

I havn't actually used the editors on OS X. Most of my code has been just
cross developed. I work on one machine and compile on another.

-- John

On 2005-12-31, John Smith <js@x-formation.com> wrote:[color=blue][color=green]
>> What is your evidence for this claim?
>>
>> note that this does not mean that it should end with a blank line.
>> Traditionally, every line of a text file ends in a newline character. I
>> suspect the editors you are using on OSX provide it. This doesn't mean
>> there is a blank line
>>[/color]
>
> Evidence? How about my eyes and fingers to type with? I've been using OS X
> 10.3 for the last year and also 10.4 for some months. I initially ported
> some software for OS X and didn't even know about the new line issue until I
> went on porting it to linux. So this behaviour is the same for both gcc 3.x
> and 4.x provided on OS X.
>
> I havn't actually used the editors on OS X. Most of my code has been just
> cross developed. I work on one machine and compile on another.[/color]

evidence would be, for example, a hexdump of a file that you think does
not end in a newline, that OSX gcc accepts.

How do you explain the exit codes of "grep"?

"tmp123" <tmp123@menta.net> writes:[color=blue]
> How do you explain the exit codes of "grep"?[/color]

Surely you've seen <http://cfaj.freeshell.org/google/>. That URL has
been posted to this newsgroup 127 times in the last month (according
to Google). If you don't provide some context, don't expect anyone to
know what you're talking about -- and don't expect anyone to go to the
extra effort to find out.

"grep" is a system-specific program. It exists on Unix-like systems,
and there are undoubtedly implementations of it on other systems. It
is therefore off-topic. If you want to understand its exit codes, you
should read the documentation that should be available on any system
that has the command.

If you're wondering why the exit codes aren't limited to 0,
EXIT_SUCCESS, and EXIT_FAILURE, there's no particular reason why they
should be. If exit() is called with any other value, the status
returned is implementation-defined. Since the "grep" command is
implementation-specific, that's perfectly appropriate. It's not even
required that "grep" is implemented in C or uses exit(). (If "grep"
were ported to VMS, presumably the exit codes would have to be
changed.)

--
Keith Thompson (The_Other_Keith) kst-u@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.

>"grep" is a system-specific program. It exists on Unix-like systems,[color=blue]
>and there are undoubtedly implementations of it on other systems. It
>is therefore off-topic. If you want to understand its exit codes, you
>should read the documentation that should be available on any system
>that has the command.
>
>If you're wondering why the exit codes aren't limited to 0,
>EXIT_SUCCESS, and EXIT_FAILURE, there's no particular reason why they
>should be. If exit() is called with any other value, the status
>returned is implementation-defined. Since the "grep" command is
>implementation-specific, that's perfectly appropriate. It's not even
>required that "grep" is implemented in C or uses exit(). (If "grep"
>were ported to VMS, presumably the exit codes would have to be
>changed.)[/color]

There are a lot of programs whose job is to test something, where
the result is necessarily three-way (or more than three):

test result is true
test result is false
unable to conduct test (possibly subdivided into: bad test syntax,
file open failed, division by zero, unable to log into database, etc.)

How you map that into EXIT_SUCCESS, EXIT_FAILURE, and other
allowed exit codes that aren't either is up to you.

Exit codes that *SHOULD* have been standardized, but aren't:

EXIT_SUCCESS_WITH_PROMOTION_AND_RAISE
EXIT_SUCCESS_YOU_GET_TO_KEEP_YOUR_JOB
EXIT_FAILURE_YOU_ARE_FIRED
EXIT_FAILURE_AND_YOU_WILL_BE_EXECUTED_BY_FIRING_SQ UAD

Gordon L. Burditt

On 30 Dec 2005 19:38:18 -0800, in comp.lang.c , "nelu"
<tandauioan@gmail.com> wrote:
[color=blue]
>Excuse me for being off-topic, just for a second, but, just out of
>curiosity, what editor is the most used on clc?[/color]

If you have a new question, start a new thread, and don't x-post to an
unrelated group.
Mark McIntyre
--

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

On 31 Dec 2005 11:00:20 -0800, in comp.lang.c , "tmp123"
<tmp123@menta.net> wrote:
[color=blue]
>How do you explain the exit codes of "grep"?[/color]

In iambic pentameter.

(since you provided absolutely no context, I chose to interpret your
question as "using what delivery style...")

--
Please quote enough of the previous message for context. To do so from
Google, click "show options" and use the Reply shown in the expanded
header.

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

Mark McIntyre said:
[color=blue]
> On 31 Dec 2005 11:00:20 -0800, in comp.lang.c , "tmp123"
> <tmp123@menta.net> wrote:
>[color=green]
>>How do you explain the exit codes of "grep"?[/color]
>
> In iambic pentameter.[/color]

Your wish is my command.

Now grep has quite a wonderful design,
And purposes untold and without number;
When searching for that quintessential line,
You know your trusty grep will never slumber,
Seeking, seeking, all throughout its sessions,
With full support for regular expressions.

But if you execute it from a shell script,
Wanting total searching automation,
You really need a way that you can decrypt
Those exit codes, a most complete translation.
Here's a guide to help you understand them,
So that you need not yet all hope abandon:

When grep yields zero, questing is completed,
And nothing sought remains to be disclosed;
But if our hero hands you one, defeated,
No answer is there to the search you posed;
And when your shell script with a two is treated,
Your files are wrong, or your argv is hosed.

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

[Followups set to comp.lang.c]

nelu said:
[color=blue]
> Excuse me for being off-topic, just for a second, but, just out of
> curiosity, what editor is the most used on clc?[/color]

In comp.lang.c, that's a bit like asking "what colour socks do C hackers
prefer?" Yes, there is an answer, but no, you'll probably never find out
what it is, because comp.lang.c subscribers don't actually care what the
answer is.

The comp.unix.programmer and comp.lang.c newsgroups have good historical
reasons for being fluffy-bunny snuggly companions, but in practice C has
spread far and wide since those halcyon days of the 1973 kernel, and the
comp.lang.c group no longer thinks of C as being merely another word for
Unix. I've hacked out C code in ISPF/PDF, Notepad, vim, elvis, pico, and
a variety of Windows IDEs. I've written C using COPY CON and cat. I have
written C code using custom-written code generators - which can scarcely
count as editors at all. Here in comp.lang.c, the question is simply not
worth asking, I'm afraid.

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

warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

re: warning : no new line at end of file

Similar C / C++ bytes

/bytes/development

/bytes/it

/bytes/about