f-log

git diff only shows CR character when the second file has CRLF, ignoring the state of the first file*

I find this "strange behaviour" on the part of git diff

create two near-identical files in /tmp

echo -en "a\r\n" > /tmp/file_a_crlf.txt
echo -en "b\r\n" > /tmp/file_b_crlf.txt

The -en allows the CRLF to be written to the file explicitly.

but comparing them with git diff

git diff /tmp/file_a_crlf.txt /tmp/file_b_crlf.txt

What is that ^M there after the +b ?

Well it looks like a Carriage Return encoded for visibility. But both files have a CRLF pair so that should show for both versions or neither?

Let us double check

git diff /tmp/file_a_crlf.txt /tmp/file_b_crlf.txt | cat -v

-v encodes non-visible characters into visible representations.

diff --git a/tmp/file_a_crlf.txt b/tmp/file_b_crlf.txt
index 533790e..485540d 100644
--- a/tmp/file_a_crlf.txt
+++ b/tmp/file_b_crlf.txt
@@ -1 +1 @@
-a^M
+b^M

and does indeed show both files have the same CRLF

---

and just for fun we can

echo -en "c\n" > /tmp/file_c_lf.txt

git diff /tmp/file_a_crlf.txt /tmp/file_c_lf.txt

There is no CR shown there either!

and once again if we pass the output through cat

git diff /tmp/file_a_crlf.txt /tmp/file_c_lf.txt | cat -v

diff --git a/tmp/file_a_crlf.txt b/tmp/file_c_lf.txt
index 533790e..f2ad6c7 100644
--- a/tmp/file_a_crlf.txt
+++ b/tmp/file_c_lf.txt
@@ -1 +1 @@
-a^M
+c

We can see the invisible CR in the first file.

Swap the files over and the opposite is true

git diff /tmp/file_c_lf.txt /tmp/file_a_crlf.txt

git diff /tmp/file_c_lf.txt /tmp/file_a_crlf.txt | cat -v

diff --git a/tmp/file_c_lf.txt b/tmp/file_a_crlf.txt
index f2ad6c7..533790e 100644
--- a/tmp/file_c_lf.txt
+++ b/tmp/file_a_crlf.txt
@@ -1 +1 @@
-c
+a^M

---

(*) I assume this is a Linux or non-windows "feature".

Caused me a massive headache. Seeing the CR in the changed version of files I was working on made me think I had added the CRs by accident.

Instead it was simply that the files had originally been created by a Windows developer.

Claws mail has been bugging me about bogofilter for spam filtering. I just ignore it and assumed it was my fault.

The error referred to the number of learned Spam/Ham was too low.

I get a fair amount of spam and I have a number of rules that junk stuff directly. Anything left over gets marked Spam manually.

bogofilter -V

bogofilter-sqlite version 1.2.5
Database: SQLite 3.38.1

and

bogofilter -Q

bogofilter[29598]: cannot compile SELECT value FROM bogofilter WHERE key=? LIMIT 1;: file is not a database_

Oh. That will be a problem.

Does the file exist?

file .bogofilter/wordlist.db

.bogofilter/wordlist.db: Berkeley DB (Btree, version 9, native byte-order)

It does ... Well, lets fix that :)

mv .bogofilter/wordlist.db .bogofilter/OLD_wordlist.db

bogofilter -Q

bogofilter[29692]: cannot compile SELECT value FROM bogofilter WHERE key=? LIMIT 1;: no such table: bogofilter_

ls -lh

-rw-r--r--  1 rednuht rednuht 4.2M Jul 22  2021 OLD_wordlist.db
-rw-r--r--  1 rednuht rednuht  67M May  2 23:06 wordlist.db

and

file .bogofilter/wordlist.db

.bogofilter/wordlist.db: SQLite 3.x database, last written using SQLite version 3038001, file counter 27, database pages 17052, cookie 0x2, schema 4, UTF-8, version-valid-for 27

looks a lot happier.

Maybe I should have looked in the Claws debug logs

claws-mail --debug | egrep bogof

plugin.c:453:trying to load `/usr/lib64/claws-mail/plugins/bogofilter.so'
bogofilter_gtk.c:495:Bogofilter GTK plugin loaded
bogofilter.c:918:Bogofilter plugin loaded
plugin.c:527:Plugin Bogofilter (from file /usr/lib64/claws-mail/plugins/bogofilter.so) loaded
plugin.c:528:TIMING plugin_load /usr/lib64/claws-mail/plugins/bogofilter.so: 0s000ms
** Message: : Connecting ...

bogofilter.c:825:|bogofilter -s -b ...
bogofilter[29165]: Error preparing "SELECT name FROM sqlite_master WHERE type='table' AND name='bogofilter';": file is not a database (#26)_
bogofilter[29165]: Error on database /home/user/.bogofilter/wordlist.db: file is not a database_
Can't open file 'wordlist.db' in directory '/home/user/.bogofilter'.
error #2 - No such file or directory.

Remember to register some spam and ham messages before you
use bogofilter to evaluate mail for its probable spam status!

** (claws-mail:29077): WARNING **: 22:51:24.987: [2022-05-02 22:51:24] Learning failed; `bogofilter -s -b` returned with error:
Unknown error

and after it was fixed

claws-mail --debug | egrep bogof

** Message: 22:56:42.316: filtering log disabled

plugin.c:453:trying to load `/usr/lib64/claws-mail/plugins/bogofilter.so'
bogofilter_gtk.c:495:Bogofilter GTK plugin loaded
bogofilter.c:918:Bogofilter plugin loaded
plugin.c:527:Plugin Bogofilter (from file /usr/lib64/claws-mail/plugins/bogofilter.so) loaded
plugin.c:528:TIMING plugin_load /usr/lib64/claws-mail/plugins/bogofilter.so: 0s002ms
** Message: : Connecting ...

bogofilter.c:825:|bogofilter -n -b ...
bogofilter.c:825:|bogofilter -s -b ...
bogofilter.c:825:|bogofilter -s -b ...
bogofilter.c:825:|bogofilter -s -b ...
bogofilter.c:825:|bogofilter -s -b ...
bogofilter.c:825:|bogofilter -s -b ...
bogofilter.c:825:|bogofilter -s -b ...
bogofilter.c:825:|bogofilter -s -b ...
bogofilter.c:825:|bogofilter -s -b ...
bogofilter.c:825:|bogofilter -s -b ...
plugin.c:289:removing /usr/lib64/claws-mail/plugins/bogofilter.so rdeps
bogofilter.c:420:thread done
bogofilter.c:973:Bogofilter plugin unloaded

there was a

bogofilter -n -b

or

bogofilter -s -b

for each message that was either marked Spam or Ham manually in the UI.

and now for something completely different.

This is my guide to popping pills.

A surprisingly small number of people seem to realise that tipping your head back works for tablets , but the same technique is terrible for capsules .

The tablets sink in the liquid in the mouth and have to be shunted to the back to be swallowed.

Capsules on the other hand float and can be easily swallowed with the head tipped forward.

As with all medical advise from the internet: This is not medical advice, please use with caution and consult a trained medical professional if you have any concerns.

That said, it works for me and I wish I had known it sooner!

Thanks to Alex for the insight.

It was also a good excuse to muck around with Inkscape again :D