zkbd on OS X

zkbd on OS X

[Daniel Serodio (lists)]

Hi,

Since 4.3.5 or so[1], zkbd uses ${DISPLAY:-$VENDOR-$OSTYPE} instead of 
$VENDOR-$OSTYPE to identify which zkbd configuration file to use, and 
this is causing an error for me on OS X because $DISPLAY seems to be a 
temporary file (eg "/tmp/launch-PnqDjA/org.x:0").At the end of zkbd 
execution:

mv: rename /Users/dserodio/.zkbd/xterm.tmp to 
/Users/dserodio/.zkbd/xterm-/tmp/launch-PnqDjA/org.x:0: No such file or 
directory

Has anyone had this problem before? Am I doing something wrong?

Thanks in advance,
Daniel Serodio

[1] 
http://zsh.git.sourceforge.net/git/gitweb.cgi?p=zsh/zsh;a=commitdiff_plain;h=bda53dc6d5135750c52f59b9cfbab39b161c0919

Re: zkbd on OS X

[Phil Pennock]

On 2012-01-02 at 16:57 -0200, Daniel Serodio (lists) wrote:
> Since 4.3.5 or so[1], zkbd uses ${DISPLAY:-$VENDOR-$OSTYPE} instead of 

> Has anyone had this problem before? Am I doing something wrong?

You're not doing anything wrong; it was an Xorg/XFree86 assumption about
the value of $DISPLAY, ":0", ":0.0", "hostname:0" or the like.
("hostname:displaynumber.screennumber").  I think that this might be an
X11 requirement ...

On MacOS, it's a Unix-domain socket, used by launchd to dynamically
start up the X11 server when a client opens the socket, and hand off to
the running server.  From an X point of view, this should still have
been exposed as ":0" and the local transport could have been chosen
behind the scenes to be via a Unix-domain socket which triggers the
launchd behaviour.  Alas, Mac's are gratuitously different here.

How about:
----------------------------8< cut here >8------------------------------
if [[ -z "$DISPLAY" || $DISPLAY == */* ]]; then
  termID="$VENDOR-$OSTYPE"
else
  termID="$DISPLAY"
fi
----------------------------8< cut here >8------------------------------

-Phil

Re: zkbd on OS X

[Mikael Magnusson]

On 3 January 2012 11:16, Phil Pennock
<zsh-workers+phil.pennock@spodhuis.org> wrote:
> On 2012-01-02 at 16:57 -0200, Daniel Serodio (lists) wrote:
>> Since 4.3.5 or so[1], zkbd uses ${DISPLAY:-$VENDOR-$OSTYPE} instead of
>
>> Has anyone had this problem before? Am I doing something wrong?
>
> You're not doing anything wrong; it was an Xorg/XFree86 assumption about
> the value of $DISPLAY, ":0", ":0.0", "hostname:0" or the like.
> ("hostname:displaynumber.screennumber").  I think that this might be an
> X11 requirement ...
>
> On MacOS, it's a Unix-domain socket, used by launchd to dynamically
> start up the X11 server when a client opens the socket, and hand off to
> the running server.  From an X point of view, this should still have
> been exposed as ":0" and the local transport could have been chosen
> behind the scenes to be via a Unix-domain socket which triggers the
> launchd behaviour.  Alas, Mac's are gratuitously different here.
>
> How about:
> ----------------------------8< cut here >8------------------------------
> if [[ -z "$DISPLAY" || $DISPLAY == */* ]]; then
>  termID="$VENDOR-$OSTYPE"
> else
>  termID="$DISPLAY"
> fi
> ----------------------------8< cut here >8------------------------------

Why does zkbd use $DISPLAY at all? Why would I be getting different
sequences for urxvt in :1 than in :0? Or have to set everything up
separately when the display number changes?

-- 
Mikael Magnusson

Re: zkbd on OS X

[Daniel Serodio (lists)]

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

Phil Pennock wrote:
> On 2012-01-02 at 16:57 -0200, Daniel Serodio (lists) wrote:
>> Since 4.3.5 or so[1], zkbd uses ${DISPLAY:-$VENDOR-$OSTYPE} instead of
>
>> Has anyone had this problem before? Am I doing something wrong?
>
> You're not doing anything wrong; it was an Xorg/XFree86 assumption about
> the value of $DISPLAY, ":0", ":0.0", "hostname:0" or the like.
> ("hostname:displaynumber.screennumber").  I think that this might be an
> X11 requirement ...
>
> On MacOS, it's a Unix-domain socket, used by launchd to dynamically
> start up the X11 server when a client opens the socket, and hand off to
> the running server.  From an X point of view, this should still have
> been exposed as ":0" and the local transport could have been chosen
> behind the scenes to be via a Unix-domain socket which triggers the
> launchd behaviour.  Alas, Mac's are gratuitously different here.
>
> How about:
> ----------------------------8<  cut here>8------------------------------
> if [[ -z "$DISPLAY" || $DISPLAY == */* ]]; then
>    termID="$VENDOR-$OSTYPE"
> else
>    termID="$DISPLAY"
> fi
> ----------------------------8<  cut here>8------------------------------
Works fine for me, but this fix has to me made not only where zkbd moves 
the temporary file but also when sourceing it in ~/.zshrc

The corresponding lines in .zshrc look somewhat like a kludge.

I was wondering the same thing as Mikael: why does zsh use $DISPLAY in 
the first place? IMHO, it doesn't make sense to have different 
keymapping in :1 then in :0, and having to setup the keyboard when 
$DISPLAY changes.

Regards,
Daniel Serodio

Re: zkbd on OS X

[Mikael Magnusson]

On 3 January 2012 13:40, Daniel Serodio (lists)
<daniel.lists@mandic.com.br> wrote:
> Phil Pennock wrote:
>>
>> On 2012-01-02 at 16:57 -0200, Daniel Serodio (lists) wrote:
>>>
>>> Since 4.3.5 or so[1], zkbd uses ${DISPLAY:-$VENDOR-$OSTYPE} instead of
>>
>>
>>> Has anyone had this problem before? Am I doing something wrong?
>>
>>
>> You're not doing anything wrong; it was an Xorg/XFree86 assumption about
>> the value of $DISPLAY, ":0", ":0.0", "hostname:0" or the like.
>> ("hostname:displaynumber.screennumber").  I think that this might be an
>> X11 requirement ...
>>
>> On MacOS, it's a Unix-domain socket, used by launchd to dynamically
>> start up the X11 server when a client opens the socket, and hand off to
>> the running server.  From an X point of view, this should still have
>> been exposed as ":0" and the local transport could have been chosen
>> behind the scenes to be via a Unix-domain socket which triggers the
>> launchd behaviour.  Alas, Mac's are gratuitously different here.
>>
>> How about:
>> ----------------------------8<  cut here>8------------------------------
>> if [[ -z "$DISPLAY" || $DISPLAY == */* ]]; then
>>   termID="$VENDOR-$OSTYPE"
>> else
>>   termID="$DISPLAY"
>> fi
>> ----------------------------8<  cut here>8------------------------------
>
> Works fine for me, but this fix has to me made not only where zkbd moves the
> temporary file but also when sourceing it in ~/.zshrc
>
> The corresponding lines in .zshrc look somewhat like a kludge.
>
> I was wondering the same thing as Mikael: why does zsh use $DISPLAY in the
> first place? IMHO, it doesn't make sense to have different keymapping in :1
> then in :0, and having to setup the keyboard when $DISPLAY changes.

It looks like Bart added this in
http://zsh.git.sourceforge.net/git/gitweb.cgi?p=zsh/zsh;a=commitdiff;h=bda53dc
but there is no motivation for the $DISPLAY change in the referenced
thread.

-- 
Mikael Magnusson

Re: zkbd on OS X

[Bart Schaefer]

[Was away on travel for a few days.]

On Jan 3, 12:13pm, Mikael Magnusson wrote:
} Subject: Re: zkbd on OS X
}
} On 3 January 2012 11:16, Phil Pennock
} <zsh-workers+phil.pennock@spodhuis.org> wrote:
} > On 2012-01-02 at 16:57 -0200, Daniel Serodio (lists) wrote:
} >> Since 4.3.5 or so[1], zkbd uses ${DISPLAY:-$VENDOR-$OSTYPE} instead of
} >
} >> Has anyone had this problem before? Am I doing something wrong?
} >
} > You're not doing anything wrong; it was an Xorg/XFree86 assumption
} > about the value of $DISPLAY, ":0", ":0.0", "hostname:0" or the like.

Indeed, at the time there really was nothing else to assume.

} > ("hostname:displaynumber.screennumber"). I think that this might be
} > an X11 requirement ...

It's definitely documented that way for X11/XFree86/Xorg.

} > How about:
} > ----------------------------8< cut here >8------------------------------
} > if [[ -z "$DISPLAY" || $DISPLAY == */* ]]; then
} >  termID="$VENDOR-$OSTYPE"
} > else
} >  termID="$DISPLAY"
} > fi
} > ----------------------------8< cut here >8------------------------------

I'd probably go with one of:

local termID=${${DISPLAY%%*/*}:-$VENDOR-$OSTYPE}

or

local termID=${${DISPLAY:t}:-$VENDOR-$OSTYPE}

depending on whether it's better to ignore DISPLAY when it contains a
slash, or to use the part of the file name that corresponds to the X11
display name.  Opinions?

} Why does zkbd use $DISPLAY at all?

The problem with using only $TERM-$VENDOR-$OSTYPE is that with remote
display, you may be either (a) running $TERM on host Q but displaying
on host P, or (b) running $TERM on host Q but with the shell in ssh on
host P.  In either of these cases $VENDOR-$OSTYPE will refer to the
local machine where zsh has started, but the keybindings you want are
for the keyboard attached to the remote machine.

The only obvious way to identify the remote keyboard is to use $DISPLAY.

} Why would I be getting different sequences for urxvt in :1 than in :0?

:0 is presumably the console with a physically attached keyboard, whereas
:1 is most likely a VNC or NX device with a virtual keyboard.  Once again
the keystrokes may be different; e.g., DEL on the physical keyboard might
send ^? but on the virtual keyboard it sends ^[[3~ .  So you need separate
zkbd files for those cases.

} Or have to set everything up separately when the display number changes?

The assumption is that the display number is pretty closely tied to the
source from which that display originates.  That assumption isn't always
going to be correct, but zkbd can't cover all possible cases; the user
is assumed to be intelligent enough to rename some files and change the
corresponding "source" commands if she has special cases.

On Jan 3, 10:40am, Daniel Serodio (lists) wrote:
}
} Works fine for me, but this fix has to me made not only where zkbd moves 
} the temporary file but also when sourceing it in ~/.zshrc

Well, yes obviously.

} The corresponding lines in .zshrc look somewhat like a kludge.

Welcome to the world of terminal/keyboard handling.  There's very little
that is NOT a kludge, given the number of possible different combinations
of physical and virtual terminals and emulators and types of keyboards.
Setting up zsh for my semi-qwerty smartphone keypad was a real joy [not],
but at least it was possible.

} I was wondering the same thing as Mikael: why does zsh use $DISPLAY in 
} the first place? IMHO, it doesn't make sense to have different 
} keymapping in :1 then in :0, and having to setup the keyboard when 
} $DISPLAY changes.

What circumstances are you dealing with where $DISPLAY changes without
some other part of the environment also changing?

Re: zkbd on OS X

[Daniel Serodio (lists)]

Sorry about the delay, replies inline:

