Questo script permette di scaricare le puntate intere di Ciao Belli o DeeJay Time da Deejay Reload perché le ascolto offline praticamente da sempre. In alternativa, è possibile ascoltare direttamente il live streaming delle trasmissioni. I pattern che uso per lo scraping sono molto elementari e sono ovviamente sensibili ai minimi cambiamenti che avvengono sulle pagine di Radio Deejay.

La versione attuale è attiva da un paio di mesi a questa parte perché il pattern prima era leggermente diverso. E più si va indietro, più le differenze aumentano. Per dirne una, lo streaming hls è molto recente, Prima di esso, il reload era disponibile solo in mp3. Questa sarà la 15^a versione dello script 🙂

Il download restituisce un file in mp3 o aac. Quest'ultimo ottenuto in maniera rudimentale estrando i singoli segmenti aac ottenuti dall'analisi della playlist hls e ricombinati attraverso ffmpeg.

In linea di principio sarebbe possibile estendere lo script aumentando la scelta delle trasmissioni disponibili e, volendo migliorare l'interazione con l'utente sacrificando l'automatismo e la “scriptabilità”, dotandolo di un menù.

help() {
    echo "$1"
    echo
    echo "Usa come: wget_deejay.sh <YYYYMMDD> <prg> <format>"
    echo "Es. wget_deejay.sh 2019062 cb mp3  [Scarica Ciao Belli in mp3]"
    echo "    wget_deejay.sh 2019062 djt aac [Scarica Deejay Time in aac]"
    echo "    wget_deejay.sh live            [Deejay Live]"
}



download() {
    if [[ ${FMT} == "mp3" || -z ${FMT} ]]; then
        if ! check_and_download_mp3; then
            return 1
        fi
    elif [[ ${FMT} == "aac" ]]; then
        if ! check_aac; then
            return 1
        else
            download_aac
        fi
    else
        help "Formato non corretto."
        return 1
    fi
}



check_and_download_mp3() {
    #if ! wget -q https://${HOST}/${DATA_URL}/episodes/${TITLE}/${DATA}.mp3 -O "${PRG}_${DATA}.mp3"; then
    echo https://${HOST}/${DATA_URL}/episodes/${TITLE}/${TITLE}-${DATA}.mp3
    if ! wget https://${HOST}/${DATA_URL}/episodes/${TITLE}/${TITLE}-${DATA}.mp3 -O "${PRG}_${DATA}.mp3"; then
        help "Puntata di ${TITLE} del ${ERR_DATA}, non trovata."
        return 1
    fi
}



check_aac() {
    #if ! wget -qO- https://${HOST}/"${DATA_URL}"/episodes/${TITLE}/hls-010000/hls-010000.m3u8 1>/dev/null; then
    echo https://${HOST}/"${DATA_URL}"/episodes/${TITLE}/hls-"${TITLE}"-"${DATA}"/hls-"${TITLE}"-"${DATA}".m3u8
    if ! wget -qO- https://${HOST}/"${DATA_URL}"/episodes/${TITLE}/hls-"${TITLE}"-"${DATA}"/hls-"${TITLE}"-"${DATA}".m3u8 1>/dev/null; then
        help "Puntata di ${TITLE} del ${ERR_DATA}, non trovata."
        return 1
    else
        return 0
    fi
}


download_aac() {
    echo -n "Scarico la traccia............. "
    ffmpeg -i https://${HOST}/"${DATA_URL}"/episodes/${TITLE}/hls-"${TITLE}"-"${DATA}"/hls-"${TITLE}"-"${DATA}".m3u8 -c copy $HOME/deejay/"${PRG}_${DATA}".aac 2>/dev/null
    echo "Fatto."

}


DATA=$1
PRG=$2
FMT=$3


if [[ $1 == "live" ]]; then
    mpv http://radiodeejay-lh.akamaihd.net/i/RadioDeejay_Live_1@189857/master.m3u8
else
    case "${PRG}" in
        "cb")
            HOST="media.deejay.it"
            TITLE="ciao_belli"
            ;;
        "djt")
            HOST="media.deejay.it"
            TITLE="deejay_time"

            ;;
        "live")
            TITLE="live"
            ;;
        *)
            help "Programma Deejay mancante o non esistente."
            exit 1
    esac


    DATA_URL="${DATA:0:4}/${DATA:4:2}/${DATA:6:2}"
    ERR_DATA="${DATA:6:2}-${DATA:4:2}-${DATA:0:4}"

    if [[ -z ${DATA:0:4} ]]; then help "Manca l'anno."; exit 1
    elif [[ -z ${DATA:4:2} ]]; then help "Manca il mese."; exit 1
    elif [[ -z ${DATA:6:2} ]]; then help "Manca il giorno."; exit 1
    elif ! download; then exit 1
    fi
fi

#bash #shell #scripting

Per buona parte del mio tempo sul pc apro una shell, per cui trovo comodo spostare il meno possibile le mani dalla tastiera. Usando spesso 2FA, ho pensato ad un modo per avere un OTP usando bash. Il tool che fa al caso mio è oathtool che, per i miei scopi, è sufficiente invocare in questo modo:

oathtool --totp -b <key>

dove <key> è una stringa base32 bella lunga.

Chiaramente non voglio doverla scrivere ogni volta, nè voglio lasciarla in chiaro. Occorre che:

1. la chiave sia cifrata e decifrata solamente quando occorre;
2. l'output non arrivi su stdout per non doverlo copiare a mia volta (e lasciarlo comunque visibile)

Al punto 1. si risponde con gpg o openssl.

Al punto 2. si risponde con xsel (Gnu/Linux) o pbcopy (MacOS) che trasferiscono l'output di un comando nella clipboard.

oathtool --totp -b <<< $(gpg -q --decrypt --pinentry-mode loopback <file_chiave_cifrato>) | xsel -bi

E veniamo quindi alla:

Versione 1

#!/bin/bash

# Path del file cifrato contentente la chiave # supponiamo sia di google
KEY_2FA_FILE="$1"

oathtool --totp -b <<< $(gpg -q --decrypt --pinentry-mode loopback "${KEY_2FA_FILE}") | xsel -bi

Non è nemmeno uno script. Potrebbe essere direttamente un alias.

VANTAGGI

• Estremamente compatto
• Si sfrutta nativamente l'autocomplete col TAB per i file da dare all'input
• L'univocità dei nomi è garantita dal file system

SVANTAGGI

• Crea un file per ogni codice e, alla lunga potrebbe generare confusione
• Necessità di creare una password di cifratura per ogni file (potenzialmente tutte diverse)

Versione 2

Mi occorre quindi un file nome-valore con separatore. Ad es. il simbolo “:”

account_1:JD88EIDIKJDKMDI3IEJDMDKJKDJKDKPA
account_2:JDNBLASPUQRIEKM89478JMFKOVJDOQKJ
account_3:OIJWGDVLOIQ94KDKSUD9KSLWOER9W3ODF
account_4:MVNMWIQPQYSKGPRIGNFG24KFG9E49RPWQ
    
    ...
    
account_n:IWPQSLNCGK49TOWODIR483IRIWOFOPIQO

Nello script, la variabile KEYS_2FA_FILE memorizza il full path del file cifrato dei codici, mentre l'account deve essere fornito in input. In caso contrario, viene restituita la lista degli account disponibili.

Se l'account è valido, il file viene decifrato e viene estratto il corrispondente codice che viene memorizzato direttamente nella clipboard.

#!/usr/bin/bash

# Path del file cifrato contentente i codici 2FA
KEYS_2FA_FILE="<path>/keys_2fa.gpg"

# Acquisisce il nome account
ACCOUNT=$1

# Decifra e carica in ram il contenuto del file cifrato
KEYS_2FA_FILE_DEC=$(gpg --decrypt  --pinentry-mode loopback  "${KEYS_2FA_FILE}" 2>/dev/null)

# Se non c'è nessun argomento, restituisce la lista degli account
if [[ -z "${ACCOUNT}" ]]; then
    while read LINE; do
        cut -d":" -f 1 <<< ${LINE}
    done <<< $(echo "${KEYS_2FA_FILE_DEC}")
    exit
else
    # Estrae l'elemento contenente l'id dato in input
    KEY=$(echo "${KEYS_2FA_FILE_DEC}" | grep ${ACCOUNT} | cut -d":" -f 2)

    # Se la chiave esiste, restituisce l'otp direttamente nella clipboard
    # altrimenti esce con errore
    if [[ -z "${KEY}" ]]; then
        echo "Account non esistente"
        exit 1
    else
        # Calcola l'otp e lo trasferisce nella clipboard con pbcopy
        oathtool --totp -b "${KEY}" | xsel -bi
        echo "Fatto."
    fi
fi

VANTAGGI

