Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > warning : no new line at end of file

Reply
Thread Tools

warning : no new line at end of file

 
 
nelu
Guest
Posts: n/a
 
      12-31-2005

Keith Thompson wrote:
> 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?

 
Reply With Quote
 
 
 
 
John Smith
Guest
Posts: n/a
 
      12-31-2005
> 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


 
Reply With Quote
 
 
 
 
Jordan Abel
Guest
Posts: n/a
 
      12-31-2005
On 2005-12-31, John Smith <(E-Mail Removed)> wrote:
>> 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.


evidence would be, for example, a hexdump of a file that you think does
not end in a newline, that OSX gcc accepts.
 
Reply With Quote
 
tmp123
Guest
Posts: n/a
 
      12-31-2005
How do you explain the exit codes of "grep"?

 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      12-31-2005
"tmp123" <(E-Mail Removed)> writes:
> 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.)

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <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.
 
Reply With Quote
 
Gordon Burditt
Guest
Posts: n/a
 
      12-31-2005
>"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_SQ UAD

Gordon L. Burditt
 
Reply With Quote
 
Mark McIntyre
Guest
Posts: n/a
 
      12-31-2005
On 30 Dec 2005 19:38:18 -0800, in comp.lang.c , "nelu"
<(E-Mail Removed)> wrote:

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

----== 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 =----
 
Reply With Quote
 
Mark McIntyre
Guest
Posts: n/a
 
      12-31-2005
On 31 Dec 2005 11:00:20 -0800, in comp.lang.c , "tmp123"
<(E-Mail Removed)> wrote:

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

--
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 =----
 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      01-01-2006
Mark McIntyre said:

> On 31 Dec 2005 11:00:20 -0800, in comp.lang.c , "tmp123"
> <(E-Mail Removed)> wrote:
>
>>How do you explain the exit codes of "grep"?

>
> 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
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      01-01-2006
[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.

--
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)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Read a file line by line and write each line to a file based on the5th byte scad C++ 23 05-17-2009 06:11 PM
Re: illegal line end in character literal in escaped unicode CARRIAGERETURN / NEW LINE Joshua Cranmer Java 0 05-15-2009 02:50 PM
Re: illegal line end in character literal in escaped unicode CARRIAGERETURN / NEW LINE Lew Java 0 05-15-2009 02:38 PM
Re: illegal line end in character literal in escaped unicode CARRIAGERETURN / NEW LINE Mark Space Java 0 05-15-2009 02:35 PM
Re: illegal line end in character literal in escaped unicode CARRIAGE RETURN / NEW LINE Andreas Leitgeb Java 0 05-15-2009 02:02 PM



Advertisments