Re: [lmi] konsole clipboard stopped working (fixed)

[Greg Chicares]

On 2017-11-02 13:04, Vadim Zeitlin wrote:
> On Thu, 2 Nov 2017 12:40:19 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> I'm really glad I took the time to port and document the
> GC> scripts in
> GC>   http://git.savannah.nongnu.org/cgit/lmi.git/tree/tabs
> 
>  I couldn't help looking at those scripts

I'm very glad to have your comments.

> and I wonder about the use of
> "git remote update" at
> http://git.savannah.nongnu.org/cgit/lmi.git/tree/tabs/1/startup_script#n6
> What is it for?

Here's the history:

$git log --patch -G'remote' gwc/develop1.txt
[...]
-svn status --show-updates
-svn update
+git remote -v update
+git pull

Back in svn days, I ran
  svn status --show-updates
unconditionally whenever I started up a group of terminal sessions
(on average, once or twice a day with cygwin in an ever-crashing VM),
because it was a relatively lightweight way to ascertain whether
there were any savannah changes that had not yet been reflected in
my local mirror. The 'svn update' command was run not at startup,
but only on demand--partly because it's more resource-intensive,
and partly because other people were changing the svn repository
more often than is now the case and I wanted to keep their changes
out of my local mirror until I had reviewed them.

Those concerns are certainly less important nowadays, and perhaps
completely irrelevant, but rather than rethink the commands, I
just translated them.

>  And while I was writing this, I received the email about your commit
> 3df3e622be691da20f5a38dcd19700b0f62998f3 ("Synchronize more than one recent
> commit to local mirror") which addresses my other question. However I still
> question the use of HEAD~5 in the script, might you really want to use
> address@hidden, i.e. the previous value of the HEAD pointer before it was 
> changed
> by the subsequent command (git pull) instead?

I had no idea that any such syntax as 'address@hidden' existed. But now,
comparing 'git reflog' in my working copy vs. my mirror, I see that
it does exactly what I want, so I'll update 3df3e62. Thanks.

BTW, running 'touch' only on files that have actually changed did
save a few noisy seconds when I was using a HDD, but with an SSD it
doesn't matter much if I just touch everything:

$time (for z in * ; do touch --reference=/opt/lmi/src/lmi/$z $z; done)
( for z in *; do; touch --reference=/opt/lmi/src/lmi/$z $z; done; ) \
 0.04s user 0.25s system 25% cpu 1.146 total

Still, having written a selective, resource-saving command, it seems
a sin not to use it, even though it probably saves less SSD wear than
a single invocation of 'make install' causes.

> GC> These scripts are clunky, but tiny and comprehensible, so I prefer them
> GC> to tmux or gnu screen.
> 
>  FWIW screen is pretty similar

Yet screen's HTML manual is 352Kb and it has
  https://savannah.gnu.org/bugs/?group=screen
237 open defects. Sure, screen and tmux would let me show multiple
text windows, but I can comfortably see only 24x80 anyway, so I
always work with a single maximized window anyway.

> [...] And it allows
> you to give specific numbers and titles to the different windows, which is
> not the case of your scripts AFAICS.

Actually, my tabs are named {ONE TWO THREE FOUR FIVE}, as set by the
"title:" field on each line of 'tabs/konsole_tabs'. But since I'm
working in this directory anyway, {Mirror Commit Build Misc Test}
seem slightly more evocative...so I'll commit that change without
testing because, hey, this is konsole, so what could go wrong?

> GC> There is one question I'd like to ask, though. My habit is to
> GC> run schroot with identical parameters in each of approximately
> GC> five terminal tabs. That seems to work perfectly well, but is
> GC> it distasteful for some reason that I'm not perceiving?
> 
>  No, I don't think so. There is no real overhead in using chroot, i.e.
> launching N chroot'ed processes shouldn't be materially different from
> launching N processes inside a chroot.

Okay, thanks, that's good to know--I've been meaning to ask you
about this for some time.

>  I probably still would use a single chroot and just launch a screen inside
> it because I absolutely always use screen anyhow (if only not to lose my
> session in case of disconnection/closing the window/anything else short of
> reboot -- but this should never happen, of course, see above).

My guess is that every 100th 'apt-get upgrade' requires restarting konsole,
which is the worst terminal emulator except for every other.

> And using a
> single screen inside a chroot just seems more logical as it ensures that
> all windows inside it have the same filesystem view while it could be
> possible to accidentally mix up chrooted and not-chrooted processes
> otherwise.

I have one xfce workspace for host and one for chroot. And using
'konsole_tabs' to set up all chroots ensures that they all have the
same filesystem view. Since I've settled on this setup, I don't even
have to do 'ls -di /' anymore ('ischroot' being unreliable) to know
where I am.

Thanks for your comments. I knew I'd learn something useful.