Colas.Nahaboo.net - linux

Suntimes, a small shell utility

2022-03-03T00:00:00+00:00

I just made a small command-line utility to display the sunrise and sunset times at a location. It can be quite useful in shell scripts.

It is a minimal Go wrapper around the nathan-osman/go-sunrise library</a>

You can find it at my repository: GitHub - ColasNahaboo/suntimes</a>

Bash lessons learned with AoC 2021

2022-01-11T00:00:00+00:00

I completed all the exercises of the Advent of Code 2021 in bash! (see my previous post</a>)

You can find my solutions with comments in my GitHub repository at https://github.com/ColasNahaboo/advent-of-code-my-solutions/tree/main/bash/2021

I must say I "cheated" a bit. My solution for the Day 24 was too slow in bash, and as I was a bit out of steam, I did not try to find a smart algorithm. I just noticed that I solved it by building a bash arithmetic expression (of 1 million characters...) that I then evaluated in bash, and since its syntax was exactly the one for C... I just made the bash script compile the bash expression in C and execute it, using the C compiler as a bash arithmetic just-in-time compiler :-)

I just discovered AoC this year, and I am impressed. Challenging, fun, and a great way to progress. I am going to do the previous years, too, but in "real" languages this time. At least ones with data structures... I will start with Go.

What I learned:🔗</a></h2>

Coding in bash is not so bad, even if it can border on insanity at times :-).</li>
Modern bash features are often overlooked but very useful.</li>
Passing shellcheck should be a mandatory goal for each bash programmer. I resented it at first since I thought it was adding unecessary syntaxic sugar to my code until I realized that it was a symptom that my coding style was the problem.</li>
Use `[[...]]</code> for strings and ((...))</code> for integers other any of the legacy constructs like [...]</code>, test</code>, etc... The code is then much cleaner and safer (and a tad faster), as you do not have to quote as much. E.g: [[ -z foo ]]</code> instead of [ -z "$foo" ]</code>, or even ((i=j))</code> instead of i="$j"</code>`

but, this makes traditional debugging with `set -x</code> less useful as the values of variables are not displayed anymore. E.g if j is 2, the tracing of i="$j"</code> shows i=2</code> whereas the tracing of ((i=j))</code> only shows ((i=j))</code>. This could be where a bash debugger would be useful, but I know only one,` `bashdb</a>, and it does not seem updated anymore, and I could not find a version working with bash 5.1. The trap DEBUG</code> trick can be useful, though.</li>`
`So, I tend to write now i=$((j+k))</code> while developing code, and maybe later for production switch to the a bit more efficient ((i = j+k))</code></li> </ul> </li>`
`I avoided arrays in bash because I found out they were abysmally slow when first introduced, to the point that managing data in files with grep, sed, ... was actually faster than using arrays. But not anymore! Bash arrays should now be used as much as possible.</li>`
`A lot of bash functions can "map" on arrays. For instance ${tab[@]//x/y}</code> will string-replace x by y in all the elements of the array tab, and is super fast.</li>`
`Use arrays rather than the classic way to represent lists in bash by space-separated (or tab-separated) substrings in a string.</li>`
`Bash can have typed variables: integer ones via declare -i</code> or local -i</code>, and using them makes your code safer.</li>`
`Bash functions can be passed variables by name, useful for efficiency to avoid copying big arrays or strings, and to provide multiple return values by modifying passed variables. But it cannot recurse as it is not a passing by reference, but by name.</li>`
`Working with arrays makes using $(...)</code> impractical, as commands are executed in a subshell and cannot access arrays anymore to update them in the parent shell. So I tend to pass the return value(s) into global variables of the same name of a function. E.g. instead of x=$(foo)</code>, I write foo; x="$foo"</code>. Or pass variables by name to set them if I want to return multiple results.</li>`
`To parse a space-separated string, the fastest is using set</code> to map the elements in the positional parameters $1</code>, $2</code>, ... then the ${string#* }</code> and ${string% *}</code> operators are the fastest, closely followed by a read, the full [[ $string =~ ([-[:digit:]]+)[[:space:]]... ]]</code> being 3 times slower. And if possible, using indexes is even faster: ${string:i:j}</code>.</li>`
`Use the faster $(< filename)</code> instead of $(cat filename)</code>.</li>`
**`To copy an associative array A1 to A2 in bash 4.4+, do: A1_def=$(declare -p A1) && declare -A A2="${A1_def#*=}"</code></li>`
`To access more than 9 parameters in a function: use braces: $10</code> wont work, but ${10}</code> does.</li> </ul>`**

Advent of Code 2021 2021-12-07T00:00:00+00:00 I just discovered the Advent of code</a> coding challenge. It exists since 2015, and seems really interesting in that it is language-agnostic. Each day a problem is described, with input files consisting of numeric values for the problem. You must submit the answer which is a number by whatever means you want. I started to do the current 2021 challenge, in bash to force myself to code in a more modern style that pass shellcheck</a>. And later, i will probably do the other years in Go to learn it. I publish my solutions as I code them on my github</a>. More info: The advent of code</a> (aka AOC) site</li> The sub-reddit /r/adventofcode</a> to discuss AOC</li> </ul> Mercurial web templating 2008-10-09T00:00:00+00:00 For some time now, I have seen the light and I switched to the new wave of the Distributed Source Control management systems. Linus famous video</a> of his Google talk decided me to try. I was a bit apprehensive at first, wary of engaging myself on a technology that would bring more problems than solutions, but after some days of use, the realisation dawned over me: Distributed Source Control may be one little step for a programmer, but it is a giant step for programming. Why? because, its mental model actually follows your first intuitions that most of us developed as young programmers before using any source control system. Suppose you want to try a feature? instead of just copying the directory, you clone it. You mess an operation? you just remove the directory, no embarrassing traces left to keep the burning scar of shame on you for the following decades of a central repository. You are used to think of your enhancements as patches, you can work with patches. I could go on and on, but many people have done it much better than me so I'll just say that you should definitely try it. By the way, between the 3 main contenders, git</a>, mercurial</a> (aka HG), and bazaar</a>, I chose mercurial because of its simplicity, its better support of windows (I work in Linux since 1995 but my coworkers currently use Windows), and because some people at ILOG started using git so I wanted to be able to try something else. I did not choose bazaar as I wanted to stay close enough of git, to be able to switch to it if ever my dream to work in a windows-free world materializes one day... So I started to set up a public web repository of my Open Source personal work with mercurial, which gave me a simple way to publish my work in full detail, but, although mercurial is quite easy to use, but I had a bit of trouble figuring out how to customize its look & feel.