bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Wishlist] add option to cat to force final newline


From: Norbert Kiesel
Subject: Re: [Wishlist] add option to cat to force final newline
Date: Tue, 25 Oct 2005 12:54:22 -0700

On Tue, 2005-10-25 at 12:56 -0600, Bob Proulx wrote:
> Norbert Kiesel wrote:
> > cat of a file without a '\n' as the last character results in the last
> > line not shown in most shells (as it's overwritten with the shell
> > prompt).  I wonder if a patch for an option like --force-newline or so
> > would be accepted, which would print a final newline if the last
> > character is not one.  Or is there already a way to get that behavior?
> 
> Thanks for filing that wishlist with the mailing list.  But let me
> kindly disagree.
> 
> The cat command is not truly a screen lister program.  The cat command
> concatenates files.  We only use it for a screen lister sometimes
> because we know that the file is small and we just want to splat it to
> the screen.  There are really too many options already to a simple
> command like cat.
Yeah, the "too may options" argument I would buy (but hey, it's still
less than 10).  Regarding the "not a true screen listener", AFAICS all
currently existing options are only really useful for a screen lister.

> 
> For a real screen lister program you should use more(1), less(1), or
> even most(1).  That is where all of those features such as adding a
> newline to the end of files and such belong.
> 
> Besides, you can always run an echo after the cat command.
> 
>   cat somefilewithoutnewline ; echo
> 
> Such as:
> 
>   $ cat <(printf "hello\nthere")
>   hello
>   there$
> 
>   $ cat <(printf "hello\nthere") ; echo
>   hello
>   there
>   $
yes, that works. (<hair_splitting_mode>but it will always add a newline,
unlike my idea which would only add one if there is
none</hair_splitting_mode>)

> 
> Another besides, why would you be cat'ing a file to your terminal that
> does not contain a newline?  It is effectively binary data at that
> point.  Instead, put a newline in the file.  :-) Plain text files
> should always end with a newline.  So the problem is really there.
Tell that to e.g. Eclipse, which writes it's ".metadata/version.ini" as
a one-liner without a trailing \n (perhaps so that they can read the
file also under Win32 without forcing windows "binary" mode??)
I fell back to use "od -c" on that, then thought it would be nice if I
could ask cat to do this for me.

Best,
  Norbert


Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]