Re: setxkbmap cannot completely set compose key

2020-02-19 Thread NilsOla Nilsson
To sum up:
It helped by recompile and reinstall xterm.
But only for
a) newly started xterm's
b) the xterm where the recompile/reinstall was run
I don't remember if I was running stable or current at
the time.

/NilsOla

On Thu, Feb 20, 2020 at 07:46:35AM +0100, NilsOla Nilsson wrote:
> We had the same problem in this thread:
> https://marc.info/?l=openbsd-misc=156352002210168=2
> 
> It is working fine for me now, so I can't reproduce it.
> 
> /NilsOla
> 
> 
> On Thu, Feb 20, 2020 at 06:03:53AM +, Xianwen Chen (陈贤文) wrote:
> > Dear Ingo,
> > 
> > Danke!
> > 
> > On 2/19/20, Ingo Schwarze  wrote:
> > > Just to make sure it worked, could you please show the output of:
> > >
> > >$ setxkbmap -query
> > 
> > The output is:
> > 
> > rules:  base
> > model:  pc105
> > layout: us
> > variant:dvp
> > options:compose:ralt
> > 
> > > What exactly do you mean by "not able to use"?
> > > If, while xterm is in focus, you press and relese the compose key,
> > > then press and release the first key, then press and release the
> > > second key, then press and release some latin letter key, what
> > > exactly happens after each step?
> > 
> > To type for example ø, I press and release the compose key, then press
> > and release the / key, and then press and release the o key. I get
> > /o
> > on xterm, but ø on firefox.
> > 
> > > Guessing blindly, the problem might be that while firefox finds a font
> > > to display the character, xterm does not.  Or that you have changed
> > > your xterm configuration in some way that disables UTF-8 (it is on
> > > by default).  Can you please retry in xterm with a different character
> > > that can be displayed in xterm out of the box, say U+00E5 LATIN
> > > SMALL LETTER A WITH RING ABOVE?  What happens if you type and release
> > > ralt, then a, then a, then x?
> > 
> > xterm can display å too, when I copies it using shift+insert from
> > firefox or other places.
> > 
> > xterm can display ø when I copies it using shift+insert from firefox
> > or other places.
> > 
> > > If none of the above lets you solve your problem yet, what does the
> > > following command say:
> > >
> > >   $ xterm -report-xres
> > >
> > > In an xterm started that way, does the compose key work?
> > > Both with the character you want and with U+00E5 A RING?
> > 
> > Ugh. xterm says:
> > 
> > xterm: bad command line option "-report-xres"
> > 
> > I forgot to report maybe an important piece of information. I use scim
> > to type in Chinese. I use the default xdm. Here is my .xsession:
> > 
> > export LC_CTYPE=en_US.UTF-8
> > 
> > export XMODIFIERS=@im=SCIM
> > export GTK_IM_MODULE="scim"
> > export QT_IM_MODULE="scim"
> > scim -d
> > 
> > setxkbmap -layout us -variant dvp -option compose:ralt
> > 
> > exec dbus-launch /usr/X11R6/bin/fvwm
> > 
> > I was going to ask my questions one by one so that I will not flood
> > the email list with all my questions. But the scim question is the
> > following.
> > 
> > Quite the opposite of my compose key problem, I am not able to
> > activate scim (by ctrl + space) on normal GUI programs (firefox,
> > libreoffice, xpdf, keepassxc, emacs-gtk etc).
> > 
> > But but but, I am able to activate scim on xterm and type Chinese there.
> > 
> > So I have actually been typing æ, ø, å in firefox and copy back to
> > xterm and typing Chinese using scim on xterm and copy back to firefox
> > / libreoffice for like more than half a year I had this problem on
> > OpenBSD 6.5 too (I was using OpenBSD like 10 years ago for some time
> > and also in between in the past ten years. I went back, last year, to
> > OpenBSD... Was using NetBSD even longer time ago and started using
> > unix-like system around 2001 or 2002). But I did not have this
> > type of scim / compose key problems on Debian, NixOS, Arch Linux, or
> > Void Linux, which are the Linux distributions that I used in the
> > recent years.
> > 
> > Good morning, by the way!
> > 
> > Yours sincerely,
> > Xianwen
> 
> -- 
> Nils Ola Nilsson,  email nils...@abc.se, tel +46-70-374 69 89



-- 
Nils Ola Nilsson,  email nils...@abc.se, tel +46-70-374 69 89


signature.asc
Description: PGP signature