• Unico entry-point per la gestione degli account (un'unica password per la cifratura del file
• Più semplice da allocare

SVANTAGGI

• L'univocità degli account deve essere garantita dall'utente.
• Perdita della funzionalità di autocomplete in fase di inserimento dati

Provo ad esplorare anche una struttura differente, più espressiva se vogliamo. Invece di un file nome-valore, uso un json così strutturato:

Versione 3

{
  "accounts": [
    {
      "id": "account_1",
      "secret": "JD88EIDIKJDKMDI3IEJDMDKJKDJKDKPA"
    },
    {
      "id": "account_2",
      "secret": "JDNBLASPUQRIEKM89478JMFKOVJDOQKJ"
    },
    {
      "id": "account_3",
      "secret": "OIJWGDVLOIQ94KDKSUD9KSLWOER9W3ODF"
    },
    {
      "id": "account_4",
      "secret": "MVNMWIQPQYSKGPRIGNFG24KFG9E49RPWQ"
    },
    
    ...
    
    {
      "id": "account_n",
      "secret": "IWPQSLNCGK49TOWODIR483IRIWOFOPIQO"
    }
  ]
}

Un array, accounts, di oggetti nome-valore.

Lo script che fa il parsing e l'estrazione non è molto diverso dal precedente.

#!/usr/local/bin/bash

# Path del file cifrato contentente i codici 2FA
JSON_2FA_FILE=<path>/json_2fa.gpg

# Acquisisce il nome account
ACCOUNT=$1

# Carica in ram il contenuto del file json cifrato
JSON_2FA_FILE_DEC=$(gpg --decrypt  --pinentry-mode loopback  "${JSON_2FA_FILE}" 2>/dev/null)

# Se non c'è nessun argomento, restituisce la lista degli account
# - jq -c '.accounts[]' restituisce una lista contenenente tante linee per quanti sono gli elementi.
# - La lista viene data in pasto al ciclo while attraverso l'operatore <<< (here-string)
# - Da ogni linea viene estratto il valore del campo "id" sempre attraverso l'operatore <<<

if [[ -z "${ACCOUNT}" ]]; then
    while read LINE; do
        jq -r '.id' <<< ${LINE}
    done <<< $(echo "${JSON_2FA_FILE_DEC}" | jq -c '.accounts[]')
    exit
else
    # Estrae dall'array l'elemento contenente l'id dato in input
    KEY=$(jq -r --arg ID ${ACCOUNT} '.accounts[] | select(.id | contains($ID)).secret' <<< ${JSON_2FA_FILE_DEC})

    # Se la chiave esiste, restituisce l'otp direttamente nella clipboard
    # altrimenti esce con errore
    if [[ -z "${KEY}" ]]; then
        echo "Account non esistente"
        exit 1
    else
        # Calcola l'otp e lo trasferisce nella clipboard con xsel
        oathtool --totp -b "${KEY}" | xsel -bi
        echo "Fatto."
    fi
fi

#bash #otp #scripting #shell

1. Introduzione

Quando si eseguono varie istanze di shell bash (zsh mi pare l'abbia già) nasce l'esigenza di disporre di una history unificata per non correre il rischio che comandi digitati su una certa istanza non siano più disponibili per un riutilizzo futuro. In alcune configurazioni, le history si sincronizzano quando si chiude esplicitamente la sessione con “exit” o con CTRL-D ma il vantaggio vero sarebbe quello di disporre del merge da subito, senza aspettare di chiudere la sessione. Anche perché, se per errore, l'emulatore di terminale viene chiuso senza prima aver chiuso le sessioni (crash o anche terminando esplicitamente l'applicazione se questo non coincide con il termine della sessione), le history non saranno più disponibili.

Il merge delle history, in sè, è banale. C'è bisogno di un pizzico di magia del comando history stesso e di un minimo di conoscenza della cosidetta “shell”.

Nota a margine: Su Gnu/Linux, tutto ciò è applicabile senza eccezioni. Su Mac OS uso bash 5 fornito da homebrew definendo un nome custom per il file history (HISTFILE in .bashrc) che altrimenti viene resettato impietosamente dopo non più di 500 linee, ogni tot riavvi e dopo tot tempo. Le ho provate tutte per andare oltre questo vincolo (sia modificando .bashrc e .profile sia usando alcune chicche specifiche del Mac che però hanno fallito tutte miseramente) e l'unica cosa che ha funzionato è stato il nome custom.

2. La ricettina

1. La shell
2. configurazione history
3. creazione script

1. La shell (Spiegone iniziale)

In un'istanza di shell i comandi di uno script vengono solitamente eseguiti come sottoprocesso del processo genitore. Uno stesso comando può essere invocato esternamente o essere implementato direttamente dalla shell (incorporato o builtin). I comandi implementati nativamente possono essere più efficienti degli equivalenti esterni perché questi ultimi richiedono la generazione di un processo figlio per essere eseguiti. Inoltre un comando builtin può accedere a parti interne della shell. D'altro canto, l'esecuzione di comandi esterni, col loro meccanismo di sottoprocesso, rende più semplice il ricorso ad un certo grado di parallelismo. Piuttosto che eseguire sequenzialmente n comandi interni, potrei decidere di ricorrere agli equivalenti esterni meno efficienti ma in grado di sfruttare il parallelismo dei sottoprocessi e lasciare al sistema operativo la gestione di questo aspetto.

Il merge delle history viene ottenuto sfruttando questi concetti.

Più facile a farsi che a dirsi:

1. si scrive una funzione history (che sarà quella invocata dalla shell come se fosse un alias)
2. nel corpo della funzione history, si usa opportunamente il builtin history che effettuerà il merge vero e proprio
3. particolare attenzione verrà data all'innesco di questa invocazione

2. Configurazione history

In ogni istanza di shell:

1. si appende la sessione corrente al file history (history -a)
2. si cancella la history attualmente in sessione (history -c)
3. si ripristina la history in sessione dal file history (history -r)
4. si riscrive history come funzione in modo che possa essere invocata dall'utente in maniera trasparente, eseguendo il sync e richiamando il builtin history (volendo scomodare impropriamente i design pattern, tutto ciò potrebbe ricordare l'adapter per es.)

