Re: snarf device bug?
>(the snarf buffer device) is bound to two places, but serves a
>different function in each.
> on /dev ...
>On /chan it communicates with Tk or wm, but not with the host. The
>result is 2 separate clipboards, which is not desired behaviour.
#^ isn't able to make two clipboards: it only ever reads and writes the host's
clipboard. the snarf files come from two distinct sources.
in your example:
% ns | grep '#\^'
bind -b '#^' /dev
bind -b '#^' /chan
% cat /dev/snarf
Dulux™ Color Matches%
% cat /chan/snarf
you've only looked for #^ in the output of ns, but that doesn't tell you what's
uppermost on either /dev or /chan. almost certainly (as in my case), /dev has #^
topmost, but in /chan it's a completely different snarf file, served by wm/toolbar.
how to tell? ls -l is probably easiest:
% ls -l '#^'
rw- ^ 0 forsyth forsyth 0 Mar 22 06:24 #^/snarf
% ls -l /dev/snarf
--rw-rw- rw- ^ 0 forsyth forsyth 0 Mar 22 06:24 /dev/snarf
% ls -l /chan/snarf
--rw- rw---- s 0 forsyth forsyth 0 Mar 22 06:24 /chan/snarf
and you'd have seen something similar in your case. the reason is that wm/toolbar puts #s
in a union mount on TOP of the #^ previously bound to /chan, and creates its own "snarf"
service there (using file2chan). wmsetup is presumably run after it does that, so adding
the bind -b to wmsetup means that the host-oriented snarf file overrides wm/toolbar's,
and is subsequently used by everything.
arguably wm/toolbar could check to see if a snarf file already exists, and not
create its own. that would make it harder to have separate clipboards, without an option,
but i expect most people find a single one more convenient, reducing the barriers between