Don’t need A PS5 or the latest Xbox, whatever it’s called, to have fun. Playing around with the Pi400. 🙂
99.999999% of my readers can probably ignore this one, but if you are of the small minority who use Rsync and have Mac and Linux computers in your home you’ll want to read this.
I have Plex running on a Raspberry Pi for my music. I have a large mp3 folder. Too large to run Syncthing on it unfortunately, but an occasional rsync is perfectly fine.
I thought it worked fine until I quickly realised it was syncing the same files over and over again. It turns out the Mac and Linux machines I’m using have different ideas about character sets their filenames are stored in. A file with an accented character on the Mac is completely different to one that looks the same on the Linux box.
The solution took a while for me to find but it’s very simple. Rsync has an option named
--iconv to convert between character sets!
The solution was embarrassingly simple: Much due to a comment I read when researching the problem, I thought you were supposed to specify the character set in the order of transformation; but it seems as that is not the correct syntax. Rather, one should always use
--iconv=utf-8-mac,utf-8when initialising the rsync from the mac, and always use
--iconv=utf-8,utf-8-macwhen initialising the rsync from the linux machine, no matter if I want to sync files from the mac or linux machine.
Then it works like magic!
EDIT: Indeed, sometimes, checking the manual page closely is a good thing to do. Here it is, black on white:
--iconv=CONVERT_SPEC Rsync can convert filenames between character sets using this option. Using a CONVERT_SPEC of "." tells rsync to look up the default character-set via the locale setting. Alternately, you can fully specify what conversion to do by giving a local and a remote charset separated by a comma in the order --iconv=LOCAL,REMOTE, e.g. --iconv=utf8,iso88591. This order ensures that the option will stay the same whether you're push- ing or pulling files.
I can’t login to my Raspberry PI3. When I ssh into it the password is rejected. When I plugged a keyboard and HDMI cable in the login would fail silently at first and then after reboot it would tell me the password was wrong.
Fearing the worst, that the small machine had been hacked, I plugged it out and attempted to go into single user mode but even that didn’t work. I tried various cmdline.txt changes, I saw an odd message saying:
sh: can't access tty; job control turned off
That wasn’t the worst. I even managed to generate a kernel panic once!
When I was just about ready to give up I plugged in the HDMI cable again and saw a strange libcrypt error show up.
/sbin/sulogin error while loading shared libraries: libcrypt.so.1: cannot open shared object file: no such file or directory
A quick search for that message brings me to the one thread on the Internet about it.
Unfortunately, I don’t have another Linux machine handy to copy libc6 from but I do have a backup of the SD card and that worked. I made a backup with Disk Utility (yes, don’t sneer, I can use
dd too) and after making a new backup I restored the old backup with Etcher.
The last time I did an
apt upgrade was just before a recent trip where I was depending on the RPI3 for my Plex music. Luckily the Plex server hadn’t restarted in that time and must have been using the old libc6!
Another tool that was useful here was ext4fuse which I installed through Homebrew. It’s even possible to mount an ext4 partition from an SD card image by first mounting the boot partition with Disk Utility, checking the device with
df -h and then using the very next device number like this:
ext4fuse /dev/disk9s2 /Volumes/rpi -o allow_other
Read only access to the Raspberry PI/Linux part of the image! Strangely enough it doesn’t show in Finder but
df shows it is mounted.
Now to make a new SD card backup before I update anything else with
X > Y >> Z
Where X is the population of developers who read this blog, Y is those that use Vim and Z is those that use vimdiff regularly. I guess this post will only be useful to a tiny minority of my readers, but to them it might be the best thing they’ve read all year. (Well, it is 2016, right? It’s been a weird year.)
Vimdiff allows you to open two files in Vim and side by side compare them, pushing changes from one file to another. I’ve been using it as long as I’ve been working on b2/WordPress and even before then too. It’s supremely useful.
Over the years I’ve used many different terminals, with various settings and colour configurations. My vim settings change over time too as I move from one machine to another. Sometimes the colours look ok in Vimdiff, sometimes they don’t. Sometimes the colours are ok for one file type while conflicting in others.
The problem is that Vimdiff has it’s own colours it uses to show what parts of the files are different or missing. Those colours can sometimes hide actual text in the files. I find myself highlighting those lines with SHIFT-V to see the text.
I could pick a different colour scheme but then there’s no guarantee that a different part of text will be hidden by Vimdiff’s colour scheme. The easiest way to fix this is by disabling syntax highlighting completely when in Vimdiff and you do it like this. Open up your ~/.vimrc and add these lines:
if &diff syntax off endif
With that in there Vimdiff goes from looking like this to the simplified appearance below.
Ironically, the theme I’m currently using in Vim in the screenshots above isn’t that problematic, but here are two screenshots that show the problem from another machine. In the second screenshot I have highlighted (with SHIFT-V) the line with the function name in the left side. As you can see, the text “function” is still invisible in the right side of the screenshot.
If you don’t want to edit your .vimrc for whatever reason you can also manually do
:set syntax=off from within the editor but you’ll have to do that for each of your files.
All the code above is GPLed WordPress code. Thanks to user hildred on Stackexchange for that one. Hopefully someone else will find this useful.
In the past I’ve used FSLint or even some BASH magic to find duplicate files but I have a huge archive of photos and videos, some of which were renamed during import, and some were accidentally imported more than once, or moved about. It’s somewhat chaotic
So I was very glad to find dupeGuru! It’s a powerful application for MacsOS and Linux that allows you to scan one directory or more for duplicate files. It can search by content, or match filenames. It has modes for music and pictures, but I’ve stuck with the standard search as I want to only look for files that are 100% the same.
It found several gigabytes of duplicates for me, and it has a useful feature that symlinks duplicates to their parent. Even though the dupes still exist, they’re not taking up any space.
The developer is looking for help to maintain the project. You can find more information and source code too on the dupeGuru GH page.
A contributor to the Hackaday blog has a good old rant about how Vim is superior to Emacs.
Of course it is (a silly argument), but he manages to give a quick overview of Vim and describes a few neat tricks beginners will find useful!
And after writing the text above I realised that there are going to be people reading this who have absolutely no idea what either Vim or Emacs are! They’re text editors, and they have passionate users. Yeah, that includes me too. 🙂
I hold on to things for way too long! The last four weeks have felt like a continuous purging of old “stuff” with several trips to the Kinsale Road site (BTW, it was a bit creepy to see a guy rummaging around in the electrical bins as soon as I dumped stuff in them, he could at least have waited until I left), and there’s still more to go. At least now I can walk around the attic without tripping over random objects.
The Bash command line can be edited using the cursor keys but for the real power user you need to enable Vi mode:
$ set -o vi
Or add it to one of your Bash startup files.
Now, instead of the slow interactive editing you’ll get the command and insert mode of Vi! Users of Vi or Vim will feel right at home. You start in insert mode by default so it feels the same as before. You can type new text, move left and right with the cursor keys and delete text but press ESC and you can do all the things Vi command mode allows you to do.
The best thing may well be the Bash command prompt and MacPorts.*
* most Mac owners probably won’t agree with me.
Making the switch from Windows or Linux to Mac OS X is not without pain. The extra CMD key plays havoc with muscle memory, and the “Windows Explorer” of Mac OS X, Finder, is quite a different beast to what you might be used to in the Windows or Linux worlds.
About two weeks ago I decided to make the switch again to Mac OS X and I lamented the difficulty in using Finder to do simple tasks. I’m still not 100% happy with Mac OS X it but the tips on the following pages made things easier:
- Home and End keys work on a line, not a document, silly.
- Disable natural scrolling.
- Switch CMD and ALT if you’re using a PC keyboard. I have a lovely split keyboard but the default configuration hurt my fingers.
- Change the keyboard layout if your keyboard doesn’t work the way you’re used to. I still haven’t got this set up exactly as I want it to. In my terminal some keys act differently I think but I haven’t set aside time to work out which. I need to swap ” (shift-2) with @ (key to the top/left of right-shift). My muscle memory gets them mixed up all the time.
- Automount SMB drives automatically. I haven’t been able to get the fstab method to work yet because my password has spaces but the “User Login” one works well enough.
- Change Finder search so it searches the current directory by default.
- Type the path into Finder.
- 9 tips to improve Finder.
- Sorting and arranging in Finder.
- Right click on the directory name in Finder and show a dropdown of the path to that directory.
- Install Mac Ports to get a working copy of Rsync and a better ls that lets me put parameters after the filename.
There are still oddities. When Mac OS X mounts an SMB share it does so with permissions that only allows the current user to edit files in the share. That’s perfectly understandable but it messes things up for Rsync when I’m syncing directories with a remote host. I’ve had to resort to using the “–size-only” parameter of Rsync so it won’t attempt to sync every file each time. I need to figure out if that can be fixed somehow.
I’ll update this post from time to time as I come across more oddities.