Re: setxkbmap cannot completely set compose key

2020-02-19 Thread NilsOla Nilsson
We had the same problem in this thread:
https://marc.info/?l=openbsd-misc=156352002210168=2

It is working fine for me now, so I can't reproduce it.

/NilsOla


On Thu, Feb 20, 2020 at 06:03:53AM +, Xianwen Chen (陈贤文) wrote:
> Dear Ingo,
> 
> Danke!
> 
> On 2/19/20, Ingo Schwarze  wrote:
> > Just to make sure it worked, could you please show the output of:
> >
> >$ setxkbmap -query
> 
> The output is:
> 
> rules:  base
> model:  pc105
> layout: us
> variant:dvp
> options:compose:ralt
> 
> > What exactly do you mean by "not able to use"?
> > If, while xterm is in focus, you press and relese the compose key,
> > then press and release the first key, then press and release the
> > second key, then press and release some latin letter key, what
> > exactly happens after each step?
> 
> To type for example ø, I press and release the compose key, then press
> and release the / key, and then press and release the o key. I get
> /o
> on xterm, but ø on firefox.
> 
> > Guessing blindly, the problem might be that while firefox finds a font
> > to display the character, xterm does not.  Or that you have changed
> > your xterm configuration in some way that disables UTF-8 (it is on
> > by default).  Can you please retry in xterm with a different character
> > that can be displayed in xterm out of the box, say U+00E5 LATIN
> > SMALL LETTER A WITH RING ABOVE?  What happens if you type and release
> > ralt, then a, then a, then x?
> 
> xterm can display å too, when I copies it using shift+insert from
> firefox or other places.
> 
> xterm can display ø when I copies it using shift+insert from firefox
> or other places.
> 
> > If none of the above lets you solve your problem yet, what does the
> > following command say:
> >
> >   $ xterm -report-xres
> >
> > In an xterm started that way, does the compose key work?
> > Both with the character you want and with U+00E5 A RING?
> 
> Ugh. xterm says:
> 
> xterm: bad command line option "-report-xres"
> 
> I forgot to report maybe an important piece of information. I use scim
> to type in Chinese. I use the default xdm. Here is my .xsession:
> 
> export LC_CTYPE=en_US.UTF-8
> 
> export XMODIFIERS=@im=SCIM
> export GTK_IM_MODULE="scim"
> export QT_IM_MODULE="scim"
> scim -d
> 
> setxkbmap -layout us -variant dvp -option compose:ralt
> 
> exec dbus-launch /usr/X11R6/bin/fvwm
> 
> I was going to ask my questions one by one so that I will not flood
> the email list with all my questions. But the scim question is the
> following.
> 
> Quite the opposite of my compose key problem, I am not able to
> activate scim (by ctrl + space) on normal GUI programs (firefox,
> libreoffice, xpdf, keepassxc, emacs-gtk etc).
> 
> But but but, I am able to activate scim on xterm and type Chinese there.
> 
> So I have actually been typing æ, ø, å in firefox and copy back to
> xterm and typing Chinese using scim on xterm and copy back to firefox
> / libreoffice for like more than half a year I had this problem on
> OpenBSD 6.5 too (I was using OpenBSD like 10 years ago for some time
> and also in between in the past ten years. I went back, last year, to
> OpenBSD... Was using NetBSD even longer time ago and started using
> unix-like system around 2001 or 2002). But I did not have this
> type of scim / compose key problems on Debian, NixOS, Arch Linux, or
> Void Linux, which are the Linux distributions that I used in the
> recent years.
> 
> Good morning, by the way!
> 
> Yours sincerely,
> Xianwen

-- 
Nils Ola Nilsson,  email nils...@abc.se, tel +46-70-374 69 89


signature.asc
Description: PGP signature


Re: [sh] Single quote in comment withing subshell buggy

2019-12-14 Thread NilsOla Nilsson
On Sat, Dec 14, 2019 at 09:03:26AM +, cho...@jtan.com wrote:
> Richard Ulmer writes:
> > Hi,
> > when there is a single ' in a comment within a subshell, I get this
> > error: foo[6]: no closing quote
> >
> > Here is an example script to reproduce the problem:
> >
> > foo=$(
> > # It's bar:
> > echo bar
> > )
> > echo $foo
> 
> This is certainly not the best way to do this but it does the job:
> 
> ~/src/ksh   [OpenBSD 6.6]
> [ksh]flask@void$ /bin/ksh
> void$ foo=$(
> >   # quote: '
> >   echo bar
> > )
> > ^D
I think a better way would be to use UTF-8 single
quote, For example codepoint 8217 ”RIGHT SINGLE
QUOTATION MARK”
foo=$(
#It’s bar:
echo bar
)
-- 
Nils Ola Nilsson,  email nils...@abc.se 


