Home > Archive > Unix Shell Programming > December 2004 > clobbering of last line by zsh prompt
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
clobbering of last line by zsh prompt
|
|
|
|
I'm generally very impressed by the design of zsh, but the way zsh
handles the case when the output to stdout does not end with a new
line is just terrible. E.g.
% echo foo
foo
% echo -n foo
%
The second 'foo' got clobbered by the zsh prompt. There's *no*
excuse for such design. I understand that if PS1 doesn't begin in
column 0 this can confuse the code for the RPROMPT, etc., etc.,
etc., but would it have been so difficult to have the shell simply
do this
% echo -n foo
foo
zsh: appended newline to output
%
???
(Of course, this would be subject to customization by the user,
for those who prefer the zsh-classic approach to newline-less
output.)
I'm aware of the solutions to this offered in the Zsh FAQ, but IMO
they are all far less preferable than the approach I've just
described.
The question is how can a lowly user implement this approach? Is
there any way for precmd to know whether the previous output ended
in a newline, or, alternatively whether the insertion point after
that output is at column 0 (and in this way decide whether to stick
a newline, and maybe a warning message as shown above, in front of
PS1 or not)?
Thanks!
kj
--
NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.
| |
| Geoff Wing 2004-12-27, 3:55 am |
| kj <socyl@987jk.com.invalid> typed:
: The second 'foo' got clobbered by the zsh prompt. There's *no*
: excuse for such design.
I'm sure there's some excuse. Let me see . . . umm . . . oh, yes . . . 'cos
that's the only way it can work in real life.
: I understand that if PS1 doesn't begin in
: column 0 this can confuse the code for the RPROMPT, etc., etc.,
: etc., but would it have been so difficult to have the shell simply
: do this
:
: % echo -n foo
: foo
: zsh: appended newline to output
: %
Yes, it would have been so difficult. To effectively do this you need
to insert something between all programs which wish to write to the tty
the shell is running on and the normal tty handler, i.e. implement a kernel
subroutine to pass all output to the shell and have the shell pass it
through some other kernel subroutine to be output. And provide this for
every OS. And have everyone update their kernel to run the shell.
: The question is how can a lowly user implement this approach?
You can't. You can only provide hacks which work for some cases.
Regards,
Geoff
| |
| Boyd Adamson 2004-12-27, 3:55 am |
| kj <socyl@987jk.com.invalid> writes:
> I'm generally very impressed by the design of zsh, but the way zsh
> handles the case when the output to stdout does not end with a new
> line is just terrible. E.g.
>
> % echo foo
> foo
> % echo -n foo
> %
>
> The second 'foo' got clobbered by the zsh prompt. There's *no*
> excuse for such design. I understand that if PS1 doesn't begin in
> column 0 this can confuse the code for the RPROMPT, etc., etc.,
> etc., but would it have been so difficult to have the shell simply
> do this
>
> % echo -n foo
> foo
> zsh: appended newline to output
> %
This would require the shell watching the entire output of every command
to react accordingly, and probably a redesign of portions of the OS.
However, your first example is a nearly exact match for one in the zsh
FAQ:
http://zsh.sunsite.dk/FAQ/zshfaq03.html#l39
| |
| Kevin Rodgers 2004-12-27, 3:57 pm |
| Geoff Wing wrote:
> kj <socyl@987jk.com.invalid> typed:
> : The second 'foo' got clobbered by the zsh prompt. There's *no*
> : excuse for such design.
>
> I'm sure there's some excuse. Let me see . . . umm . . . oh, yes . . . 'cos
> that's the only way it can work in real life.
>
> : I understand that if PS1 doesn't begin in
> : column 0 this can confuse the code for the RPROMPT, etc., etc.,
> : etc., but would it have been so difficult to have the shell simply
> : do this
> :
> : % echo -n foo
> : foo
> : zsh: appended newline to output
> : %
>
> Yes, it would have been so difficult. To effectively do this you need
> to insert something between all programs which wish to write to the tty
> the shell is running on and the normal tty handler, i.e. implement a kernel
> subroutine to pass all output to the shell and have the shell pass it
> through some other kernel subroutine to be output. And provide this for
> every OS. And have everyone update their kernel to run the shell.
Why can't zsh do what every other shell (that I'm familiar with) does?
% echo -n foo
foo%
--
Kevin Rodgers
| |
| Boyd Adamson 2004-12-27, 8:56 pm |
| Kevin Rodgers <ihs_4664@yahoo.com> writes:
> Geoff Wing wrote:
>
> Why can't zsh do what every other shell (that I'm familiar with) does?
>
> % echo -n foo
> foo%
It can,
setopt nopromptcr
but that leaves any shell unaware of the current cursor location when it
prints its prompt. Since zsh has interactive features like RPROMPT and
multi-line editing that look awful unless it can compensate (which it
can't without knowing where the prompt ends) it clears the line first,
to at least put the prompt in a known location. The above command turns
that behaviour off.
See the FAQ for more info:
http://zsh.sunsite.dk/FAQ/zshfaq03.html#l39
By the way, in ksh try doing the equivalent to your example above:
$ print -n foo
Then type a line long enough to wrap. Ksh will screw up its
scroll-text-to-the-left behaviour for exactly the reason I mention
above (at least in any (genuine) ksh I've used).
|
|
|
|
|