J'ai eu le besoin de nettoyer des tonnes et des tonnes de features-branches non-mergées et abandonnées dans nos répos Git. J'ai donc écrit un petit script bash qui va lister toutes les branches dont l'âge dépasse le nombre de jours indiqués en paramètre.

Utilisation

# Va lister toutes les branches qui n'ont pas bougées depuis plus de 180 jours
$ git-unused-branches 180

Le script

#!/usr/bin/env bash

if [ "$1" == "" ]; then
    echo "Usage:    git-too-old-branches <NB_DAYS>"
    echo ""
    echo "( NB_DAYS The lower age limit filter of branches"
    echo "          to list"  
    echo ""
    echo "Example"
    echo "          To list any branches which has not been"
    echo "          changed since 90 days use :"
    echo "          git-unused-branches 90"
    exit 1
fi

NB_DAYS="${1}"
SECONDS_IN_DAY=86400
TODAY_EPOCH_TIME=$(date +"%s")

## List everything expect
## - Production branches
## - Renovate branches
## - HEAD (master)
list_branches() {
    local branches

    branches=$(git branch -r | grep -v -E "origin/HEAD|origin/production|origin/renovate" | sed "s/  //" | sort)

    echo "${branches}"
}

filter_branch() {
    local ageGap
    local branch
    local branchAge
    local maxDays

    branch="${1}"

    branchAge=$(git log "$branch" -n 1 --format=%ct)
    ageGap=$(((TODAY_EPOCH_TIME-branchAge)/SECONDS_IN_DAY))

    if (( ${ageGap} > ${NB_DAYS} )); then
        echo "$branch is [$ageGap] days old"
    fi
}

main() {
    local branches

    branches=$(list_branches)

    for branch in ${branches}
    do
        filter_branch "${branch}"
    done
}

main

En espérant que ça puisse aider certains :P

@Animal voici un petit script à mettre dans ton PATH qui te sortira la valeur en hexa directement :

#!/usr/bin/env bash
if [ "${1}" == "" ]; then
    echo "Usage : script <PATH_TO_THE_FILE>"
fi

crc=$(cksum -o3 "${1}")
printf "%x\n" ${crc}

@Oros j'ai souvent vu que la ligne set -euo pipefail était recommandée en Bash et je voudrai te poser une question car je crois que le c'est le -e ou le pipefail qui ne marchent pas chez moi à cause de ma façon de coder en Bash.

En fait (et je sais que @Animal fait pareil) je créé des fichiers à sourcer et qui ne contiennent que des fonctions. Ces fichiers/bibliothèques peuvent aussi contenir des constantes via un export -r et surtout, chaque fonction est testée unitairement avec bbtools ou shellunit.

Comme Bash ne permet que de retourner des "exit codes" depuis une fonction, le hack consiste à leur faire imprimer le résultat souhaité via un echo unique et d'exécuter la fonction de la manière suivante pour récupérer la valeur de retour :

local resultat
resultat=$(ma_fonction "${param_eventuel}")

Donc mon script principale consiste à sourcer les libs dans le bon ordre puis à déclencher une fonction unique, en générale baptisée main() qui contient la procédure à suivre. Évidemment, cette fonction main() est purement déclarative et se limite à déléguer les traitements aux fonctions des API sourcées.

Est-ce que tu procèdes comme ça pour écrire un script où est-ce que tu écris les traitements en flat directement dedans ? (Je vais essayer de retrouver le cas ou le set -euo pipefail plante avec des fonctions)

Merci j'oublie tout le temps ! (^__^)

Un tuto pour installer le Windows Subsystem Linux sous Windows 10.

Aujourd'hui j'ai testé deux Linux Mint : Tricia (19.3) qui est basée sur Ubuntu et LMDE (4) qui est basée sur Debian. Et je ne comprends pas comment marche les variables d'environnement sous LMDE ! Je m'explique, sous une Tricia je peux ajouter des exports dans mon fichier ~/.profile, typiquement :

# Ajouts en fin de fichier
export JAVA_HOME="..."
...
export PATH="${PATH}:${JAVA_HOME}/bin"

Et que je sois dans un script shell ou dans une console, ces variables sont bien définies avec la bonne valeur. Mieux encore, la modification de $PATH me permettra d'utiliser les commandes/scripts de démarrage des programmes lorsque j'exécuterai un ALT + F2 ; en somme tout marche au poil.

Par contre sous LMDE pas moyen !!
(ノಠ益ಠ)ノ彡┻━┻
Tout ce qui est déclaré dans le ~/.profile est ignoré par Bash et pourtant je n'ai aucun fichier du type ~/.bash_profile ou ~/.bash_login (ndr. pour ceux qui ne le saurait pas, si l'un de ces deux fichiers existe alors le ~/.profile est ignoré par Bash).

Et c'est très frustrant parce que ce qu'y est défini dans le ~/.bashrc ne l'est que pour Bash, ce faisant je perds la possibilité de charger des applis via le lanceur ALT + F2.

Du coup si quelqu'un sait pourquoi et surtout comment y remédier sous LMDE, je veux bien l'info. (◕_◕)

En réalité Bash ne possède pas le concept de packages ou de namespaces mais il est possible de le reproduire à partir d'une convention de nommage (ce que propose ici Google).

Dans l'idée, il suffit de préfixer toutes les déclarations de fonctions par NOM_DU_PACKAGE:: et de faire la même chose pour les invocations. Par exemple avec un "Hello World!" :

# Définition
CORE::hello() {
    echo "Hello ${1}!"
}
export -f CORE::hello

# Usage
CORE::hello "World"

Et ça marche. Par contre impossible de savoir si les double deux-points sont POSIX ou non.

Super cheat sheet ! Merci

Exécuter une application en tirant partie du multi-coeur en bash ! Pour toi @Animal !

Via Dooby

Pour @Animal et @Lenny.