signature.asc
Description: PGP signature


Re: Patch suggestion for sysupgrade

2019-11-14 Thread NilsOla Nilsson
I have upgraded a machine where /home was NFS-mounted,
like this:
- check that the / partition has space for the files
  that will populate /home/_sysupgrade
- unmount /home
- comment ut the /home line in /etc/fstab
- upgrade with sysupgrade
- restore the line in /etc/fstab
- mount -a

All this could be done remote.

Note that I can log in to a user where the home
directory is not NFS-mounted, in our case
/local_home/

On Thu, Nov 14, 2019 at 03:01:18PM +0100, Raimo Niskanen wrote:
> The use case for this patch is that in our lab network we have NFS
> automounted /home/* directories, so using /home/_sysupgrade
> for sysupgrade does not work.
> 
> With this patch it is easy to modify /usr/sbin/sysupgrade and change
> just the line SETSDIR=/home/_sysupgrade to point to some other local file
> system that is outside hier(7) for example /opt/_sysupgrade
> or /srv/_sysupgrade.
> 
> Even using /var/_sysupgrade or /usr/_sysupgrade should work.  As far as
> I can tell the sysupgrade directory only has to be on a local file system,
> and not get overwritten by the base system install.
> 
> The change for mkdir -p ${SETSDIR} is to make the script more defensive about
> the result of mkdir, e.g in case the umask is wrong, or if the directory
> containing the sysupgrade directory has got the wrong group, etc.
> 
> 
> A follow-up to this patch, should it be accepted, could be to add an option
> -d SysupgradeDir, but I do not know if that would be considered as a too odd
> and error prone feature to merit an option.  Or?
> 
> The patch is on 6.6 stable.
> 
> Index: usr.sbin/sysupgrade/sysupgrade.sh
> ===
> RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v
> retrieving revision 1.25
> diff -u -u -r1.25 sysupgrade.sh
> --- usr.sbin/sysupgrade/sysupgrade.sh 28 Sep 2019 17:30:07 -  1.25
> +++ usr.sbin/sysupgrade/sysupgrade.sh 14 Nov 2019 13:27:34 -
> @@ -119,6 +119,7 @@
>   URL=${MIRROR}/${NEXT_VERSION}/${ARCH}/
>  fi
>  
> +[[ -e ${SETSDIR} ]] || mkdir -p ${SETSDIR}
>  if [[ -e ${SETSDIR} ]]; then
>   eval $(stat -s ${SETSDIR})
>   [[ $st_uid -eq 0 ]] ||
> @@ -127,8 +128,6 @@
>ug_err "${SETSDIR} needs to be owned by root:wheel"
>   [[ $st_mode -eq 040755 ]] || 
>   ug_err "${SETSDIR} is not a directory with permissions 0755"
> -else
> - mkdir -p ${SETSDIR}
>  fi
>  
>  cd ${SETSDIR}
> @@ -185,7 +184,7 @@
>  
>  cat <<__EOT >/auto_upgrade.conf
>  Location of sets = disk
> -Pathname to the sets = /home/_sysupgrade/
> +Pathname to the sets = ${SETSDIR}/
>  Set name(s) = done
>  Directory does not contain SHA256.sig. Continue without verification = yes
>  __EOT
> @@ -193,7 +192,7 @@
>  if ! ${KEEP}; then
>   CLEAN=$(echo SHA256 ${SETS} | sed -e 's/ /,/g')
>   cat <<__EOT > /etc/rc.firsttime
> -rm -f /home/_sysupgrade/{${CLEAN}}
> +rm -f ${SETSDIR}/{${CLEAN}}
>  __EOT
>  fi
> 
> Best regards
> --  
> / Raimo Niskanen, Erlang/OTP, Ericsson AB

-- 
Nils Ola Nilsson, email nils...@abc.se, tel +46-70-374 69 89


signature.asc
Description: PGP signature


Re: When will OpenBSD become a friendly place for bug reporters?

2019-07-19 Thread NilsOla Nilsson
On Sat, Jul 13, 2019 at 03:47:53PM +0200, Ingo Schwarze wrote:
> Hi NilsOla,
> 
>  On 2019-07-11, Ingo Schwarze  wrote:
> 
> >>> I just did
> >>>   cd /usr/xenocara/app/xterm/
> >>>   cvs up -dP
> >>>   make clean
> >>>   make obj
> >>>   make
> >>>   doas make install
> >>> and now compose works again for me in xterm, too.
> >>> 
> >>> I have no idea what was going on.  I often have patches lying around
> >>> in my tree for diverse testing purposes, though i fail to remeber
> >>> anything in particular in xterm(1) lately, and there are no patches
> >>> there now.  Anyway, sorry for the noise.
> >>> 
> >>> To the other poster who reported problems with compose in xterm:
> >>> Can you try updating and recompiling xterm as shown above,
> >>> and does that help for you, too?
> 
> >> It works for mee too. 
> >> So, the xterm distributed in current is not the same
> >> as in the source tree? Just asking.
> 
> I don't know.  It sounds as if this aspect of xterm(1) was briefly
> broken in at least one snapshot about three weeks ago.  But i don't
> know why, i see no plausible reason.  Nothing was committed to xterm
> for four months, and i don't recall hearing about uncommitted xterm
> patches in snapshots either.
> 
> > It works also for one xterm that was started before the
> > reinstall.
> 
> Now that's very weird.  It doesn't for me.  I still have some old
> xterm binaries running, and compose still doesn't work in those,
> in the way i described, while it does work in xterms that i start
> now using the freshly recompiled /usr/X11R6/bin/xterm.

Of the xterms started before the reinstall it works
only for the one were i run the reinstallation. 

BTW I have one other machine with openbsd 6.5 stable, and
there it seems to work from the beginning

Yours 
NilsOla

-- 
Nils Ola Nilsson,  email nils...@abc.se, tel +46-70-374 69 89


signature.asc
Description: PGP signature


Re: When will OpenBSD become a friendly place for bug reporters?

2019-07-13 Thread NilsOla Nilsson
On Sat, Jul 13, 2019 at 07:51:33AM +0200, NilsOla Nilsson wrote:
> On Fri, Jul 12, 2019 at 08:14:06PM +0200, Ingo Schwarze wrote:
> > Hi Christian,
> > 
> > Christian Weisgerber wrote on Fri, Jul 12, 2019 at 05:48:37PM -:
> > > On 2019-07-11, Ingo Schwarze  wrote:
> > 
> > >> Quite likely.  I'm so clueless that right now, i can't even seem to get
> > >> Compose to work even though i'm sure i had it working in the past.
> >  
> > > I use "setxkbmap -option compose:ralt" and compose works as expected
> > > for me in xterm.
> > 
> > Thanks for mentioning that.
> > 
> > I just did
> > 
> >   cd /usr/xenocara/app/xterm/
> >   cvs up -dP
> >   make clean
> >   make obj
> >   make
> >   doas make install
> > 
> > and now compose works again for me in xterm, too.
> > 
> > I have no idea what was going on.  I often have patches lying around
> > in my tree for diverse testing purposes, though i fail to remeber
> > anything in particular in xterm(1) lately, and there are no patches
> > there now.  Anyway, sorry for the noise.
> > 
> > To the other poster who reported problems with compose in xterm:
> > Can you try updating and recompiling xterm as shown above,
> > and does that help for you, too?
> 
> It works for mee too. 
> So, the xterm distributed in current is not the same
> as in the source tree? Just asking.

It works also for one xterm that was started before the
reinstall.
> 
> /NilsOla
> -- 
> Nils Ola Nilsson,  email nils...@abc.se, tel +46-70-374 69 89



-- 
Nils Ola Nilsson,  email nils...@abc.se, tel +46-70-374 69 89


signature.asc
Description: PGP signature


Re: When will OpenBSD become a friendly place for bug reporters?

2019-07-12 Thread NilsOla Nilsson
On Fri, Jul 12, 2019 at 08:14:06PM +0200, Ingo Schwarze wrote:
> Hi Christian,
> 
> Christian Weisgerber wrote on Fri, Jul 12, 2019 at 05:48:37PM -:
> > On 2019-07-11, Ingo Schwarze  wrote:
> 
> >> Quite likely.  I'm so clueless that right now, i can't even seem to get
> >> Compose to work even though i'm sure i had it working in the past.
>  
> > I use "setxkbmap -option compose:ralt" and compose works as expected
> > for me in xterm.
> 
> Thanks for mentioning that.
> 
> I just did
> 
>   cd /usr/xenocara/app/xterm/
>   cvs up -dP
>   make clean
>   make obj
>   make
>   doas make install
> 
> and now compose works again for me in xterm, too.
> 
> I have no idea what was going on.  I often have patches lying around
> in my tree for diverse testing purposes, though i fail to remeber
> anything in particular in xterm(1) lately, and there are no patches
> there now.  Anyway, sorry for the noise.
> 
> To the other poster who reported problems with compose in xterm:
> Can you try updating and recompiling xterm as shown above,
> and does that help for you, too?

It works for mee too. 
So, the xterm distributed in current is not the same
as in the source tree? Just asking.

Thanks for the help!

/NilsOla
-- 
Nils Ola Nilsson,  email nils...@abc.se, tel +46-70-374 69 89


signature.asc
Description: PGP signature


Re: When will OpenBSD become a friendly place for bug reporters?

2019-07-11 Thread NilsOla Nilsson
I am using cwm and ksh and at present my compose key
work in st and in gvim, but not in xterm.
I am on current updated a few weeks ago.

/NilsOla

On Thu, Jul 11, 2019 at 09:18:41PM +0200, Ingo Schwarze wrote:
> Hi Ian,
> 
> ropers wrote on Thu, Jul 11, 2019 at 12:41:45AM +0200:
> 
> > While I'm personally only or mainly interested in Alt+numeric input,
> > if altnumd existed, it would probably be comparatively easy to then
> > extend it and add support for Alt+u thru Alt+u10, with the U
> > becoming a reserved keyword unambiguously signifying that what follows
> > will be a Unicode code point between U+ and U+10.
> 
> There is no reason to make it different.  ASCII is a subset of Unicode,
> with the same numbering.  So the "U" looks redundant to me.
> 
> > There's a huge competence gap between us,
> 
> Quite likely.  I'm so clueless that right now, i can't even seem to get
> Compose to work even though i'm sure i had it working in the past.
> This is on amd64-current, inside xterm(1) and ksh(1):
> 
>$ locale
>   LANG=
>   LC_COLLATE="en_US.UTF-8"
>   LC_CTYPE="en_US.UTF-8"
>   LC_MONETARY="en_US.UTF-8"
>   LC_NUMERIC="en_US.UTF-8"
>   LC_TIME="en_US.UTF-8"
>   LC_MESSAGES="en_US.UTF-8"
>   LC_ALL=en_US.UTF-8
>$ setxkbmap -query -v -v -v 
>   Setting verbose level to 8
>   locale is en_US.UTF-8
>   Trying to load rules file ./rules/base...
>   Trying to load rules file /usr/X11R6/share/X11/xkb/rules/base...
>   Success.
>   Applied rules from base:
>   rules:  base
>   model:  pc105
>   layout: de
>   Trying to build keymap using the following components:
>   keycodes:   xfree86+aliases(qwertz)
>   types:  complete
>   compat: complete
>   symbols:pc+de+inet(pc105)+terminate(ctrl_alt_bksp)
>   geometry:   pc(pc105)
>   rules:  base
>   model:  pc105
>   layout: de
> 
> At this point, the caps key toggles caps lock, i.e. pressing
> 
>   caps a caps a
> 
> results in the input "Aa".
> 
>$ setxkbmap -option compose:caps -v -v -v   
>   Setting verbose level to 8
>   locale is en_US.UTF-8
>   Trying to load rules file ./rules/base...
>   Trying to load rules file /usr/X11R6/share/X11/xkb/rules/base...
>   Success.
>   Applied rules from base:
>   rules:  base
>   model:  pc105
>   layout: de
>   options:compose:caps
>   Trying to build keymap using the following components:
>   keycodes:   xfree86+aliases(qwertz)
>   types:  complete
>   compat: complete
>   symbols:pc+de+inet(pc105)+terminate(ctrl_alt_bksp)+compose(caps)
>   geometry:   pc(pc105)
> 
> Now, the caps key no longer toggles caps lock and becomes a dead key,
> i.e. pressing
> 
>   caps , c caps " a
> 
> results in the input "ca".  However, the resulting input is really
> ASCII-c ASCII-a rather than the expected c-cedille a-umlaut.
> It looks like Compose works well enough to discard the , and ",
> but not well enough to actually generate non-ASCII characters.
> 
> Somewhat grumpy today,
>   Ingo

-- 
Nils Ola Nilsson,  email nils...@abc.se, tel +46-70-374 69 89


signature.asc
Description: PGP signature