13 posts tagged with "linux"

Which CLI command would you say you use most on Linux? Most definitely ls to display the list of files in the current directory.

And then you'll say to me, well, all you have to do is create an alias alias ls="ls -alh"; of course, but let's go further and revisit this ultrabasic command and add some functionality to it.

Natively, Linux has a command-line tool called diff for comparing two folders or files. Comparing two folders is quite simple: diff folder_1 folder2. And it's no more complicated for two files: diff file_1 file2.

However, when you want to do this in a slightly more industrialised way (launch a very large number of comparisons to compare two versions of the same project, for example), the use of a few flags and snippets comes in handy.

A concept of the clean code approach is to avoid too many function parameter (I would say that four parameters is already too many).

When you're programming in a language more advanced than Linux Bash, it's easy to get round the problem. For example, in PHP, if I need to call a function and pass it several parameters, I'll create an object that will be my only parameter and that object will then have several properties.

So, for instance, if I need to pass data such as a surname, first name, date of birth, gender, etc., I'll create a person object, define my properties and voilà, I've only got one parameter to pass to my function. In most cases, it'll be a very nice solution.

But how do you do it in Linux Bash? It's impossible to pass an object... so I'm going to pass it an associative array.

Today is a public holiday in Belgium, so I'm finally taking the time to install Ubuntu on my old PC.

The idea is to remove Windows and install Ubuntu Desktop 24.04 on the computer.

Let's go, you'll see, it's easy.

As you probably know, CTRL+R in the console will give you access to your HISTORY i.e. you'll retrieve the list of the commands you previously typed in your console. Just like using UP or DOWN keys but with a very small search engine.

And it makes the job but, honestly, this is really basic, no?

The Fuzzy Finder (aka fzf) command line utility will explode the possibilities linked to searching in the history but, in reality, this is just one of the consequences of installing fzf, which is so much more powerful.

Let's have a look.

ZSH supports plugin and one of the wonders is the zsh-autosuggestions one.

That one will suggests commands as you type based on your previous history and completions.

The more you use your Linux console, the more valuable this plugin will prove to be, as it will learn from you; it will know which commands you have already executed and will suggest them as soon as you start typing the first characters. Finish thinking "Gee, what were the parameters I used for ...".

zsh-syntax-highlighting is another gem for ZSH.

As you type, you'll be able to tell from the colors that, for example, something isn't quite right.

If you type head followed by a space, ZSH will display this word in green: this command exists and is valid. If you type heat there, the word will appear in red: this command does not exist.

It sounds simple, but it's so practical.

ZSH is a powerful alternative to Linux Bash offering a lot of features like auto-completion (I like this so much), plugins and even themes.

The idea here is to empower your Linux console, both the command line like, f.i. new aliases out-of-the-box and make the look and feel even better.

I've chosen Oh My ZSH since years, let's see how to install it followed by a discovering some features.

This is a very common source of problems using .env files: you've two or more different .env file like .env and .env.example.

You're a programmer and coding a new amazing feature. You're adding one or more new environment variables to your local .env file and everything is working fine on your computer.

Why? Because the variable(s) you've added have been added in your local .env file, on your computer only.

As you know, you have to create the variables in the .env.example file too but let's be honest, nobody thinks about it.

When deploying a project on servers, we need to pay particular attention to the .env file. This file is crucial and will determine whether our application works properly (or crashes).

The normal way of doing things is to run a git clone command to get the latest version of the application from a repository (branch test for a test server, dev for an acceptance server, main for a production server).

Once cloned, the next command will be to create the .env file and it's done using cp .env.example .env.

And that's where the obligation to be meticulous begins.