"2004h" at the end of each prompt and "2004l" after pressing Enter on DragonFlyBSD console with zsh 5.1.1

"2004h" at the end of each prompt and "2004l" after pressing Enter on DragonFlyBSD console with zsh 5.1.1

[Axel Beckert]

Hi,

I've just downloaded the DragonFlyBSD image from
http://ftp.halifax.rwth-aachen.de/dragonflybsd/iso-images/dfly-x86_64-4.2.4_REL.img.bz2,
started it inside kvm, installed zsh 5.1.1 with "pkg install zsh" and
started it.

I've set a very simple prompt inside ~/.zshrc:

PROMPT="%~ # "

But my prompt always looks like this:

~ # 2004h_

And if I press just Enter, it looks like this:

~ # 2004h2004l
~ # 2004h_

(Underscore shows where the cursor is.)

Even with "zsh -f" the prompt looks like this:

# 2004h_

With a little bit help of an internet search engine I found this
posting which suggests that this is related to the bracketed pasting:
http://www.zsh.org/mla/users//2015/msg00801.html

Anyone an idea how I get rid of these prompt postfixes? There seems no
global zshrc or similar. (And the global zshrc wouldn't be involved
anyways since it also happens with "zsh -f".)

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.nonhtmlmail.org/campaign.html | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://abe.noone.org/ (Web)

Re: "2004h" at the end of each prompt and "2004l" after pressing Enter on DragonFlyBSD console with zsh 5.1.1

[Bart Schaefer]

The short answer to your question is:

    unset zle_bracketed_paste

The longer answer is:

Congratulations, you've just disproved the assumption that all terminals
(emulators) will consume and discard the start-of-bracketed-paste escape
sequence even if they don't support the feature.  Some of us were worried
about that when the feature was introduced, but no counter-examples were
forthcoming during development.

I'm guessing you're on the BSD system console?  If not, what terminal
program are you using?

Any idea how we can test for support of this feature and disable it
automatically on terminals that don't support it?

Re: "2004h" at the end of each prompt and "2004l" after pressing Enter on DragonFlyBSD console with zsh 5.1.1

[Axel Beckert]

Hi,

On Fri, Oct 09, 2015 at 04:04:52PM -0700, Bart Schaefer wrote:
> The short answer to your question is:
> 
>     unset zle_bracketed_paste

This works if I enter it manually at the shell prompt, but does
neither work in .zshrc nor in .zshenv. It though does work if I source
the according files manually afterwards. Strange. The file is read
though since the remainder of the prompt works fine.

> Congratulations, you've just disproved the assumption that all terminals
> (emulators) will consume and discard the start-of-bracketed-paste escape
> sequence even if they don't support the feature.

Yay! ;-)

> Some of us were worried about that when the feature was introduced,
> but no counter-examples were forthcoming during development.

JFTR: This does not happen with bash (4.3.42) or tcsh (6.18.01) in the
same environment.

> I'm guessing you're on the BSD system console?

Yes, as mentioned in the subject. The image I mentioned in my initial
mail is without X and I've just started it inside kvm and logged in on
the console there, i.e. no remote login via SSH or such.

> Any idea how we can test for support of this feature and disable it
> automatically on terminals that don't support it?

Nope. Except maybe looking how bash does it. :-)

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.nonhtmlmail.org/campaign.html | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://abe.noone.org/ (Web)

Re: "2004h" at the end of each prompt and "2004l" after pressing Enter on DragonFlyBSD console with zsh 5.1.1

[Axel Beckert]

Hi again,

On Sat, Oct 10, 2015 at 01:32:24AM +0200, Axel Beckert wrote:
> > I'm guessing you're on the BSD system console?
> 
> Yes, as mentioned in the subject. The image I mentioned in my initial
> mail is without X and I've just started it inside kvm and logged in on
> the console there, i.e. no remote login via SSH or such.
> 
> > Any idea how we can test for support of this feature and disable it
> > automatically on terminals that don't support it?

JFTR: $TERM is set to "cons25" there.

> Nope. Except maybe looking how bash does it. :-)

... if it has such a feature.

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.nonhtmlmail.org/campaign.html | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://abe.noone.org/ (Web)

Re: "2004h" at the end of each prompt and "2004l" after pressing Enter on DragonFlyBSD console with zsh 5.1.1

[Oliver Kiddle]

Bart wrote:
> Any idea how we can test for support of this feature and disable it
> automatically on terminals that don't support it?

