weird behaviour

weird behaviour

[david sowerby]

====================================================
Morality is doing what is right, no matter what you are told.
Religion is doing what you are told, no matter what is right.
                                                              H.L. Mencken

Re: weird behaviour

[david sowerby]

Thanks for the quick reply. I did think about the PS1 being a problem.  Everything is surrounded with 
%{    %}.   I'll try a more basic prompt and let you know.  -----------------------------dave 

====================================================
Morality is doing what is right, no matter what you are told.
Religion is doing what you are told, no matter what is right.
                                                              H.L. Mencken

--------------------------------------------
On Mon, 5/9/16, Nikolay Aleksandrovich Pavlov (ZyX) <kp-pav@yandex.ru> wrote:

 Subject: Re: weird behaviour
 To: "david sowerby" <d_sowerby@yahoo.com>, "zsh-users@zsh.org" <zsh-users@zsh.org>
 Date: Monday, May 9, 2016, 1:04 PM
 
 09.05.2016, 21:40,
 "david sowerby" <d_sowerby@yahoo.com>:
 >
 I noticed recently that when I <tab> to complete zsh
 doubles the first letter of the command eg:
 > % cd T <tab> expands to TV - as
 expected and the expansion works as normal - unless there
 are more than one choice when it does this
 > % ccd /TV/TV/ARROW/ with the multiple dirs
 shown below as expected
 > This
 doesn't affect the command at all, and if I backspace I
 can't remove the first 'c', and if I then hit
 <enter> nothing happens ie as if the command
 'c' isn't there.
 > I'm
 using 5.0.7 (Debian 8) in urvxt. I also tested in xterm and
 get the same result, strangely it doesn't happen on a
 console. I tried zsh -l in urxvt and get the same double
 letter result, but in xterm it is fine! Running a bare
 "compinit" without any extras doesn't make any
 difference. Has anyone else noticed this? I'm baffled
 :-/
 >
 ------------------------------dave
 >
 >
 ====================================================
 > Morality is doing what is right, no matter
 what you are told.
 > Religion is doing
 what you are told, no matter what is right.
 >
                                                               H.L.
 Mencken
 
 You clearly
 have some problem with prompt. Most likely you forgot to
 surround something in PS1 with %{ … %} and zsh was no
 longer able to determine real prompt width. When you do
 completion in some cases zsh needs to redraw command text in
 which case it basically does “go to position {just after
 the place where PS1 ends} and print ‘cd …’”. If
 position is wrong you see what you see, but zsh still knows
 that it needs to run “cd …” and not “ccd …”.
 
 Except for missing %{ … %}
 there is another possible reason for this: zsh thinks that
 some character is double width, but terminal emulator thinks
 it has single width. If this is the case I do not know how
 to fix this cleanely (it is always possible to construct
 some hack).
 
 In any case you
 need to check your PS1.

Re: weird behaviour

[Bart Schaefer]

On Mon, May 9, 2016 at 1:33 PM, david sowerby <d_sowerby@yahoo.com> wrote:
> Thanks for the quick reply. I did think about the PS1 being a problem.  Everything is surrounded with
> %{    %}.

It's also possible that you have too much surrounded by %{ %}, i.e.,
there is something inside the braces that isn't really zero-width.

weird behaviour

[david sowerby]

I noticed recently that when I <tab> to complete zsh doubles the first letter of the command eg:
% cd T <tab> expands to TV - as expected and the expansion works as normal - unless there are more than one choice when it does this
% ccd /TV/TV/ARROW/  with the multiple dirs shown below as expected
This doesn't affect the command at all, and if I backspace I can't remove the first 'c', and if I then hit <enter> nothing happens ie as if the command 'c' isn't there.
I'm using 5.0.7 (Debian 8) in urvxt. I also tested in xterm and get the same result, strangely it doesn't happen on a console. I tried zsh -l in urxvt and get the same double letter result, but in xterm it is fine!  Running a bare "compinit" without any extras doesn't make any difference. Has anyone else noticed this? I'm baffled :-/
------------------------------dave 


====================================================
Morality is doing what is right, no matter what you are told.
Religion is doing what you are told, no matter what is right.
                                                              H.L. Mencken

Re: weird behaviour

[Nikolay Aleksandrovich Pavlov (ZyX)]

