Conflict between my prompt definition and cat in zsh

Question

I have a file on a remote filesystem that I know has a short text string in it (a sequence of numbers in a single line). If I open the file on a text editor like nano or Emacs I can see the string. Also, not sure if this is relevant, but ls reports the file has 8 bytes*.

The odd thing is that if I cat this file, cat reports nothing.

However, I noticed that if I add a linebreak at the end of the line, cat then shows the contents, which is confusing me.

So my questions are:

• Why does this happen? Do I really need a linebreak at the end of each line to have cat print its contents? Is this the default behavior for cat? (if so, what is the reasoning behind it?)
• Is there a way to force cat to print everything in a file, regardless of whether or not I have linebreaks?

Update:

Based on the answers below, I thought it would be relevant to post how I defined my prompt. I'm on zsh, and I have the following two lines on my ~/.zshrc:

export PS1="%{$fg[white]%}%n%{$reset_color%} @ %{$fg[green]%}%m: %{$fg[yellow]%}%~ %{$reset_color%}%%
> "

Before the definition of my prompt, I have the following two lines which I believe enable me to use color aliases in the shell:

autoload -U colors
colors

Rephrasing the question:

With the above in mind, how can I get a linebreak in my prompt, and still manage to get cat to print a file like the above correctly?

---

*If I touch a random file, ls reports the file has only 0 bytes, so I presume that the fact that ls reports that my file has 8 bytes is meaningful. Not sure if this is helpful though.

Answer 1

Zsh outputs a CR automatically before the prompt so the prompt can start at a known location. Note that if you used a shell other than zsh, you would get:

$ cat file
12345678$ _ <-- your prompt after the file contents

Here is a FAQ entry about the issue: http://zsh.sourceforge.net/FAQ/zshfaq03.html#l40

Text files are supposed to end with a newline for this and other reasons - it's unusual to find a tool for creating them that won't include one (except in a cross-platform environment - windows notepad won't end files in a newline for example)

If you can tolerate an extra blank line after most commands' output (as on windows) before the prompt, try adding a newline to the beginning of your prompt:

export PS1="
%{$fg[white]%}%n%{$reset_color%} @ %{$fg[green]%}%m: %{$fg[yellow]%}%~ %{$reset_color%}%%
> "

And (maybe, it might actually work even with it on) disable the prompt_cr shell option. You could also try the "line of spaces" option from the linked email.

Answer 2

My guess is that your shell prompt is overriding the line cat wrote. Try the following to check whether it is the case:

cat file; echo

Depending on your shell, you can tweak your configuration files in some way to make sure this will never happen.

Answer 3

If you printf %q "$PS1", does it show any \r (carriage return) characters? That would explain it: cat outputs some string without a newline, then as $PS1 is processed, it returns to the start of the line and proceeds to overwrite the value. To check indirectly whether this is the case, you can try to write a value in the file which is longer than your prompt (or just copy the prompt to the start of the file), and see if the cat output flows past the prompt.

Answer 4

If you do an echo $PS1 from your shell you can check to see if there is a \r anywhere in the line. If so that is the culprit.

To fix the issue you can add a \n to the beginning of your prompt.

If you just need to cat it to another command you can do so without fear of it being hijacked. To view it at the command line you can also do cat file | less

Answer 5

I define my PS1 like this:

PS1='\n\u@\h \w\n(\\$\\$='$$') \! \$ '

So my prompt looks like this

...output of last command

glennj@machine ~
($$=29608) 1403 $

with a blank line preceding. So if there is output without a trailing newline, it's still visible:

glennj@auds916 ~
($$=29608) 1403 $ printf hello
hello
glennj@auds916 ~
($$=29608) 1404 $