Mac OS X Prompt Bug

Mac OS X Prompt Bug

[Sorin Ionescu]

[-- Attachment #1: Type: text/plain, Size: 1295 bytes --]

Hello,

Please have a look at the screenshot at http://i.imgur.com/huNpI.jpg. Otherwise, the following text may not make sense.

A % character appears before every prompt then it is replaced by the prompt; so, it only flashes for a fraction of a second. However, if the buffer is empty when ZSH starts, such as when one has a ~/.hushlogin file, it results in the behaviour in the screenshot, which is % character followed by blank lines. 

Before you ask, the screenshot was taken via a new user account. There is no zshrc, zshenv, nor any combination thereof in the home directory. The ZSH versions tested are 4.3.9 and 4.3.10.

There is a global /etc/zshenv file that has the following contents:
# system-wide environment settings for zsh(1)
if [ -x /usr/libexec/path_helper ]; then
	eval `/usr/libexec/path_helper -s`
fi

The output of /usr/libexec/path_helper is the following:
PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/Users/sorin/.local/bin:/Users/sorin/.local/sbin"; export PATH;
MANPATH="/usr/share/man:/usr/local/share/man:/usr/X11/share/man:/Users/sorin/.local/share/man"; export MANPATH;

Thus, /etc/zshenv is not the problem. It could be a fault of Terminal.app, but it only happens with ZSH and no other shell.

Thank you,

Sorin Ionescu

Re: Mac OS X Prompt Bug

[Peter Stephenson]

On Wed, 24 Nov 2010 08:58:26 -0500
Sorin Ionescu <sorin.ionescu@gmail.com> wrote:
> A % character appears before every prompt then it is replaced by the
> prompt; so, it only flashes for a fraction of a second. However, if
> the buffer is empty when ZSH starts, such as when one has a
> ~/.hushlogin file, it results in the behaviour in the screenshot,
> which is % character followed by blank lines. 

That's almost certainly a side-effect of the PROMPT_SP option, see the
manual entry. This gets printed at the start of the line, then covered
over by the prompt itself.

Somehow in the case you're showing some output is coming out between zsh
printing the mark and printing the prompt itself.  I have no idea where
that would be, but the pre-prompt activities are carried out quite
early, before the line editor is set up, so there is a reasonable amount
of scope for it.

If you don't have time to track down where the extra output is coming
from, turning off the PROMPT_SP option should make the mark go away.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: Mac OS X Prompt Bug

[Vincent Lefevre]

Hi,

On 2010-11-24 08:58:26 -0500, Sorin Ionescu wrote:
> Please have a look at the screenshot at
> http://i.imgur.com/huNpI.jpg. Otherwise, the following text may not
> make sense.
> 
> A % character appears before every prompt then it is replaced by the
> prompt;

This is a very useful feature (which can be disabled), to know when
some output hasn't been followed by a newline character, e.g. try

  echo -n foo

Other shells do not do this, hence the difference.

> so, it only flashes for a fraction of a second. However, if
> the buffer is empty when ZSH starts, such as when one has a
> ~/.hushlogin file, it results in the behaviour in the screenshot,
> which is % character followed by blank lines.

I don't have such a problem under Mac OS X (using iTerm, but I hadn't
noticed it with Terminal either in the past). This may come from the
terminal (a bug?) or its configuration.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: Mac OS X Prompt Bug

[Vincent Lefevre]

On 2010-11-24 15:24:08 +0000, Peter Stephenson wrote:
> Somehow in the case you're showing some output is coming out between zsh
> printing the mark and printing the prompt itself.  I have no idea where
> that would be, but the pre-prompt activities are carried out quite
> early, before the line editor is set up, so there is a reasonable amount
> of scope for it.

Couldn't the mark be printed exactly at the same time of the prompt?

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: Mac OS X Prompt Bug

[Peter Stephenson]

On Wed, 24 Nov 2010 17:08:32 +0100
Vincent Lefevre <vincent@vinc17.net> wrote:
> On 2010-11-24 15:24:08 +0000, Peter Stephenson wrote:
> > Somehow in the case you're showing some output is coming out
> > between zsh printing the mark and printing the prompt itself.  I
> > have no idea where that would be, but the pre-prompt activities are
> > carried out quite early, before the line editor is set up, so there
> > is a reasonable amount of scope for it.
> 
> Couldn't the mark be printed exactly at the same time of the prompt?

