Grokking grep

A colleague was tinkering with grep and, thanks to him, I discovered a bit more about the trusty little utility.

I had not really explored the -e switch: -

     -e pattern, --regexp=pattern

             Specify a pattern used during the search of the input: an input line is selected if it matches any of the specified patterns.  This option is

             most useful when multiple -e options are used to specify multiple patterns, or when a pattern begins with a dash (‘-’).

but he pointed out that that switch can have problems when parsing, say, a list of strings that are similar but different.

As an example, I have a set of files: -

-rw-r--r--   1 hayd  wheel    0 22 Jul 17:34 dave

-rw-r--r--   1 hayd  wheel    0 22 Jul 17:34 dave_1

-rw-r--r--   1 hayd  wheel    0 22 Jul 17:36 dave_2

-rw-r--r--   1 hayd  wheel    0 22 Jul 17:36 dave_3

If I want to e.g. query a directory for all files containing the word 'dave' I could do this: -

ls -al | grep dave

or, to be more specific: -

ls -al | grep -e Dave

both of which return: -

-rw-r--r--   1 hayd  wheel    0 22 Jul 17:34 dave

-rw-r--r--   1 hayd  wheel    0 22 Jul 17:34 dave_1

-rw-r--r--   1 hayd  wheel    0 22 Jul 17:36 dave_2

-rw-r--r--   1 hayd  wheel    0 22 Jul 17:36 dave_3

However, if I only want to return the file that's named 'dave' and ignore the rest, I'm somewhat stymied.

However, grep -w comes to the rescue: -

     -w, --word-regexp

             The expression is searched for as a word (as if surrounded by ‘[[:<:]]’ and ‘[[:>:]]’; see re_format(7)).  This option has no effect if -x is

             also specified.

so I can run: -

ls -al | grep -w dave

and just get this: -

-rw-r--r--   1 hayd  wheel    0 22 Jul 17:34 Dave

Isn't that nifty ?

To start, press any key .... hey, where's the [Any] key ?

So I was writing some scripts for a demo that I delivered earlier today...

One script will run on my Mac, using the Zsh shell, the other will run on an Ubuntu box, using Bash.

In both cases, I wanted to pause the script and wait for user input before proceeding.

On Ubuntu, I did this: -

read -p "Press [Enter] to continue"

Sadly, however, on macOS 12.4 via zsh, that didn't work ...

read: -p: no coprocess

Thankfully, there's a better / different way: -

read "?Press [Enter] to continue"

which is nice

Today I Learned - Shorter redirection, what's not to like ?

So I write a lot of scrips for Bash and Zsh, and often make use of redirection where, for example, I generate a variable by running another command within parentheses.

As a specific example, I'd query my Floating IP and persist it to a text file for future use: -

ic is floating-ips --output JSON | jq -r '.[].address' > ~/floating_ip.txt

Later on, I'd look to use that Floating IP for, for example, a SSH connection, as follows: -

export floating_ip=$(cat floating_ip.txt)

ssh root@$floating_ip

Authorized uses only. All activity may be monitored and reported.

root@163.61.95.34's password:

However, one of my colleague's did point out that I could reduce the number of characters typed when setting the floating_ip variable: -

export floating_ip=$(< floating_ip.txt)

See, that saves a whole two characters ....

Mind you, I can also reduce things further via: -

ssh root@$(cat floating_ip.txt)

I love shelling !

TIL - read-only variables in Linux

 A co-worker was seeing an exception: -

 line 8: TMOUT: readonly variable

when trying to SCP a file from a remote Linux box.

I did some digging and found a RedHat article: -

Why does it prompt "bash: TMOUT: readonly variable" when sudo'ing or ssh'ing to the system? 

that said, in part: -

The TMOUT variable is usually defined read-only to avoid users from unsetting or modifying its value. Due to this it's not possible to set it twice.

I reproduced the problem on my Ubuntu 18.04 box: -

-bash: TMOUT: readonly variable

with a pair of scripts: -

The first script: -

cat /etc/profile.d/a.sh

readonly TMOUT=500; export TMOUT

sets TMOUT as readonly

The second script: -

cat /etc/profile.d/b.sh

TMOUT=600; export TMOUT

then tries to override it

which I validated: -

fgrep -R TMOUT /etc/profile.d/

/etc/profile.d/a.sh:readonly TMOUT=500; export TMOUT

/etc/profile.d/b.sh:TMOUT=600; export TMOUT

I left my colleague to dig into /etc etc. and see what was going on, but TIL about read-only variables 

Having fun and games with Kubernetes networking

I'd forgotten how much I simply enjoy the opportunities for hacking - in the original naive sense of the word - that Kubernetes (K8s) offers.

Today I've been working to find out why CoreDNS didn't work in my cluster - clue, it was containerd that did it

However, I then started seeing: -

failed to allocate for range 0: no IP addresses available in range set: 10.48.131.1-10.48.131.62

from my CoreDNS pods, having "fixed" containerd.

Thankfully, Google Cloud have a doc for that: -

Pods display failed to allocate for range 0: no IP addresses available in range set error message

In part, it required me to stop containerd and kubelet, and clear out the previously defined IP address range: -

mkdir /var/lib/cni/networks

Once I did this, and restarted containerd and kubelet, we're back in the game !

Munging JSON with JQ - without using grep and awk

Further to a previous post: -

Grep AND awk

I wanted to achieve much the same, but only using jq

So here we go: -

ic is images --output JSON | jq -r '.[] | {Name:.name,Architecture:.operating_system.architecture,Status:.status} | select((.Name | contains("ubuntu")) and (.Architecture | startswith("s390x")) and (.Status | startswith("available")))'

which returns: -

{

  "Name": "ibm-ubuntu-18-04-1-minimal-s390x-3",

  "Architecture": "s390x",

  "Status": "available"

}

as opposed to the alternative: -

ic is images | awk '/s390x/ && /ubuntu/ && /available/'

r018-e3d94080-972f-4f18-8a79-60a12d0b61c2   ibm-ubuntu-18-04-1-minimal-s390x-3                 available    s390x   ubuntu-18-04-s390x                   18.04 LTS Bionic Beaver Minimal Install   2               public       provider     none         -   

Git and Ubuntu - not branching out

 Whilst trying to make some changes to a GitHub project, using an Ubuntu box, I hit an interesting issue with git switch - namely that it doesn't work 

So I'm running Ubuntu 18.04.6 LTS: -

lsb_release -a

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.6 LTS
Release: 18.04
Codename: bionic

and had created a new branch: -

git branch

  test_doc_update
* develop

and then tried to switch to it: -

git switch test_doc_update

but instead got: -

git: 'switch' is not a git command. See 'git --help'.

I checked the version of Git: -

git --version

git version 2.17.1

and even tried upgrading it: -

apt-get update && apt-get upgrade -y git

...

The following packages will be upgraded:
  git git-man
2 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.

...

but to no avail: -

git --version

git version 2.17.1

Instead, as per this Git: ‘switch’ is not a git command. See ‘git –help’  I used this instead: -

git checkout test_doc_update

Switched to branch 'test_doc_update'

git branch

* test_doc_update
  develop

Sorted !

For the record, I have a more up-to-date version of git on the Mac, via Homebrew

ls -al `which git`

lrwxr-xr-x  1 hayd  admin  28 19 Apr 08:59 /usr/local/bin/git -> ../Cellar/git/2.36.0/bin/git

git --version

git version 2.36.0

with which git switch DOES work