Bart Schaefer wrote:
> [Was away on travel for a few days.]
>
> On Jan 3, 12:13pm, Mikael Magnusson wrote:
> } Subject: Re: zkbd on OS X
> }
> } On 3 January 2012 11:16, Phil Pennock
> }<zsh-workers+phil.pennock@spodhuis.org>  wrote:
> }>  On 2012-01-02 at 16:57 -0200, Daniel Serodio (lists) wrote:
> }>>  Since 4.3.5 or so[1], zkbd uses ${DISPLAY:-$VENDOR-$OSTYPE} instead of
> }>
> }>>  Has anyone had this problem before? Am I doing something wrong?
> }>
> }>  You're not doing anything wrong; it was an Xorg/XFree86 assumption
> }>  about the value of $DISPLAY, ":0", ":0.0", "hostname:0" or the like.
>
> Indeed, at the time there really was nothing else to assume.
>
> }>  ("hostname:displaynumber.screennumber"). I think that this might be
> }>  an X11 requirement ...
>
> It's definitely documented that way for X11/XFree86/Xorg.
>
> }>  How about:
> }>  ----------------------------8<  cut here>8------------------------------
> }>  if [[ -z "$DISPLAY" || $DISPLAY == */* ]]; then
> }>   termID="$VENDOR-$OSTYPE"
> }>  else
> }>   termID="$DISPLAY"
> }>  fi
> }>  ----------------------------8<  cut here>8------------------------------
>
> I'd probably go with one of:
>
> local termID=${${DISPLAY%%*/*}:-$VENDOR-$OSTYPE}
>
> or
>
> local termID=${${DISPLAY:t}:-$VENDOR-$OSTYPE}
>
> depending on whether it's better to ignore DISPLAY when it contains a
> slash, or to use the part of the file name that corresponds to the X11
> display name.  Opinions?
>
> } Why does zkbd use $DISPLAY at all?
>
> The problem with using only $TERM-$VENDOR-$OSTYPE is that with remote
> display, you may be either (a) running $TERM on host Q but displaying
> on host P, or (b) running $TERM on host Q but with the shell in ssh on
> host P.  In either of these cases $VENDOR-$OSTYPE will refer to the
> local machine where zsh has started, but the keybindings you want are
> for the keyboard attached to the remote machine.
>
> The only obvious way to identify the remote keyboard is to use $DISPLAY.
>
> } Why would I be getting different sequences for urxvt in :1 than in :0?
>
> :0 is presumably the console with a physically attached keyboard, whereas
> :1 is most likely a VNC or NX device with a virtual keyboard.  Once again
> the keystrokes may be different; e.g., DEL on the physical keyboard might
> send ^? but on the virtual keyboard it sends ^[[3~ .  So you need separate
> zkbd files for those cases.
>
> } Or have to set everything up separately when the display number changes?
>
> The assumption is that the display number is pretty closely tied to the
> source from which that display originates.  That assumption isn't always
> going to be correct, but zkbd can't cover all possible cases; the user
> is assumed to be intelligent enough to rename some files and change the
> corresponding "source" commands if she has special cases.
Makes perfect sense, thanks for the explanation.
> On Jan 3, 10:40am, Daniel Serodio (lists) wrote:
> }
> } Works fine for me, but this fix has to me made not only where zkbd moves
> } the temporary file but also when sourceing it in ~/.zshrc
>
> Well, yes obviously.
>
> } The corresponding lines in .zshrc look somewhat like a kludge.
>
> Welcome to the world of terminal/keyboard handling.  There's very little
> that is NOT a kludge, given the number of possible different combinations
> of physical and virtual terminals and emulators and types of keyboards.
> Setting up zsh for my semi-qwerty smartphone keypad was a real joy [not],
> but at least it was possible.
>
> } I was wondering the same thing as Mikael: why does zsh use $DISPLAY in
> } the first place? IMHO, it doesn't make sense to have different
> } keymapping in :1 then in :0, and having to setup the keyboard when
> } $DISPLAY changes.
>
> What circumstances are you dealing with where $DISPLAY changes without
> some other part of the environment also changing?
My actual problems are:

1) I use Subversion to store my config files, which I share between my 
home and work computers. $DISPLAY is different between them, but I'd 
like the keymappings to be the same.

2) When zkbd finishes executing (eg. because I've changed terminal 
emulators), I get an error (which zkbd neither tries to prevent nor test 
for):

mv: rename /Users/dserodio/.zkbd/xterm.tmp to 
/Users/dserodio/.zkbd/xterm-/tmp/launch-dC1Rir/org.x:0: No such file or 
directory

zkbd should test for the existence of the the destination to mv before 
moving the temp file.

Regards,
Daniel Serodio

Re: zkbd on OS X

[Bart Schaefer]