I don't think that's appropriate because it can be redrawn within zle.
I think it needs to be done before the line editor starts, at least, if
I've understood what's going on. Anybody is welcome to play around (I
will not be doing so).

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK




Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: Mac OS X Prompt Bug

[Sorin Ionescu]

Yes, iTerm2 does not have this problem. While unsetopt PROMPT_SP removes the %, the blank lines are still echoed. The easiest way to test this is to touch ~/.hushlogin and open Terminal.app. Notice the scrollbar.

So, PROMPT_SP is definitely not the problem. It seems the prompt is being pushed down by the blank lines. Hence why % is not being overwritten by the prompt in the screenshot.

On 24 Nov 2010, at 10:30, Vincent Lefevre wrote:

> Hi,
> 
> On 2010-11-24 08:58:26 -0500, Sorin Ionescu wrote:
>> Please have a look at the screenshot at
>> http://i.imgur.com/huNpI.jpg. Otherwise, the following text may not
>> make sense.
>> 
>> A % character appears before every prompt then it is replaced by the
>> prompt;
> 
> This is a very useful feature (which can be disabled), to know when
> some output hasn't been followed by a newline character, e.g. try
> 
>  echo -n foo
> 
> Other shells do not do this, hence the difference.
> 
>> so, it only flashes for a fraction of a second. However, if
>> the buffer is empty when ZSH starts, such as when one has a
>> ~/.hushlogin file, it results in the behaviour in the screenshot,
>> which is % character followed by blank lines.
> 
> I don't have such a problem under Mac OS X (using iTerm, but I hadn't
> noticed it with Terminal either in the past). This may come from the
> terminal (a bug?) or its configuration.
> 
> -- 
> Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: Mac OS X Prompt Bug

[Benjamin R. Haskell]

On Wed, 24 Nov 2010, Sorin Ionescu wrote:

> Yes, iTerm2 does not have this problem. While unsetopt PROMPT_SP 
> removes the %, the blank lines are still echoed. The easiest way to 
> test this is to touch ~/.hushlogin and open Terminal.app. Notice the 
> scrollbar.
>
> So, PROMPT_SP is definitely not the problem. It seems the prompt is 
> being pushed down by the blank lines. Hence why % is not being 
> overwritten by the prompt in the screenshot.

So, figure out what's printing out the blank lines.

You mentioned /etc/zshenv.  What about /etc/zshprofile or /etc/zshrc? 
Or maybe even /etc/profile, which is often sourced by system Zsh startup 
files, depending on how Zsh is distributed.

Maybe see if something is set up with hook functions:

$ functions preexec precmd chpwd periodic TRAPDEBUG

As a last resort, try to run Zsh with tracing enabled:

zsh -x  (then Ctrl-d or quit)
[produces lots of output, but maybe near the end you'll see something 
printing out some blank lines]

Might need: zsh -l -x
(not sure how you start your commands in OS X terminal)

-- 
Best,
Ben

Re: Mac OS X Prompt Bug

[Wayne Davison]

[-- Attachment #1: Type: text/plain, Size: 1880 bytes --]

On Wed, Nov 24, 2010 at 8:08 AM, Vincent Lefevre <vincent@vinc17.net> wrote:

> Couldn't the mark be printed exactly at the same time of the prompt?
>

That wouldn't be desirable, because it can allow other output to muck things
up.  The PROMPT_SP needs to happen as soon after the command exits as
possible to ensure that its output-idiom has the largest chance of just
affecting incomplete output from the program (e.g. we actually want to cover
up type-ahead that shows up just prior to the prompt).

One thing that could be done to improve the PROMPT_SP heuristic is to output
a extra space (assuming the width (w) is 1) and another CR after the
trailing CR that is currently output.  That would ensure that newlines
wouldn't show a superfluous percent when no dangling output was present.
 So, how about this?

--- a/Src/utils.c
+++ b/Src/utils.c
@@ -1292,9 +1292,7 @@ preprompt(void)
        countprompt(str, &w, 0, -1);
        opts[PROMPTPERCENT] = percents;
        zputs(str, shout);
-       for (w = (int)columns - w - !hasxn; w > 0; w--)
-           putc(' ', shout);
-       putc('\r', shout);
+       fprintf(shout, "%*s\r%*s\r", (int)columns - w - !hasxn, "", w, "");
        free(str);
     }


I'm not sure if that works well for the case where hasxn isn't set, though.
 We may want to create a separate fprintf() for that case which leaves the
no-hasxn case alone:

--- a/Src/utils.c
+++ b/Src/utils.c
@@ -1292,9 +1292,10 @@ preprompt(void)
        countprompt(str, &w, 0, -1);
        opts[PROMPTPERCENT] = percents;
        zputs(str, shout);
-       for (w = (int)columns - w - !hasxn; w > 0; w--)
-           putc(' ', shout);
-       putc('\r', shout);
+       if (hasxn)
+           fprintf(shout, "%*s\r%*s\r", (int)columns - w, "", w, "");
+       else
+           fprintf(shout, "%*s\r", (int)columns - w - 1, "");
        free(str);
     }


..wayne..

Re: Mac OS X Prompt Bug

[Sorin Ionescu]

There is no /etc/zshprofile, /etc/zshrc or any other combination. /etc/profile is not sourced.

I have found nothing in the output of zsh -l -x. Like I said, it’s not a configuration issue. It’s something in ZSH or Terminal.app or both. Nothing hooks on those functions. It’s possible that ZSH outputs some sequences Terminal.app does not like and generates those lines. Perhaps, they are invisible characters.

Output of zsh -l -x.

krustyroo% zsh -l -x
+/etc/zshenv:2> [ -x /usr/libexec/path_helper ']'
+/etc/zshenv:3> /usr/libexec/path_helper -s
+/etc/zshenv:3> eval 'PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/Users/sorin/.local/bin:/Users/sorin/.local/sbin";' export 'PATH;'
+(eval):1> PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/Users/sorin/.local/bin:/Users/sorin/.local/sbin 
+(eval):1> export PATH


On 24 Nov 2010, at 12:49, Benjamin R. Haskell wrote:

> On Wed, 24 Nov 2010, Sorin Ionescu wrote:
> 
>> Yes, iTerm2 does not have this problem. While unsetopt PROMPT_SP removes the %, the blank lines are still echoed. The easiest way to test this is to touch ~/.hushlogin and open Terminal.app. Notice the scrollbar.
>> 
>> So, PROMPT_SP is definitely not the problem. It seems the prompt is being pushed down by the blank lines. Hence why % is not being overwritten by the prompt in the screenshot.
> 
> So, figure out what's printing out the blank lines.
> 
> You mentioned /etc/zshenv.  What about /etc/zshprofile or /etc/zshrc? Or maybe even /etc/profile, which is often sourced by system Zsh startup files, depending on how Zsh is distributed.
> 
> Maybe see if something is set up with hook functions:
> 
> $ functions preexec precmd chpwd periodic TRAPDEBUG
> 
> As a last resort, try to run Zsh with tracing enabled:
> 
> zsh -x  (then Ctrl-d or quit)
> [produces lots of output, but maybe near the end you'll see something printing out some blank lines]
> 
> Might need: zsh -l -x
> (not sure how you start your commands in OS X terminal)
> 
> -- 
> Best,
> Ben

Re: Mac OS X Prompt Bug

[Bart Schaefer]

On Nov 24,  4:14pm, Sorin Ionescu wrote:
}
} There is no /etc/zshprofile, /etc/zshrc or any other combination.
} /etc/profile is not sourced.
}
} I have found nothing in the output of zsh -l -x. Like I said, it's
} not a configuration issue. It's something in ZSH or Terminal.app or
} both. Nothing hooks on those functions. It's possible that ZSH outputs
} some sequences Terminal.app does not like and generates those lines.

Things that zsh might be doing when the window first opens include
closing and re-opening the standard I/O streams, reading the name
of the terminal device with ttyname(), setting the close-on-exec
flag on some descriptors, and reading the size of the terminal from
ioctl().  It might also repeat that last a few times if it receives
WINCH signals.

You could try putting a TRAPWINCH function in your ~/.zshenv file
to see if that's called when the blank lines are printed.  Otherwise
you're going to have to resort to some sort of debugger or system
call trace.

Re: Mac OS X Prompt Bug

[Peter Stephenson]

On Wed, 24 Nov 2010 11:04:33 -0800
Wayne Davison <wayned@users.sourceforge.net> wrote:
> One thing that could be done to improve the PROMPT_SP heuristic is to
> output a extra space (assuming the width (w) is 1) and another CR
> after the trailing CR that is currently output.  That would ensure
> that newlines wouldn't show a superfluous percent when no dangling
> output was present. So, how about this?

Thanks.

Might be best just to commit it and see how it works, I suspect just
staring at it isn't going to give us a feel.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom