Macos on blog.iankulin.com

Git/GutHub - macOS - marking file as executable

Sun, 30 Apr 2023 00:00:00 +0000

I’m working on the world’s shortest shell script - it’s called by cron to pull down a JSON weather report to a text file using curl so I can expose it on an Nginx endpoint. The purpose is to allow me to hammer that weather API from multiple machines I control without violating the TOS of my free API key.

Because I’m learning all the things, instead of just creating this on the VPS where it runs, it’s cloned from my GitHub repo for that machine. I’m creating and editing the file in VS Code on macOS, pushing to Github, then pulling the changes on the Ubuntu VPS. The intention is that this will eventually become automated with a Github action.

The problem I’ve run into is that I want the file permissions so show the file is executable so when it arrives on the VPS - so no chmod is required to make it usable.

Some googling suggested that the executable flag (but none of the other file permissions) is stored and handled by git, and furthermore, there’s a git command to set it:

git update-index --chmod=+x bin/fetchWeather.sh

So I wrote my (one line) script, applied the command above, committed and pushed, then pulled it down on the VPS and the bit wasn’t set. So somewhere in this chain there’s a problem.

At this stage, it’s helpful to know that if the executable bit is set for a file, GitHub shows this in the header of the file where it says how many lines etc.

In my case, it was showing that the file was not marked as executable in GitHub, so the problem was that the git update-index was not working for me for some reason.

A bit more investigation turned up that there’s a setting in the .git/config file called filemode that controls if the originating file system executable status is preserved. That sounded promising - I was expecting to find that is was set to false, and I could change it to true, and it would fix my problem. I had a quick look and, oh, it’s already set to true.

Seems like it’s involved though, so perhaps (my thinking went) I should change it to false and see if the problem goes away…. and it did. I changed this value to false, applied the executable bit with the git update-index command, committed, pushed it to GitHub (it was marked executable), pulled it down to the VPS, it was still marked executable!

My whole tech life, I’ve never been happy with solutions to problems where I don’t understand the underlying reasons. If things just start working when you’re fiddling around and you’re not clear on why, it feels like they could change back with just as easily and with no more reason.

A clue to what’s going on (many readers will already have figured this out) was given to me by ChatGPT. When I was asking it about this issue, it kept insisting I should chmod the file to be executable before I committed it. I had to be really clear with it that this wasn’t possible on macOS because it doesn’t have that sort of file permissions…

Of course, in fact, it does. macOS is based on FreeBSD (“without the good bits” goes the old joke told at Unix conferences). I’d just somehow forgotten this - I guess in Linux I’m used to explicitly seeing them every time I look at a directory contents, but never see it on Mac. Even if you go into “Get Info” for a file in Finder on the mac, you can see the read/write permissions, but not the executable bit status.

So how do you set and view the executable status on mac? Exactly the same as on any Unix.

I did that, and changed the /git/config filemode back to true. Committed and pushed the file up (without worrying about the git update-index) and it showed up in GitHub as executable, pulled it down, still executable.

Where's My App?

Sat, 08 Oct 2022 00:00:00 +0000

The iOS apps I’ve been making, can only run in the simulator or on my tethered device (which I haven’t actually tried yet), but the MacOS app I made today, in theory could be zipped up and distributed to the world from my website. At the very least, I wanted to drop it into my Applications folder so I could use it, so I needed to find the .app “file”, and realised I had no idea where it was. If that’s your situation, then here’s the steps you need.

First of all, you are currently building debug versions of your app. We need to create a new Scheme for the release build. In Xcode use the menus to go to Product | Scheme | New Scheme…

Give it a sensible name - maybe <app name> Release or similar. Then Product | Scheme | Edit Scheme and on the Info tab, change it to a Release build.

Build the app (Product | Build ), then back in the Product menu, there’s an item “Show Build Folder in Finder”. Click on that, and there’s your different builds. In the Release folder will be the .app file that can be copied into your applications folder.

I’m not actually sure if this is a file, more likely a folder that MacOS is pretending is a file. If you right click on it and select “Show Package Contents” you can see the actual files inside it.

Customizing the default About dialog for MacOS apps

Fri, 07 Oct 2022 00:00:00 +0000

The default Xcode MacOS targeted app has a built in “About” dialog called up from the “About ” menu item in the Mac menu bar. It wasn’t immediately clear to me how to customise this, but after digging through some MacOS apps on GitHub, here’s the answer.

When you app is being built, it looks for the file “Credits.rtf” in the app bundle. If that is found (or “Credits.html” or “Credits.rtfd”) it’s used to build out the About dialog along with your app icon.

After you’ve created the “Credits.rtf” file, you need to drop it into the folder for your project where the source files go. Then in Xcode, add it to your project in that inner folder:

Then when you rebuild the app, it will show in your about dialog.

CodeTrimmer - First MacOS App

Thu, 06 Oct 2022 00:00:00 +0000

I was listening to the StackTrace app this morning (episode 169 - “Choosing What Bugs to Ship”) and one of the ideas discussed was taking the time to automate some of your development processes, partially to save time, but also because if you make a process simple and quick, you’ll be more likely to do it multiple times to improve quality.

Coincidentally, I’d been thinking about how often I paste some code from Xcode in order to display it in one of these blog posts. If it’s from the middle of a method, it will generally be indented a long way in, and there’s no point in displaying it like that (especially for a mobile reader) so I usually manually delete a heap of spaces from each line to left align it whilst keeping the needed indentation.

Sounds like a job for a tiny MacOS app - my first! Here it is in action. You copy your code from Xcode, and paste it into the app:

Then press the “Strip Spaces” button to get:

I’ve got a few little niceties to add/tidy up, but it was a breeze converting my SwiftUI iOS development skills to MacOS - literally ticking a box.

Source