Re: [gentoo-user] Re: How to set size to windows in Openbox in local config [SOLVED]

[Floyd Anderson]

On Fr, 21 Apr 00:12:28 +0200
Miroslav Rovis <miro.rovis@××××××××××××××.hr> wrote:
>On 170420-05:57+0200, Floyd Anderson wrote:
>> On Do, 13 Apr 21:55:29 +0200
>> Miroslav Rovis <miro.rovis@××××××××××××××.hr> wrote:
>...
>> >
>> >But I forgot floyd has got a "patch to keep the window position while
>> >resizing the font" and offered it:
>> >
>> >https://marc.info/?l=gentoo-user&m=149205691530349&w=2
>...
>>
>> Hi Miroslav,
>>
>> back from some computer-free holidays,
>I hope you had good and restful time!
Yes, thanks, it was like that and I had better stay there because after 
an update yesterday, xorg-server kills my last nerve while I am fighting 
with a "Segmentation fault at address 0x0" server error. :-(

>> The patch is too unimportant to solve some/all of the above issues
>> and/or bloating up the urxvt extension script. And additionally,
>> rxvt-unicode won’t and doesn’t expose all Xlib functions (such as
>> XGetWindowAttributes) in urxvtperl, the embedded perl interpreter. So it
>$ man urxvtperl # but how cryptic!, how long study that will be... I don't
>                  have all those hours right now...
>                  I hope I'll find a solution with less time to invest,
>                  else...
Yes it needs investigation. That was the reason why I does not realise 
firstly, that the changes to my local font-size extension script were 
made by me (as I mentioned in an earlier reply). I could not believe 
that I spend my time to those cryptic stuff (have not used Git for this 
in the past, which had simply shown myself as the author). 

>> My used and tested urxvt-font-size related Xresource settings:
>> 	URxvt.font-size.keepwin:	true
>> 	URxvt.font-size.step:		4
>> 	URxvt.keysym.C-0xffad:		font-size:decrease
>> 	URxvt.keysym.C-0xffab:		font-size:increase
>> 	URxvt.keysym.C-0xffb0:		font-size:reset
>>
>> Since I use the default keysyms for font-size:{decrease,increase,reset}
>> in Vim, I changed those defaults to C-KP_Substract (C-0xffad), C-KP_Add
>> (C-0xffab), C-KP_0 (C-0xffb0) like in Firefox and others.
>I don't get what these are. Not at this time. And this is my second
>reading of your email...
>
>NOTE (at proofreading): Is that 'C-KP_Substract' should read
>'C-KP_Subtract'?, the "-" on the keypad? So 'C-KP_Subtract' means
>Ctrl-<minus>?, and C-KP_0 means Ctrl-0?
Sorry, I was not quite verbose about this. Yes your are right, the "C" 
means control key and "KP" stands for keypad. Normally you can use those 
identifier directly in the keysym definitions but those for keypad keys 
does not work for me, so I used their hexadecimal keycode equivalents. 
You can find the keycodes with the command `xev` or by looking in the 
header file "/usr/include/X11/keysymdef.h" near line 202.

>I also compared what I have currently installed:
>
># eix urxvt-font-size
>[I] x11-misc/urxvt-font-size
>     Available versions:  1.1 **9999
>     Installed versions:  1.1(13:07:28 22/02/15)
>     Homepage:            https://github.com/majutsushi/urxvt-font-size/
>     Description:         Perl extension for rxvt-unicode to change the font size on the fly
>
>#
>
># qlist urxvt-font-size
>/usr/lib64/urxvt/perl/font-size
>/usr/share/doc/urxvt-font-size-1.1/README.markdown.bz2
>#
>
>[I compared what I have currently installed] with the 9999 version, which
>is the version that, IIUC, I plan to hopefully try and patch with your
>patch...
Cannot figure out what IIUC is but anyway. Patching will fail with the 
v1.1-tag commit (two years, four month old).

I would recommend not to hassle portage with those tiny installs (at 
least on a single user machine). Simply tell rxvt-unicode where it can 
find your additionally extension script(s) by using for instance:
    URxvt.perl-lib: $HOME/.config/urxvt/ext

in your Xresource file for rxvt-unicode. Have a look at urxvt(1) manual 
for more alternatives. I see only one disadvantage, you have to apply 
the patch manually but only once if you are using a local Git repo (as 
you do and mentioned in your reply).

>> [2] <https://archives.gentoo.org/gentoo-user/message/a4d58e993934aa4a273998eda030d115>
>The link that Savchenko gave in that email is puzzling me:
>http://rcr.io/words/dynamic-xterm-colors.html
>I want to try and figure out that bash script there... It's very
>educational.
>
>I need more time to study this. […]
Not necessary if you rarely use it (in my opinion) but always good to 
known that it is there when you need it. Becomes probably very handy 
e.g. for terminal prompt designs, window titling or:
  - quickly change/test fonts, where <type> is one of {710..713} which
    stands for regular, bold, italic, bold-italic and <font> something
    like 9x15, fixed or xft:termminus-12 and so on.
    $ printf '\e]%s;%s\007' "<type>" "<font>"
  - query RGB colour values, where <colournumber> is one of {0..255}
    $ echo -ne "\033]4;<colournumber>;?\007"
  - window sizing/positioning (e.g. 1144x954+0+0 bound to Ctrl+F11) in
    urxvt. Did you remember the syntax? :-)
    URxvt.keysym.C-F11: command:\033[4;1144;954t\033[3;0;0t
  - ...

> […] But I do have a question:
>
>I read, somewhere, spender (the author of grsecurity) wrote it, but I
>don't recall the entire context, and so I can only vaguely paraphrase
>what I remember he wrote, that... Aaargh, can't remember well at all...
>I think it wasn't about perl only, or perl wasn't even mentioned
>explicity, but it was spender saying how running scripts by using stuff
>like:
>
>#!/usr/bin/env [perl|python|...]
>(
>in the new script it's
>#!/usr/bin/env perl
>)
Yes, with commit 83da253a7946c85d65fbf9c3a983bd6ef51420aa the explicit 
path declaration for perl was removed.

>instead of the more simple, traditional shebang line:
>
>#!/usr/bin/<interpreter> # perl or python or bash
>
>(
>in the old script it's
>#!/usr/bin/perl
>)
>
>that the former (...env <interpreter>) is not as safe as the latter
>(...bin/<interpreter>).
>
>Why was it necessary to introduce that change? I'm referring to Jan's
>change, of course.
>
>It can't be it does not bring a tiny bit more into the attack surface,
>can it?
I do not think so. It is probably rather a portability related decision. 
Have a look at a blog post by Michał Górny [1] for some light on this.

>And my plan is... Probably bump the ebuild into my custom overlay, as I
>don't install online from git (until it becomes possible to verifiably
>install packages while online, I mean: for non-experts like me; it is
>possible to verifiably install packages with the old webrsync, also
>while online...; OTOH app-crypt/gkeys that Savchenko recommended to me
>in an email a month or two ago to try and test, those do bring in
>more verifiability when installing from git, but I haven't found time to
>study gkeys yet...)
Same here. I does not knew app-crypt/gkeys previously and it sounds very 
interesting. It is totally overdue nowadays to have something like that 
for the rsync protocol.

>[And my plan is... Probably bump the ebuild into my custom overlay,]
>modify it to get the git source served from my local Apache cgit repo
>[1] (and urxvt-font-size package is not even PGP-signed, neither tags
>nor commits, which is always an important feature missing with the code,
>for me...)
Maybe a kindly request upstream for signed tags may change this.

>[modify it to get the git source from my local Apache cgit repo], put
>your patch in /etc/portage/patches/x11-misc/urxvt-font-size/ check that
>my /etc/portage/bashrc is ready to apply user patches (I recently
>updated it as per the wiki page, gave the link in another email a couple
>of days ago, to this list, yeah, it was in the non-replied-to message to
>Ian Zimmermann in a 2 emails --so far-- thread split from this one...
>which was about window positions as well!... [2]), and...
>
>...And emerge it:
>
># emerge urxvt-font-size
>
>Courious to read what your opinion is on usage of /env vs plain /bin
>scripts security-wise, as I put it further above! And why that change...
>
>Regards!
>---
>[1]  I have actually learned when installing gnunet from
>     youbroketheinternet-overlay just two days ago that I probably can
>     use local overlay even without seving it with cgit and Apache,
>     simply from local filesystem!
>
>[2]  openbox window positions
>     https://lists.gt.net/gentoo/user/325342
>     (and my reply to it contains digressions, but also simple
>     questions...)
>
Your plan with the Apache cgit repo seems to be a nice challenge to 
learn something but as I noted above, creating and maintaining an 
overlay for so tiny things is a little bit overkill in my opinion. 
Fetching the related Git repository from time to time and you are done 
while an overlay needs probably more significant work.

As an example, I am currently just imagine I have to create overlays for 
my favourite Vim plugins instead of using well known manager like 
Vundle, NeoBundle, Dein or what else. That were a lot of work for the 
overlay solution or did I miss the point?


References:
[1] <https://blogs.gentoo.org/mgorny/2016/02/08/a-quick-note-on-portable-shebangs/>

-- 
Regards,
floyd