Terminal Output – Why Does Output from ls Have Newlines but Display on a Single Line?

One of the reasons for that behaviour will be the setting of the terminal for each user.

For example:

• User1 is using TERM=xterm, in this case when you exit vim it will clear the terminal.
• User2 is using TERM=vt100, in this case when you exit vim it will not clear the terminal.

Check what terminal user1 is using with echo $TERM and set the same for user2. for bash:

TERM=xterm; export TERM

UPDATE (2014-02-02)

Thanks to our very own @Anthon's determination in following the lack of this feature up, we have a slightly more formal reason as to why this feature is lacking, which reiterates what I explained earlier:

Re: [PATCH] ls: adding --zero/-z option, including tests

From:      Pádraig Brady
Subject:   Re: [PATCH] ls: adding --zero/-z option, including tests
Date:      Mon, 03 Feb 2014 15:27:31 +0000

Thanks a lot for the patch. If we were to do this then this is the interface we would use. However ls is really a tool for direct consumption by a human, and in that case further processing is less useful. For futher processing, find(1) is more suited. That is well described in the first answer at the link above.

So I'd be 70:30 against adding this.

My original answer

This is a bit of my personal opinion but I believe it to be a design decision in leaving that switch out of ls. If you notice the find command does have this switch:

-print0
      True; print the full file name on the standard output, followed by a 
      null character (instead of the newline character that -print uses).  
      This allows file  names  that  contain  newlines or other types of white 
      space to be correctly interpreted by programs that process the find 
      output.  This option corresponds to the -0 option of xargs.

By leaving that switch out, the designers were implying that you should not be using ls output for anything other than human consumption. For downstream processing by other tools, you should be using find instead.

Ways to use find

If you're just looking for the alternative methods you can find them here, titled: Doing it correctly: A quick summary. From that link these are likely the 3 more common patterns:

1. Simple find -exec; unwieldy if COMMAND is large, and creates 1 process/file:

   find . -exec COMMAND... {} \;
   

2. Simple find -exec with +, faster if multiple files are okay for COMMAND:

   find . -exec COMMAND... {} \+
   

3. Use find and xargs with \0 separators

   (nonstandard common extensions -print0 and -0. Works on GNU, *BSDs, busybox)

   find . -print0 | xargs -0 COMMAND
   

Further evidence?

I found this blog post from Joey Hess' blog titled: "ls: the missing options". One of the interesting comments in this post:

The only obvious lack now is a -z option, which should make output filenames be NULL terminated for consuption by other programs. I think this would be easy to write, but I've been extermely busy IRL (moving lots of furniture) and didn't get to it. Any takers to write it?

Further searching I found this in the commit logs from one of the additional switches that Joey's blog post mentions, "new output format -j", so it would seem that the blog post was poking fun at the notion of ever adding a -z switch to ls.

As to the other options, multiple people agree that -e is nearly almost useful, although none of us can quite find a reason to use it. My bug report neglected to mention that ls -eR is very buggy. -j is clearly a joke.

References

• Why you shouldn't parse the output of ls(1)
• How can I get a file's permissions (or other metadata) without parsing ls -l output?
• Filenames and Pathnames in Shell: How to do it Correctly