Reading up on the differences between Zsh and Bash

Typically, when writing self-documenting scripts, especially those used during a demonstration, I'd add a command such as: -

read -p "Press [Enter] to continue"

However, using Zsh on macOS 13.2.1 Ventura, I saw: -

read: -p: no coprocess

If I skipped the -p I saw: -

zsh: not an identifier: Press [Enter] to continue

when I actually pressed the Enter key

As ever, the internet answered my cry for help

ZSH: Read command fails within bash function "read:1: -p: no coprocess"

So now I have this: -

ibmcloud cs cluster ls

read "?Press [Enter] to continue"

which rightly prompts: -

Press [Enter] to continue

Fun and games with Docker login on macOS

I've been around the houses with Docker Desktop, Podman and Docker via Homebrew on my Mac over the past few months

I saw something curious this morning, whilst trying to log into IBM Container Registry 

ic cr login

Logging 'docker' in to 'uk.icr.io'...

FAILED

Failed to 'docker login' to 'uk.icr.io' with error: Error saving credentials: error storing credentials - err: docker-credential-desktop resolves to executable in current directory (./docker-credential-desktop), out: ``

I then tried the same auth process using docker login 

docker login --username iamapikey uk.icr.io

but with the same effect: -

Password:

Error saving credentials: error storing credentials - err: docker-credential-desktop resolves to executable in current directory (./docker-credential-desktop), out: ``

In case I was missing something, I even tried the Docker Creds Helper: -

brew install docker-credential-helper

but to no avail.

Finally, in desperation, I nuked my Docker credentials file - which is a TERRIBLE thing imho 

rm ~/.docker/config.json

and tried again: -

docker login --username iamapikey uk.icr.io

Password:

Login Succeeded

Even better, now that I'd installed the creds helper - which caches the creds in the macOS Keychain, the config.json is somewhat cleaner: -

cat ~/.docker/config.json

{

"auths": {

"uk.icr.io": {}

},

"credsStore": "osxkeychain"

}

Better still, the IBM Cloud CLI is also happy: -

ic cr login

Logging 'docker' in to 'uk.icr.io'...

Logged in to 'uk.icr.io'.

OK

Removing filenames with special characters - a reminder

I've written this down somewhere before but ...

I have a file that I created, by mistake, by abusing the target during a scp command

ls -altrc

-rw-r--r-- 1 root root 2541 Feb  2 02:15 '~'

and I wanted to delete it - but it has weird characters in the file name

This to the rescue: -

rm -v -- '~'

removed '~'

Reminder to self - check out Finch

From this: -

Today we are happy to announce a new open source project, Finch. Finch is a new command line client for building, running, and publishing Linux containers. It provides for simple installation of a native macOS client, along with a curated set of de facto standard open source components including Lima, nerdctl, containerd, and BuildKit. With Finch, you can create and run containers locally, and build and publish Open Container Initiative (OCI) container images.

Introducing Finch: An Open Source Client for Container Development

a friend had recommended that I check out Finch, so it's definitely on my personal to-do list.

It's on GitHub and Slack 

Go modules and forks

I'm tinkering with a Go project ( let's call it foobar ), which has a dependency upon yet another Go project ( let's call it snafu )  in the same organisation.

For the moment, I've got a fork of snafu in my own org - david-hay - and wanted to update go.mod in the foobar project to leverage it.

I knew I had to update go.mod either manually or use go mod edit --replace source=target but couldn't get past the exception: -

go: -replace=github.com/org/snafu=github.com/david-hay/snafu: unversioned new path must be local directory

It turned out, as ever, that I was holding it wrong ...

I needed to explicitly provide a "version" - in this context, that was a branch e.g. main at which to point the target during go mod edit --replace like this: -

go mod edit --replace github.com/org/snafu=github.com/david-hay/snafu@main

In other words, the right-hand side of the --replace directive needed to include four things: -

- domain e.g. github.com

- organization e.g. david-hay

- project/repo e.g. snafu

- branch e.g. main

like this: -

...

replace github.com/org/snafu => github.com/david-hay/snafu main

When I then ran go mod tidy, this went off to GitHub and pulled down the latest release from that branch in my fork: -

go: downloading github.com/david-hay/snafu v1.11.39-0.20230116121922-46267d910e38

and updated go.mod with: -

replace github.com/org/snafu => github.com/david-hay/snafu v1.11.39-0.20230116121922-46267d910e38

In other words, it replaced the branch with the release ... which is nice

With thanks to this: -

Pointing to a fork of a Go module

Fun with Git and branching

In very brief terms, I hit an issue last week where I'd created four branches in a repo, having cloned the main branch of the upstream repo.

Therefore, I'd done something like this: -

git clone -b main git@github.com:snafu/foobar@github.com

cd ~/foobar

git fetch origin && git rebase origin/main

to bring the main branch down to my Mac.

I'd then created my first branch: -

git branch dave1

git switch dave1

and added/changed some code, committed it, and pushed my new branch upstream.

I then went ahead and created a second branch: -

git branch dave2

git switch dave2

git fetch origin && git rebase origin/main

and again added/changed some code, committed it, and pushed the new branch upstream

All seemed fine ...

And I did the same for two more branches - dave3 and dave4 - with a PR for each branch being reviewed/approved and merged into main.

And then I found, when merging in separate Pull Request, that my changes from dave2 overwrote the changes made in dave1.

Which was weird....

A colleague helped explain ...

I see the 4 PRs were created from a shared branch instead of independently being created from main. That could explain the unexpected behavior where they kept rewriting each other. 

He went onto explain how to avoid the issue ...

When you run git checkout -b branchname it creates a branch branching off of your current branch.

I am used to running git checkout main; git checkout -b branchname to ensure my branches are direct branches off of main. That helps rebase them based on other PRs merging to main.

which worked a treat

So, now I've learned this, and am trying hard to add this to my "muscle memory" ...

git clone -b main git@github.com:snafu/foobar@github.com

cd foobar

git fetch origin && git rebase origin/main

git checkout main; git checkout -b dave1

etc.

We shall see if that sticks ....

Weirdness with Go

Whilst tinkering ( my fave word ) with a Go project,  I was trying to force a complete rebuild of the module, via go mod tidy.

Now I started by removing go.mod and go.sum : -

rm go.mod
rm go.sum

And, when I ran go mod tidy  I noticed that the command was: -

(a) failing
(b) looking at a whole slew of OTHER Go projects, including those outside of the directory within which I was running the command, namely : -

/root/go/src/github.com/docker/sbom-cli-plugin

Now, of course, note what I did previously i.e. rm go.mod 

THAT WAS MY DOWNFALL :-)

From this: -

Why does 'go mod tidy' record indirect and test dependencies in my 'go.mod'?

<snip>

go mod tidy updates your current go.mod to include the dependencies needed for tests in your module — if a test fails, we must know which dependencies were used in order to reproduce the failure.

</snip>

Guess what I didn't have ?

So, the key was to re-create go.mod via: -

go mod init

and then re-run the make command that had initially populated go.mod - which also ran go mod tidy and then ... everything is OK.

Phew !