warning : no new line at end of file

[nelu]

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.

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

 

[John Smith]

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

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

 

[Jordan Abel]

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.

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

 

[tmp123]

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

 

[Keith Thompson]

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

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

 

[Gordon Burditt]

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

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_SQUAD

Gordon L. Burditt

 

[Mark McIntyre]

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

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

 

[Mark McIntyre]

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

In iambic pentameter.

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

 

[Richard Heathfield]

Mark McIntyre said:

In iambic pentameter.

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]

[Followups set to comp.lang.c]

nelu said:

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

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.

 

[Keith Thompson]

Mark McIntyre said:


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.

Alas, your talk of grep, though it's quite pretty,
Is not on topic here in comp lang c.
And though to criticize you is a pity,
We must maintain our rules of pedantry.
Bandwidth is cheap, and yet we must be frugal.
(It could be worse; at least you don't use Google.)

 

[nelu]

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.

Yes, I guess I was way off .

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.

I was just curios what C programmers prefer to use. Would it be safe,
for example, to guess that you prefer notepad to copy con on a regular
basis?

But you're right, going down this path usually leads to things that
have nothing in common with C, so I hope people will disregard that
post.

 

[Mark McIntyre]

On Sun, 1 Jan 2006 05:44:34 +0000 (UTC), in comp.lang.c , Richard

(snip most excellent verse rendition of the return codes of grep).

Your sig seems curiously appropriate....

"Usenet is a strange place" - dmr 29/7/1999

Mark McIntyre

 

[Richard Heathfield]

nelu said:

Yes, I guess I was way off .

Having established that.....

I was just curios what C programmers prefer to use. Would it be safe,
for example, to guess that you prefer notepad to copy con on a regular
basis?

Weeeeelllll, if you must know, I prefer vim.

 

[toby]

So that you can concatenate files together without lines merging.


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.

Hmm, no, gcc does not mash input files together in this manner. It's
hard to imagine a valid C file that does not end with ; or }. On the
other hand, it is conceivable that a preprocessor directive not ending
in a newline, when manually concatenated with another file to form
input to the compiler, might cause an unexpected problem...

In ages past, I believe such lexical warnings helped flag media
problems such as a missing card, bad parity, truncated file, and such.
I am not certain that remains the rationale for this warning, however
-- since C is strict about nesting braces and statement termination (as
noted above), file corruption is likely to abort compilation anyway.

 

[David Schwartz]

David Schwartz wrote:

Hmm, no, gcc does not mash input files together in this manner.

Who was talking about gcc?

It's
hard to imagine a valid C file that does not end with ; or }.

On the contrary, most header files end with a preprocessor directive.

On the
other hand, it is conceivable that a preprocessor directive not ending
in a newline, when manually concatenated with another file to form
input to the compiler, might cause an unexpected problem...

Exactly.

In ages past, I believe such lexical warnings helped flag media
problems such as a missing card, bad parity, truncated file, and such.
I am not certain that remains the rationale for this warning, however
-- since C is strict about nesting braces and statement termination (as
noted above), file corruption is likely to abort compilation anyway.

I think it's just for logical consistency. A text file consists of
lines. A line is defined as ending with a line terminator.

DS