09.05.2016, 21:40, "david sowerby" <d_sowerby@yahoo.com>:
> I noticed recently that when I <tab> to complete zsh doubles the first letter of the command eg:
> % cd T <tab> expands to TV - as expected and the expansion works as normal - unless there are more than one choice when it does this
> % ccd /TV/TV/ARROW/ with the multiple dirs shown below as expected
> This doesn't affect the command at all, and if I backspace I can't remove the first 'c', and if I then hit <enter> nothing happens ie as if the command 'c' isn't there.
> I'm using 5.0.7 (Debian 8) in urvxt. I also tested in xterm and get the same result, strangely it doesn't happen on a console. I tried zsh -l in urxvt and get the same double letter result, but in xterm it is fine! Running a bare "compinit" without any extras doesn't make any difference. Has anyone else noticed this? I'm baffled :-/
> ------------------------------dave
>
> ====================================================
> Morality is doing what is right, no matter what you are told.
> Religion is doing what you are told, no matter what is right.
>                                                               H.L. Mencken

You clearly have some problem with prompt. Most likely you forgot to surround something in PS1 with %{ … %} and zsh was no longer able to determine real prompt width. When you do completion in some cases zsh needs to redraw command text in which case it basically does “go to position {just after the place where PS1 ends} and print ‘cd …’”. If position is wrong you see what you see, but zsh still knows that it needs to run “cd …” and not “ccd …”.

Except for missing %{ … %} there is another possible reason for this: zsh thinks that some character is double width, but terminal emulator thinks it has single width. If this is the case I do not know how to fix this cleanely (it is always possible to construct some hack).

In any case you need to check your PS1.

Weird behaviour

[Raghavendra D Prabhu]

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

Hi,
I was just testing out something and I noticed following

===========================
Xye% ""
zsh: permission denied:
============================
Is this a bug or some weird quirk ?

--------------------------
Raghavendra Prabhu
GPG ID:D72BE977


[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: Weird behaviour

[Bart Schaefer]

On Apr 3,  2:30am, Raghavendra D Prabhu wrote:
}
} Xye% ""
} zsh: permission denied:
} ============================
} Is this a bug or some weird quirk ?

Neither, exactly.

You've asked the shell to execute the command named (empty string) found
anywhere in the directories named in $PATH.

Bash searches the path and finds no executable file named (empty string)
so it gives up and prints "command not found".

Zsh does the same search, but instead of giving up at the end it repeats
the attempt with actual execve() system calls, so as to find the "real"
error that the operating system would report if you were to have typed
out the full path to the command.  That error is "permission denied"
because (any directory name)/(empty string) is the same as the directory
itself, and directories can't be executed as commands.

Aside:  As it happens, if you were to have typed out the full path in
bash, it first calls execve(), but when that fails with "permission
denied" bash goes one step further and stat()s the path to determine
if it is a directory, and if so prints "is a directory" instead of the
permission error.

Re: Weird behaviour

[Raghavendra D Prabhu]

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

* On Sat, Apr 02, 2011 at 05:05:29PM -0700, Bart Schaefer <schaefer@brasslantern.com> wrote:
>On Apr 3,  2:30am, Raghavendra D Prabhu wrote:
>}
>} Xye% ""
>} zsh: permission denied:
>} ============================
>} Is this a bug or some weird quirk ?
>
>Neither, exactly.
>
>You've asked the shell to execute the command named (empty string) found
>anywhere in the directories named in $PATH.
>
>Bash searches the path and finds no executable file named (empty string)
>so it gives up and prints "command not found".
>
>Zsh does the same search, but instead of giving up at the end it repeats
>the attempt with actual execve() system calls, so as to find the "real"
>error that the operating system would report if you were to have typed
>out the full path to the command.  That error is "permission denied"
>because (any directory name)/(empty string) is the same as the directory
>itself, and directories can't be executed as commands.
>
>Aside:  As it happens, if you were to have typed out the full path in
>bash, it first calls execve(), but when that fails with "permission
>denied" bash goes one step further and stat()s the path to determine
>if it is a directory, and if so prints "is a directory" instead of the
>permission error.
Cool. Thanks for the explanation.
--------------------------
Raghavendra Prabhu
GPG ID:D72BE977


[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]