The approach I suggested in workers/35393 would work for this case.
That is, there is no output from the following with TERM set to cons25.
  printf '%s %q\n' ${(kv)terminfo[(R)*[0-9](#c4)[hl]]}

I'm fairly sure that I tried the console on FreeBSD which may have also
been cons25 but much of DragonFly is presumably older. The question is
whether we want to make such a change.

Axel wrote:
> >     unset zle_bracketed_paste
> 
> This works if I enter it manually at the shell prompt, but does
> neither work in .zshrc nor in .zshenv. 

It needs to come after the zle module has loaded. So put it nearer the
bottom of .zshrc - after your bindkeys would do the job.

Oliver

Re: "2004h" at the end of each prompt and "2004l" after pressing Enter on DragonFlyBSD console with zsh 5.1.1

[Axel Beckert]

Hi,

On Sat, Oct 10, 2015 at 02:37:33AM +0200, Oliver Kiddle wrote:
> I'm fairly sure that I tried the console on FreeBSD which may have also
> been cons25 but much of DragonFly is presumably older.

That's what I would have expected, too.

> The question is whether we want to make such a change.

JFTR: I don't mind if that doesn't get fixed as I only used
DragonFlyBSD to debug an issue with a different Open Source project
which hasn't shown up on any other OS so far.

> Axel wrote:
> > >     unset zle_bracketed_paste
> > 
> > This works if I enter it manually at the shell prompt, but does
> > neither work in .zshrc nor in .zshenv. 
> 
> It needs to come after the zle module has loaded.

Thanks! So I'll need to load that explicitly.

> So put it nearer the bottom of .zshrc

I tried at the very end and very beginning. But then again there were
only two lines in there: Setting the prompt and unsetting
zle_bracketed_paste. :-)

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.nonhtmlmail.org/campaign.html | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://abe.noone.org/ (Web)

what is truth?

[Ray Andrews]

test ()
{
[[ "$1" = <-> ]]  && echo true
}

I don't have a clue what to make of ' <-> '.  What value
would work?

Re: what is truth?

[Kurtis Rader]

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

On Fri, Oct 9, 2015 at 8:24 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:

>
> test ()
> {
> [[ "$1" = <-> ]]  && echo true
> }
>
> I don't have a clue what to make of ' <-> '.  What value
> would work?
>

The redirection characters "<" and ">" are apparently still interpreted as
such even within a "[[ ]]" construct. Or something very similar is
occurring. Replace the dash with "x":

[[ '<->' = <x> ]] && echo true

You'll get the error "zsh: parse error: condition expected: '<->'". If you
quote the right-hand side of that expression you get the expected behavior
(with the original dash or the "x"). If you want to literally match "<->"
then put it inside single or double quote characters.

You need to understand that all UNIX shells, including zsh, have extremely
ad-hoc unexpected behaviors. This is a consequence of their input parsing
model coupled with dynamic options that configure them to behave more or
less like another shell. If you want more predictable and understandable
behavior you should be using languages like Python or Ruby.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: what is truth?

[Mikael Magnusson]

On Sat, Oct 10, 2015 at 5:24 AM, Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> test ()
> {
> [[ "$1" = <-> ]]  && echo true
> }
>
> I don't have a clue what to make of ' <-> '.  What value
> would work?

In zsh pattern matching, <x-y>, where x and y are numbers, it matches
a number (of any length) between x and y, numerically. If you leave
either end out, that end is open. So <-> matches a numeric expression
of any length, viz

% test abc
% test 123
true
% test 123abc

-- 
Mikael Magnusson

Re: what is truth?

[Bart Schaefer]

On Oct 9,  8:24pm, Ray Andrews wrote:
} Subject: what is truth?

Please use an actual descriptive subject rather than faux philosophical
pondering.  Thanks.

} I don't have a clue what to make of ' <-> '.  What value
} would work?

<[X]-[Y]>
     Matches any number in the range X to Y, inclusive.  Either of the
     numbers may be omitted to make the range open-ended; hence `<->'
     matches any number.  To match individual digits, the [...] form is
     more efficient.


Also, not stated in the doc, but ranges of this sort are compared using
integer values so they are limited by the representable integers in the
local architecture.  If you really want to match an arbitrarily long
string of digits, you should setopt extendedglob and use [0-9]##.

Re: what is truth?

[Ray Andrews]

On 10/09/2015 09:16 PM, Kurtis Rader wrote:
> On Fri, Oct 9, 2015 at 8:24 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:
>
>> test ()
>> {
>> [[ "$1" = <-> ]]  && echo true
>> }
>>
>> I don't have a clue what to make of ' <-> '.  What value
>> would work?
>>
> The redirection characters "<" and ">" are apparently still interpreted as
> such even within a "[[ ]]" construct. Or something very similar is
> occurring. Replace the dash with "x":
Thanks Kurtis, it does seem that it's  trying to interpret that as 
redirection.  I thought there
might be some strange cryptic meaning.  So really then it's a test that 
can never be true
nevertheless the parser still accepts it.  Or maybe there really could 
be redirection in there.
> You need to understand that all UNIX shells, including zsh, have extremely
> ad-hoc unexpected behaviors.

I've noticed ;-)  An honest comment like that saves much grief, since 
one might be prepared
ahead of time for strange behavior.  Man ... when I first got involved 
in this I was expecting
absolutely bulletproof perfection.  That was a long time ago.
> This is a consequence of their input parsing
> model coupled with dynamic options that configure them to behave more or
> less like another shell. If you want more predictable and understandable
> behavior you should be using languages like Python or Ruby.
Yup, but learning a shell seemed like a necessary thing.

Re: what is truth?

[Ray Andrews]

On 10/09/2015 09:25 PM, Mikael Magnusson wrote:
> In zsh pattern matching, <x-y>, where x and y are numbers, it matches
> a number (of any length) between x and y, numerically. If you leave
> either end out, that end is open. So <-> matches a numeric expression
> of any length, viz
Marvelous.  Thanks Mikael.

Re: what is truth?

[Kurtis Rader]

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

On Fri, Oct 9, 2015 at 9:16 PM, Kurtis Rader <krader@skepticism.us> wrote:

> The redirection characters "<" and ">" are apparently still interpreted as
> such even within a "[[ ]]" construct. Or something very similar is
> occurring. Replace the dash with "x":
>
> [[ '<->' = <x> ]] && echo true
>
> You'll get the error "zsh: parse error: condition expected: '<->'". If you
> quote the right-hand side of that expression you get the expected behavior
> (with the original dash or the "x"). If you want to literally match "<->"
> then put it inside single or double quote characters.
>

Oy Vey! After seeing the responses from Mikael and Bart I realized that I
did not know about the pattern <[x]-[y]> as documented under "Glob
Operators" in the "man zshexpn" documentation. Which itself surprises me
since I've been a programmer since 1978 and fell in love with UNIX a couple
of years later.

This reinforces my belief that zsh, and to a lesser degree other shells
such as ksh, have enough idiosyncratic behaviors that they should not be
used where non-trivial semantics are relevant.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: what is truth?

[Ray Andrews]

On 10/09/2015 09:26 PM, Bart Schaefer wrote:
> On Oct 9,  8:24pm, Ray Andrews wrote:
> } Subject: what is truth?
>
> Please use an actual descriptive subject rather than faux philosophical
> pondering.  Thanks.
>
> } I don't have a clue what to make of ' <-> '.  What value
> } would work?
>
> <[X]-[Y]>
What is lacking is knowing where to look for that kind of information.  
We have expansions, substitutions, designators, modifiers, operators, 
matches, globs, flags, subscripts and so on. Getting the overview of the 
jargon is what I must master so that I can pick the right chapter to 
read.  Searching for the above literally I see that is a glob operator.  
It is astonishing how much
syntax can be carried by just a few symbols.

Re: what is truth?

[Phil Pennock]

On 2015-10-09 at 20:24 -0700, Ray Andrews wrote:
> 
> test ()
> {
> [[ "$1" = <-> ]]  && echo true
> }
> 
> I don't have a clue what to make of ' <-> '.  What value
> would work?

Any number.
Well, okay, any non-negative integer.

It's a glob operator:
----------------------------8< cut here >8------------------------------
 <[x]-[y]>
        Matches any number in the range x to y,  inclusive.   Either  of
        the  numbers  may be omitted to make the range open-ended; hence
        `<->' matches any number.  To match individual digits, the [...]
        form is more efficient.
----------------------------8< cut here >8------------------------------

Please don't hijack existing threads (was: what is truth?)

[Axel Beckert]

Dear Ray,

On Fri, Oct 09, 2015 at 08:24:33PM -0700, Ray Andrews' mail contained
in its headers:
> Subject: what is truth?
> References: <20151009220942.GH12039@sym.noone.org>
>         <151009160452.ZM5208@torch.brasslantern.com>
>         <4505.1444437453@thecus.kiddle.eu>
>	  <20151010005939.GK12039@sym.noone.org>
> In-reply-to: <20151010005939.GK12039@sym.noone.org>

