koldfront

diva: Random signature generator in Haskell #amiga #computers #email #gnus #haskell #perl

Back in the days of FidoNet a lot of people created ARexx scripts for GCCHost, and later EMS, on our Amiga computers to generate random signatures at the end of our Echomail.

When moving to "real" email and usenet, this feature was of course not abandoned. I've been using two small Perl-scripts, one that selects a random signature from a list of signatures, and another that formats it, to include my name and email address for years.

I reported a bug and suggested an enhancement of the Text::Autoformat-module, I used for formatsig, in 2000, only later to recognize the positive reply coming from one of the "famous" Perl-programmers, Damian Conway - cool!

When I switched to a new laptop recently, I took it as an opportunity to leave behind some of the accumultated cruft and wean myself off some old habits. For instance, I haven't installed wajig (yet), and I also left behind the auto-signature scripts, because they sometimes didn't format correctly, and I didn't want to debug them.

But I still want to change my signature randomly, so I challenged myself to implement a randomizer and formatter in Haskell. The result is diva.

It is a very simple program, you need a file with signatures in ~/.sigs, and you call diva with two command line parameters, your name, and your email-address. diva then prints out a randomly chosen, formatted signature for you, which you can redirect into ~/.signature, where your email-program and/or newsreader will pick it up. I have integrated a call to it into message-signature-setup-hook in Gnus, so I get a new random signature for each message I write.

 (0 comments)

Choosing what program to open what file; mailcap.order #debian

Configuring what program to use to open what file is quite straight forward: Edit /etc/mailcap.order, run update-mime.

Only problem is, when I did that, I got:

  Warning: package evince listed in /etc/mailcap.order does not have mailcap entries.

The man-page for mailcap.order helpfully says: "Remember that this files [sic] takes package names and not executable names."

But, the command "evince" comes in the package called "evince", so I assumed the "package name" was "evince". That holds for "eog", which comes in the package "eog", and is also a GNOME application, as far as I know, and which update-mime doesn't complain about.

Oh well, strace -e openat to the rescue, and - hey presto - it turns out the "package name" for evince is "org.gnome.Evince". I plopped that into mailcap.order, and now Bob's my uncle. Nice to know.

 (0 comments)

Perl 5.30 - oh my #perl

I like this:

Declarations such as my $x if 0 are no longer permitted.

- What's new in Perl 5.30.0

 (0 comments)

Dear Signal #community #free software #programming #vcs

Signal logo Please provide a useful changelog in your signal-desktop Debian package.

The previous package broke the application, today apt(8) fetched a new package, and the complete changelog reads:

signal-desktop (1.27.2) whatever; urgency=medium
 
  * Package created with FPM.
 
 -- Open Whisper Systems <support@signal.org>  Fri, 06 Sep 2019 15:36:44 -0700

That is useless. The changelog should provide, at minimum, a summary of the changes between this version and the previous one.

Thank you.

 (0 comments)

Hosts sending 2 or 6 NULL bytes #net

Recently, like the last month or so, my server has been receiving packets from various, seemingly arbitrary, hosts, containing either 2 or 6 NULL bytes.

They hit mostly port 22 (ssh), 53 (dns), 80 (http), 443 (https) and imaps (993). I only have a very limited number of ports open in the router, so they might be hitting more ports.

Looking at them with ngrep(8), it looks like this:

$ sudo ngrep -x -q '^\x00\x00*$'
interface: enp4s0 (192.168.1.0/255.255.255.0)
filter: ((ip || ip6) || (vlan && (ip || ip6)))
match: ^\x00\x00*$
 
T 88.208.41.159:42560 -> 192.168.1.101:22 [S] #32
  00 00                                                 ..
 
T 78.140.142.55:44230 -> 192.168.1.101:80 [S] #41
  00 00                                                 ..
 
T 78.140.141.247:47152 -> 192.168.1.101:53 [S] #46
  00 00                                                 ..
 
T 5.11.81.197:48256 -> 192.168.1.101:443 [S] #62
  00 00                                                 ..
 
T 54.36.150.116:41070 -> 192.168.1.101:443 [R] #404
  00 00 00 00 00 00                                     ......

I'm not quite sure to make of it. The sources seem to change, sometimes they're mostly from Japan, sometimes from China, sometimes from AWS, other times from various hosting companies.

Anyone know what this is?

 (0 comments)

rdiff-backup backport to Debian 11 (buster) #debian

A new version of rdiff-backup, 1.3.3, has been added to Debian unstable.

When that is used to backup to a machine running Debian 11 (buster), you get errors, because it has version 1.2.8.

As a work-around, I have backported librsync-dev and rdiff-backup from unstable to Debian 11 (buster), packages are in my local repository. Use at your own peril.

 (0 comments)

Making subprocess.Popen in Python 3 play nice with "elaborate" output #programming #python