Queste due funzioni andranno collocate in .bashrc (o .profile o .bash_profile, dipende dalla vostra configurazione) e richiamate attraverso il PROMPT_COMMAND in modo che, prima di ogni visualizzazione del prompt, si esegua il merge come volevamo

3. creazione script

In .bashrc:

...
history(){
  syncHistory
  builtin history "$@"
}
 
syncHistory(){
  builtin history -a
  HISTFILESIZE=$HISTFILESIZE
  builtin history -c
  builtin history -r
}
...
PROMPT_COMMAND=syncHistory

Appendice

terminale vs. shell vs. emulatore di terminale Quando ci si vuole sentire fighi e veri hacker, confessando con un falso senso di colpa e una strizzatina d'occhio, “di lavorare solo aprendo delle shell”, commettiamo due piccole leggerezze:

• si dice una sciocchezza
• se la contrazione intrinseca nella frase “aprire una shell” non è voluta, allora non si ha nessuna idea di quello che si sta facendo.

1. La shell è un interprete di comandi (bash, dash, ksh, csh, zsh ecc.) e basta. Come può esserlo python per es. Mai sentito dire: “ora apro un bel python”, al di là del senso vagamente inquietante della frase.
2. Un terminale reale è una console collegata ad uno pseudo-dispositivo tty, collegato a sua volta fisicamente ad una porta seriale.
3. Un terminale virtuale in ambienti *nix è una console collegata ad uno pseudo-dispositivo tty virtuale (note anche come “console tty”) che permette di eseguire una shell all'interno di una sessione X. Di solito accessibili con CTRL-ALT-Fn (per n=1..7 ma comunque configurabile).
4. Infine, quando si “apre una shell”, quello che si fa in realtà al 99,9999%, è aprire un emulatore di terminale (xterm, Gnome Terminal, Konsole, Iterm2, PuTTY, ecc.), ossia un terminale virtuale all'interno di un ambiente grafico, su cui eseguire una shell come per i terminali reali/virtuali.

Ulteriore suddivisione può essere operata considerando la tipologia di sessioni aperte e la possibilità o meno di disporre di un accesso al sistema.

• Il terminale virtuale esegue una shell interattiva con login (o shell di login). È ciò che avviene quando non si dispone di un login manager come KDM, GDM, LightDM ecc. che sono shell di login con GUI.
• L'emulatore di terminale permette di eseguire invece una shell interattiva senza login.
• L'esecuzione di uno script invece eseguirà una shell non interattiva.

Quindi “eseguo” una shell, la “uso”. Ma non la “apro”, pur essendo una “conchiglia”.

#bash #shell