On Jan 11,  7:53pm, Daniel Serodio (lists) wrote:
}
} Bart Schaefer wrote:
} > I'd probably go with one of:
} >
} > local termID=${${DISPLAY%%*/*}:-$VENDOR-$OSTYPE}
} >
} > or
} >
} > local termID=${${DISPLAY:t}:-$VENDOR-$OSTYPE}
} >
} > depending on whether it's better to ignore DISPLAY when it contains a
} > slash, or to use the part of the file name that corresponds to the X11
} > display name.  Opinions?

[...]

} > What circumstances are you dealing with where $DISPLAY changes without
} > some other part of the environment also changing?
} My actual problems are:
} 
} 1) I use Subversion to store my config files, which I share between my 
} home and work computers. $DISPLAY is different between them, but I'd 
} like the keymappings to be the same.

I do something similar and deal with this kind of thing in this way:

(1) _Don't_ source-control $HOME/.z* files; instead have a $ZDOTDIR
that is source controlled (I use $HOME/.zsh/) and have $HOME/.zshenv
do nothing but export ZDOTDIR and then "source $ZDOTDIR/.zshenv"

(2) Have a subdirectory $ZDOTDIR/local/ which contains symlinks from
standard names for assorted files (such as zkbd bindings) to the actual
files used for each host (this could be somewhere outside ZDOTDIR if it
creates source control conflicts)

(3) Create a little setup script that populates local/ the first time
the ZDOTDIR source tree is checked out on a new host (also creates the
$HOME/.zshenv in my case)

(4) $ZDOTDIR/.zshrc et al. always "source $ZDOTDIR/local/something"
for any config that isn't completely portable.
 
} 2) When zkbd finishes executing (eg. because I've changed terminal 
} emulators), I get an error (which zkbd neither tries to prevent nor test 
} for)

See "Opinions?" question above.

Re: zkbd on OS X

[Daniel Serodio (lists)]

Bart Schaefer wrote:
> On Jan 11,  7:53pm, Daniel Serodio (lists) wrote:
> }
> } Bart Schaefer wrote:
> }>  I'd probably go with one of:
> }>
> }>  local termID=${${DISPLAY%%*/*}:-$VENDOR-$OSTYPE}
> }>
> }>  or
> }>
> }>  local termID=${${DISPLAY:t}:-$VENDOR-$OSTYPE}
> }>
> }>  depending on whether it's better to ignore DISPLAY when it contains a
> }>  slash, or to use the part of the file name that corresponds to the X11
> }>  display name.  Opinions?
I'd go with the second option, as it would be more consistent with the 
behaviour on Linux, but since I don't use remote X I don't really 
understand the pros and cons of each for remote X.
> }>  What circumstances are you dealing with where $DISPLAY changes without
> }>  some other part of the environment also changing?
> } My actual problems are:
> }
> } 1) I use Subversion to store my config files, which I share between my
> } home and work computers. $DISPLAY is different between them, but I'd
> } like the keymappings to be the same.
>
> I do something similar and deal with this kind of thing in this way:
>
> (1) _Don't_ source-control $HOME/.z* files; instead have a $ZDOTDIR
> that is source controlled (I use $HOME/.zsh/) and have $HOME/.zshenv
> do nothing but export ZDOTDIR and then "source $ZDOTDIR/.zshenv"
>
> (2) Have a subdirectory $ZDOTDIR/local/ which contains symlinks from
> standard names for assorted files (such as zkbd bindings) to the actual
> files used for each host (this could be somewhere outside ZDOTDIR if it
> creates source control conflicts)
>
> (3) Create a little setup script that populates local/ the first time
> the ZDOTDIR source tree is checked out on a new host (also creates the
> $HOME/.zshenv in my case)
>
> (4) $ZDOTDIR/.zshrc et al. always "source $ZDOTDIR/local/something"
> for any config that isn't completely portable.
Thanks for the help, I'll give it a try and see how it compares with my 
current setup. Currently, my .zshrc has some if statements testing for 
$OS and hostname for dealing with non-portable stuff.
>
> } 2) When zkbd finishes executing (eg. because I've changed terminal
> } emulators), I get an error (which zkbd neither tries to prevent nor test
> } for)
>
> See "Opinions?" question above.
Sorry I'd skipped this part. I've replied now.

Regards,
Daniel Serodio

Re: zkbd on OS X

[Daniel Serodio (lists)]

Comments inline.