All these referenced mails had the subject '"2004h" at the end of each
prompt and "2004l" after pressing Enter on DragonFlyBSD console with
zsh 5.1.1'.

But your mail had _nothing_ at all to do with that thread.

So if you want to start a new thread or topic, please do _not_ just
reply to any mail on the same list and just change the subject. This
confuses other readers for no reason.

FYI: There is more legacy in such mails than just the subject and this
additional information makes it look like this in any threaded mail
reader:

  13   < Sat·10·Oct To zsh-users@zsh [To zsh-users] (1.2K   40) "2004h" at the end of each prompt […]
  14 r T Sat·10·Oct Bart Schaefer    [To zsh-users] (0.6K   17) └─>
  15 r L Sat·10·Oct Oliver Kiddle    [Cc zsh-users] (0.8K   22)   ├─>
  16   < Sat·10·Oct To zsh-users@zsh [To zsh-users] (1.2K   36)   │ ├─>
  17   L Sat·10·Oct Ray Andrews      [To zsh-users] (0.1K    8)   │ │ └─>what is truth?
  18   L Sat·10·Oct Phil Pennock     [Cc zsh-users] (0.6K   21)   │ │   ├─>
  19 N L Sat·10·Oct Mikael Magnusson [Cc Zsh Users] (0.5K   22)   │ │   ├─>
  20 N L Sat·10·Oct Ray Andrews      [To zsh-users] (0.3K    6)   │ │   │ └─>
  21 N L Sat·10·Oct Kurtis Rader     [Cc Zsh Users] (1.2K   37)   │ │   ├─>
  22 N L Sat·10·Oct Ray Andrews      [To zsh-users] (1.4K   33)   │ │   │ ├─>
  23 N L Sat·10·Oct Kurtis Rader     [Cc Zsh Users] (1.2K   32)   │ │   │ └─>
  24   L Sat·10·Oct Bart Schaefer    [To zsh-users] (0.7K   20)   │ │   └─>
  25   L Sat·10·Oct Ray Andrews      [To zsh-users] (0.7K   18)   │ │     └─>
  26   L Sat·10·Oct Bart Schaefer    [To zsh-worke] (0.6K   15)   │ └─>
  27 r < Sat·10·Oct To zsh-users@zsh [To zsh-users] (1.6K   41)   └─>
  28   < Sat·10·Oct To zsh-users@zsh [To zsh-users] (0.9K   24)     └─>

Thanks in advance!

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.nonhtmlmail.org/campaign.html | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://abe.noone.org/ (Web)

Re: Please don't hijack existing threads

[Ray Andrews]

On 10/11/2015 06:54 AM, Axel Beckert wrote:
> Dear Ray,
>
> On Fri, Oct 09, 2015 at 08:24:33PM -0700, Ray Andrews' mail contained
> in its headers:
Sorry all, I thought changing the subject was sufficient.

Re: Please don't hijack existing threads

[ZyX]

11.10.2015, 17:43, "Ray Andrews" <rayandrews@eastlink.ca>:
> On 10/11/2015 06:54 AM, Axel Beckert wrote:
>>  Dear Ray,
>>
>>  On Fri, Oct 09, 2015 at 08:24:33PM -0700, Ray Andrews' mail contained
>>  in its headers:
>
> Sorry all, I thought changing the subject was sufficient.

It depends on the mail client. Most I use automatically “start a new thread” should the topic change. But this is usually the case for the mail clients which provide linear thread view. Mail clients with tree threads (e.g. kmail from KDE) use references found in mail headers and this makes your “new” message be buried inside another thread. AFAIK this is also the case for the web view of the mailing list archive.

Re: Please don't hijack existing threads

[Ray Andrews]

On 10/11/2015 08:04 AM, ZyX wrote:
>
> Sorry all, I thought changing the subject was sufficient.
> It depends on the mail client. Most I use automatically “start a new thread” should the topic change. But this is usually the case for the mail clients which provide linear thread view. Mail clients with tree threads (e.g. kmail from KDE) use references found in mail headers and this makes your “new” message be buried inside another thread. AFAIK this is also the case for the web view of the mailing list archive.
>
I had no idea there were thread-view email clients; it sounds like a 
good idea.  I use the
detestable, dozy Thunderbird.  Anyway, it looks like it's better hygiene 
to just start from
scratch which I will certainly do from now on.  Thanks Axel for pointing 
it out.  My questions
are bad enough without that added irritation.