mlegendre

And conversely, `/dev/stdout` (resp. `/dev/stderr`) is a convenient way to "redirect" output to stdout (resp stderr) instead of a file

Or you can use `/dev/stdin`, which has the upside of not needing tool support.

I somewhat regularly use this on Linux. I think it also works on OS X

Amusingly, in French, "desed" sounds like "décéde", which means die / decease. That's quite a fitting name for a tool one would use in "I need to debug a sed script" situations!

The first link [1] in section "4. Code and test improvements" leads to a patch series with a cover letter which reads

  There are a number of tests that still follow an old convention of using
  four-space indentation. Update a bunch of tests to use the new convention
  with tab indentation

This feels a bit ridiculous to include this in such a blog post...

[1]: https://lore.kernel.org/git/pull.1513.git.git.1684440205.git...

Beware that the trailing slash in the string after `gitdir` is significant! This string is a globbing pattern (it is not obvious at first sight, and seldom mentioned), and the trailing slash implies `**` [1].

So if you type "gitdir:~/work" instead of "gitdir:~/work/", you will lose some time wondering why your configuration is ignored.

[1]: https://git-scm.com/docs/git-config#_conditional_includes

> LineageOS is not the answer

Could you expand on that?

I am curious because I have been using LineageOS on Pixel 2 / Pixel 2 XL phones for a while (and it works very well, I might add), but I am kinda clueless when it comes to Android security.

Sadly I can't remember this part; I'm pretty sure there were comical bits to it.

This makes me want to dig out the gitlab issue, and turn it into a better write-up! This'll have to wait until I'm back from holidays though.

Your mouse story makes me think of the day the CI system at work turned out not to be robust to vibrations.

One day we started having flaky tests, seemingly out of nowhere. We quickly identified that the issue affected tests involving graphical X client applications, but then we struggled to make further progress. The issue was just impossible to reproduce in other conditions... Well, as it happens, the CI jobs were running on some desktop machines we had installed somewhere within our premises. It turned out that some gentleman had plugged a mouse into one of the machines, and left it lying around on the shelf. Since then, when one of the machines was under a heavy load, the fans would spin faster, causing more vibrations, in turn causing the mouse to move, ever so slightly. And for ungodly reasons, this had side effects on tests.

Fun fact: the machines were not on my site, I managed to diagnose this over SSH. I was quite proud :-)

This enables the C-r / M-c / C-t key bindings, but there's also a completion.bash file. This enables the "**" completion trigger, which can contextually complete paths, envvar names or PIDs in commands. (See "Fuzzy completion for bash and zsh" in fzf's readme [1]). Similarly, you can add to your .bashrc:

    if [ -e /usr/share/doc/fzf/examples/completion.bash ]; then
      source /usr/share/doc/fzf/examples/completion.bash
    fi

/usr/share/doc/fzf/README.Debian explains this, as well as the setup for zsh, fish and vim.

[1]: https://github.com/junegunn/fzf#fuzzy-completion-for-bash-an...

I am now reading The Grug Brained Developer for the first time, and thoroughly enjoying every minute of my time. Thank you for writing this!

> If you're a paying user it's 5GB per repository.

TFA says 10 GB (and so does my experience).

> A namespace is basically a user or project

I believe you meant to write "a user or a group".

"Reproducible environments" sounds like a strong argument to me. If you don't have a reproducible environment, you have no guarantee that your code will work at any point in time. The more complex the projet and its dependencies, the more likely breakage will happen with a new version of a dependency.

Maybe this is something that is best learnt the hard way? Something you understand once you reflect back on how many hours you have lost fighting with dependencies, instead of doing what you actually wanted to do with the code (be it running it, developping, debugging, bisecting...).

Freezing dependencies comes at a cost though, especially since dependency management in python is a PITA. So this is a trade-off. For simpler, projects or scripts, I personally don't bother with freezing dependencies, and I handle issues when they happen. (And they do happen.)