Daniel Serodio wrote:
> Bart Schaefer wrote:
>> On Jan 11,  7:53pm, Daniel Serodio (lists) wrote:
>> }
>> } Bart Schaefer wrote:
>> }>  I'd probably go with one of:
>> }>
>> }>  local termID=${${DISPLAY%%*/*}:-$VENDOR-$OSTYPE}
>> }>
>> }>  or
>> }>
>> }>  local termID=${${DISPLAY:t}:-$VENDOR-$OSTYPE}
>> }>
>> }>  depending on whether it's better to ignore DISPLAY when it 
>> contains a
>> }>  slash, or to use the part of the file name that corresponds to 
>> the X11
>> }>  display name.  Opinions?
> I'd go with the second option, as it would be more consistent with the 
> behaviour on Linux, but since I don't use remote X I don't really 
> understand the pros and cons of each for remote X.
Since no one else chimed in, would you agree to change this zkbd 
behaviour? I prefer the second option but IMHO, any of these is better 
then the current situation (ie. ${DISPLAY:-$VENDOR-$OSTYPE})
>> }>  What circumstances are you dealing with where $DISPLAY changes 
>> without
>> }>  some other part of the environment also changing?
>> } My actual problems are:
>> }
>> } 1) I use Subversion to store my config files, which I share between my
>> } home and work computers. $DISPLAY is different between them, but I'd
>> } like the keymappings to be the same.
>>
>> I do something similar and deal with this kind of thing in this way:
>>
>> (1) _Don't_ source-control $HOME/.z* files; instead have a $ZDOTDIR
>> that is source controlled (I use $HOME/.zsh/) and have $HOME/.zshenv
>> do nothing but export ZDOTDIR and then "source $ZDOTDIR/.zshenv"
>>
>> (2) Have a subdirectory $ZDOTDIR/local/ which contains symlinks from
>> standard names for assorted files (such as zkbd bindings) to the actual
>> files used for each host (this could be somewhere outside ZDOTDIR if it
>> creates source control conflicts)
>>
>> (3) Create a little setup script that populates local/ the first time
>> the ZDOTDIR source tree is checked out on a new host (also creates the
>> $HOME/.zshenv in my case)
>>
>> (4) $ZDOTDIR/.zshrc et al. always "source $ZDOTDIR/local/something"
>> for any config that isn't completely portable.
> Thanks for the help, I'll give it a try and see how it compares with 
> my current setup. Currently, my .zshrc has some if statements testing 
> for $OS and hostname for dealing with non-portable stuff.
I've found this scheme too complicated and ended never implementing it. 
My current setup is working fine, except for this zkbd problem. The 
change suggested above would fix it for my use case.
>>
>> } 2) When zkbd finishes executing (eg. because I've changed terminal
>> } emulators), I get an error (which zkbd neither tries to prevent nor 
>> test
>> } for)
>>
>> See "Opinions?" question above.
> Sorry I'd skipped this part. I've replied now.
Regards,
Daniel Serodio

Re: zkbd on OS X

[Bart Schaefer]

On Mar 13,  7:57pm, Daniel Serodio (lists) wrote:
}
} Since no one else chimed in, would you agree to change this zkbd 
} behaviour? I prefer the second option but IMHO, any of these is better 
} then the current situation (ie. ${DISPLAY:-$VENDOR-$OSTYPE})

This has already been committed to CVS.  ChangeLog:

2012-02-29  Barton E. Schaefer  <schaefer@zsh.org>

        * unposted (see users/16697): Functions/Misc/zkbd: select a more
        reasonable output file name when the DISPLAY variable refers to a
        local socket file (MacOS); fix problem with writing the output
        file when the user overrides the default value of TERM.

Re: zkbd on OS X

[Daniel Serodio (lists)]

Great news, thanks.

Regards,
Daniel Serodio

Bart Schaefer wrote:
> On Mar 13,  7:57pm, Daniel Serodio (lists) wrote:
> }
> } Since no one else chimed in, would you agree to change this zkbd
> } behaviour? I prefer the second option but IMHO, any of these is better
> } then the current situation (ie. ${DISPLAY:-$VENDOR-$OSTYPE})
>
> This has already been committed to CVS.  ChangeLog:
>
> 2012-02-29  Barton E. Schaefer<schaefer@zsh.org>
>
>          * unposted (see users/16697): Functions/Misc/zkbd: select a more
>          reasonable output file name when the DISPLAY variable refers to a
>          local socket file (MacOS); fix problem with writing the output
>          file when the user overrides the default value of TERM.
>