Monday, 22 May 2023

On the subject of aliases ...

I'm a super-massive fan of time/labour saving devices, and that goes for command-line tips n' tricks to save me: -

(a) typing more stuff

(b) looking in my notes to remember what I need, in order to type more stuff

Therefore, I've finally got around to creating an alias to create a new branch in a GitHub repo that I've cloned to my Mac.

I've added this alias to ~/.zprofile: -

gitbranch='git fetch origin && git rebase origin/master && git checkout master; git checkout -b $1'

so now I just need to type: -

gitbranch foobar

or: -

gitbranch snafu

in order to create a new branch ...

Which is nice.

Using 1Password to store API keys ...

 Following on from my earlier post: -

Wow, why have I not been using 1Password for my SSH keys before today ? 

I've got a little further, with various API keys now stored in my 1Password vault

This is far simpler, in that the vault entry, of type API Credential, only needs to have a name/title e.g. IBM Cloud API Key and a credential, the actual API key itself.

With that in place, I've then setup an alias to retrieve/display the API key: -

apikey='export APIKEY=$(op item get "IBM Cloud" --field credential) && echo $APIKEY'

in ~/.zprofile, meaning that I just need to run the "command" apikey to ... see my API key.

I will, of course, be leveraging the same API keys in various other scripts/aliases, including things that login to IBM Cloud etc.

Saturday, 20 May 2023

Wow, why have I not been using 1Password for my SSH keys before today ?

 As an avid user of 1Password, I've only really just delved into the Command-Line Interface (CLI), including the ability to create AND use SSH keys.

I'm running on macOS 13.4 and, as per the documentation - Manage SSH Keys - I've installed the BETA version of the op command: -


downloaded from here 

I'm also running 1Password for Mac 8.10.6 (81006027) and, having configured the SSH Agent and the Command-Line Interface (CLI) options via Settings > Developer : -

1Password Developer pane showing SSH Agent and CLI settings

and then generate a new SSH key: -

op ssh generate --title "SSH Key - 20 May 2023"

The key then appeared under a new 1Password category - SSH Keys - from where I could select the public key and add it to the ~/.ssh/authorized_keys file on two of my target Ubuntu boxes

This has all made life much easier on the Mac, via iTerm etc. where my SSH config is WAY simpler: -

cat ~/.ssh/config

Host *
  IdentityAgent "~/Library/Group Containers/"

Even better, I was able to quickly add the public key to GitHub's SSH Keys page via the New SSH Key button, which immediately prompted to retrieve the new key - SSH Key - 20 May 2023 - from the 1Password vault ...

Which is nice

Friday, 19 May 2023

Today I Learned - how to deal with Shell Check SC2086

So, technically I learned this yesterday but 🤷‍♀️

As part of our CI/CD testing, we run shellcheck  against our shell scripts, and saw the following: -

   ^----^ SC2086 (info): Double quote to prevent globbing and word splitting.

for a piece of code that referenced a variable e.g. : -

echo $FILES

The shellcheck Wiki covers this: -

SC2086 – ShellCheck Wiki

and suggests that $FILES be wrapped in double quotes e.g. : -

echo "$FILES"

So far, so good

However, the code in question was actually a variable containing more than one element e.g. : -

FILES="a.txt b.txt c.txt"

so the next line in the script which leveraged the values within the $FILES variable: -

ls "$FILES"

fails with: -

ls: a.txt b.txt c.txt: No such file or directory

Thinking more about this, this kinda made sense i.e. we're treating the values within the $FILES variable as elements within an array, but we're not actually treating the variable as an array, by incrementing through the elements by an index.

The Wiki does reference this: -

Using that as inspiration, I updated the script: -

read -ra files <<<"${FILES}"
ls "${files[@]}"

In essence, this is creating a "real" array from the $FILES variable, and then we're incrementing the index using [@] 

To be clear, I also took inspiration from: -

How to be explicit about intentional word splitting?

and this is my demo / test script: -

#! /bin/bash
# Set variable
FILES="a.txt b.txt c.txt"
echo "Works, but breaks shellcheck"
echo "Fails, but passes shellcheck"
ls "$FILES"
echo "Works, and passes shellcheck"
read -ra files <<<"${FILES}"
ls "${files[@]}"

which, when I run it, does this: -


Works, but breaks shellcheck

a.txt b.txt c.txt

Fails, but passes shellcheck

ls: a.txt b.txt c.txt: No such file or directory

Works, and passes shellcheck

a.txt b.txt c.txt

Finally, for now, there's a great shellcheck plugin for VS Code: -

ShellCheck for Visual Studio Code

and, for the record, the shellcheck project is available on GitHub

macOS to macOS File Sharing - Don't work, try The IT Crowd

 I use File Sharing between two Macs on the same network, both running the latest macOS 13.4 Ventura. For some strange reason I wasn't a...