docker-compose produces "elaborate" output when run, making use of carriage returns and ANSI CSI codes to move the cursor about.

A wrapper script written in Python 3 tried to handle the output - printing a '.' for each line usually, and actually printing the lines if given a --verbose option.

Unfortunately the output with --verbose got mangled, which really annoyed me. So I tried to find a solution.

Here is a small script that does some output, mimicking the stuff that docker-compose outputs. Note that we want the lines printed as they are produced, and not all at once at the end of the script.

command.py:

#!/usr/bin/python3
 
from time import sleep
 
print("1", flush=True)
sleep(1)
print("2", flush=True)
sleep(1)
print("3", flush=True)
sleep(1)
 
print("\x1b[2A\x1b[K\r", end="", flush=True)
sleep(1)
print("2 - let's go\r", end="", flush=True)
sleep(1)
print("2 - lookin' good\r", end="", flush=True)
sleep(1)
print("\x1b[1A\x1b[K\r", end="", flush=True)
sleep(1)
print("1 - abba\r", end="", flush=True)
sleep(1)
print("\x1b[2B\r", end="", flush=True)
sleep(1)
print("\r3 - flappa\r", end="", flush=True)
sleep(1)
print("\x1b[1A\x1b[K\r", end="", flush=True)
sleep(1)
print("2 - done\r", end="", flush=True)
sleep(1)
print("\x1b[1A\x1b[K\r", end="", flush=True)
sleep(1)
print("1 - done\r", end="", flush=True)
sleep(1)
print("\x1b[2B\r", end="", flush=True)
sleep(1)
print("3 - done\x1b[K\r", end="", flush=True)
sleep(1)
print("\nFinito", flush=True)

Try running it:

The original code wrapping it, was like this (slightly simplified):

runner_orig.py:

#!/usr/bin/python3
 
import subprocess
 
 
def run_command():
    p = subprocess.Popen("./command.py",
                         stdout=subprocess.PIPE,
                         stderr=subprocess.STDOUT,
                         universal_newlines=True)  # this converts \r into \n #fail
 
    for line in iter(p.stdout.readline, ""):
        yield line, p.poll()
 
    yield "", p.wait()
 
 
for l, rc in run_command():
    print(l, end="", flush=True)

If you run this, you'll see how the output it mangled:

So why does this happen? Well, the first culprit is universal_newlines=True. That means that any combination of carriage return and/or line feed is interpreted as and converted to a line feed. Uh-oh, definitely not what we want, if the fancy output it to be reproduced as intended.

If set to False, the situation improves, carriage returns are no longer converted. Unfortunately the p.stdout.readline() function only interprets line feeds as end of line and not carriage returns, so all the fancy stuff piles up, and is only shown at the very end. Not what we want.

Looking at the documentation of open() reveals that it has an option called newline, which is used to control how universal newlines are handled, and that if set to '' it actually does what we want: carriage returns are not converted, and they are recognized and line endings.

Unfortunately the documentation of subprocess.Popen() only documents universal_newlines taking two values, True and False, and '' doesn't work. I tried.

Fortunately Klaus had a tip - if you use os.dup(), you can open the file handle again, and - hey - now I can give it the option to open() we need, newline=''.

Lo and behold, it works!

runner_fixed.py:

#!/usr/bin/python3
 
import subprocess
import os
 
def run_command():
    p = subprocess.Popen("./command.py",
                         stdout=subprocess.PIPE,
                         stderr=subprocess.STDOUT,
                         universal_newlines=False)  # \r goes through
 
    nice_stdout = open(os.dup(p.stdout.fileno()), newline='')  # re-open to get \r recognized as new line
    for line in nice_stdout:
        yield line, p.poll()
 
    yield "", p.wait()
 
 
for l, rc in run_command():
    print(l, end="", flush=True)

It is kind of kludgy to have to do that, but it does work:

I wonder why subprocess.Popen() in Python 3 does not have the same options for handling newlines as open() has. It feels like open() has moved on (to the newline parameter), but subprocess.Popen() hasn't followed yet.

 (0 comments)

Archive... Search... Keywords...
Lille langebro

Today

Laust Sonne (45).

Friday

Klaus' first recorded usenet-address (27).

Saturday

Quantum physics (119).

Last men landed on the moon (so far) (47).

Tuesday

Wright brothers took off (116).

Stine Sjørslev Kelså (44).

2019-12-18

Perl 1.000 released (32).

2019-12-20

Apple buys NeXT (23).

2019-12-21

Adams first recorded usenet-address (27).

2019-12-22

Ramanujan (132).

Winter solstice.

2019-12-23

Vincent van Gogh cut off his ear (131).

2019-12-24

Jesus (2018).

2019-12-25

Isaac Newton (377).

2019-12-26

Mary Somerville (239).

Charles Babbage (228).

Sonja Rindom (115).

2019-12-28

Linus Torvalds (50).

0.0169 s
webcustodian@koldfront.dk