FaciLinux

Guide Facili per Linux

Orage è lo strumento di calendario presente e integrato nel desktop Xfce. Supporta le notifiche native all'interno del desktop, ed è molto leggero. Purtroppo però Orage funziona solo con file locali, e non è quindi possibile puntare direttamente a risorse webdav. Con un semplice script e un po' di configurazione è però possibile fare in modo che orage legga, in sola lettura, gli appuntamenti pubblicati nei calendari di NextCloud. Ecco come fare:

  • Portarsi nel proprio account Nextcloud, sezione calendari, e cliccare il menu a tendina del calendario che si intende usare

menu cal nextcloud

  • Cliccare il menu, portarsi con il mouse sulla voce "Scarica"

menu Scarica

  • Cliccare con il tasto destro del mouse e selezionare "copia indirizzo" menu copia indirizzo

A questo punto è possibile utilizzare wget per scaricare il calenadrio, utilizzando questa sintassi:

wget --http-user=<netxcloud-user> --http-passwd=<password> -O <file-locale.ics> <URL REMOTO>

Il download del calendario può essere automatizzato con la frequenza desiderata, creando uno script bash e aggiungendolo al proprio contab personale.

A questo punto occorre configurare Orage.

  • Aprire Orage
  • Cliccare su File > Scambio Dati
  • Selezionare il Tab "File esterni"
  • Aggiungere il file esterno precedentemente scaricato con wget, con l'accortezza di spuntare l'opzione "Sola lettura" cal orange

Ora Orage è configurato: è possibile scegliere il tipo di notifica che si desidera che appaia (dal menu Modifica > Preferenze); personalmente mi sembra più elegante la notifica del desktop rispetto alla finestra di Orage. notifiche orage

Non rimane che aggiungere il plugin di Orage al pannello di Xfce per avere sempre sottomano i propri calendari di Nextcloud.

Ovviamente i calendari sono disponibili in sola lettura, e le modifiche sono da fare sempre via interfaccia web di Nextcloud; personalmente però mi sembra un buon compromesso per avere gli avvisi degli impegni pianificati, integrati nel sistema, anche senza tenere sempre aperti programmi dedicati (qualcuno ha detto thunderbird con tbsync?).

Gestire i dotfiles

- Posted in tools by

Molti programmi su GNU/Linux usano memorizzare la loro configurazione nella $HOME usando uno o più dotfile (cioè file che iniziano con un punto, come ad esempio .bash_aliases o .vimrc) oppure salvandoli nella directory .config o directory ad hoc (come ad esempio Atom nella directory .atom, KDE nella directory .kde).

Spesso viene dedicato molto tempo alla configurazione e alla personalizzazione dei propri dotfile.\ Pertanto, quando si passa a una nuova macchina o si reinstalla il nostro sistema operativo, è molto importante poter ripristinare facilmente e velocemente tutti quei file di configurazione.

Soluzioni utilizzando il versioning di git

Directory $HOME come repository git

La prima soluzione è rendere l'intera directory $HOME un repository git. Questa può sembrare una soluzione semplice e buona, anche se dobbiamo stare attenti ai sub-repository e, soprattutto, non sarà semplice ripristinare il repository su una nuova macchina (poiché la cartella $HOME esiste già).

Repository separato e link simbolici

Per superare gli inconvenienti dati dal rendere la cartella $HOME un repository git, si può mettere il repository git con i dotfile altrove (ad esempio in $HOME/ dotfiles) e quindi ricollegare i file di configurazione all'interno della cartella $HOME attraverso link simbolici.

L'unico aspetto negativo è che su una nuova macchina dobbiamo collegare manualmente tutto al posto giusto e potrebbe essere un po' noioso.

Per questo motivo, quando si utilizza questo metodo, è una buona idea automatizzare la gestione dei link simbilici, ad esempio utilizzando GNU Stow.

Bare git repository

Un bare git repository consente di mantenere le directory working tree e .git in posizioni differenti.

Questo è molto simile al primo metodo, tranne per il fatto che la cartella .git non si trova direttamente nella cartella $HOME ma risiede, ad esempio, in ~/.config/dotfiles.\ Questo comporta che

  • evitiamo tutti i possibili problemi con i repository nidificati
  • non utilizziamo collegamenti simbolici

Sfortunatamente, come nel primo metodo, non è semplice clonare il repository quando la cartella $HOME esiste già.

vcsh

vcsh (Version Control System for $HOME) permette di avere diversi repository, che mantengono i loro working tree nella directory $HOME senza interferenze reciproche.\ Per impostazione predefinita, tutti i repository git gestiti tramite vcsh memorizzano i file effettivi in $HOME (ma è possibile modificare questa impostazione).

Ciò permette di avere un repository per applicazione o famiglia di applicazioni, ad esempio zsh, vim, ssh, ecc. Ciò, a sua volta, consente di clonare set personalizzati di configurazioni su macchine diverse o anche per utenti diversi e selezionare quali configurazioni si desidera utilizzare dove. Ad esempio, potresti non aver bisogno di avere la tua configurazione di mplayer su un server e potresti voler mantenere una configurazione diversa per ssh sulle tue macchine personali e di lavoro.

In particolare vcsh presenta i seguenti vantaggi:

  • cli più semplice: non è necessario ricordare comandi git complessi o definire alias su una nuova macchina
  • UX migliore: nessun problema nel clonare i dotfile quando la cartella $HOME esiste già o non è vuota
  • supporto perfetto per più repository: non è necessario definire un alias per ciascun repository

vcsh e mr

myrepos è uno strumento per gestire più repository di controllo versione, che funziona molto bene con vcsh.\ myrepos fornisce un comando mr, che è uno strumento unificato per gestire tutti i repository di controllo versione.

Questo metodo è più complesso da configurare rispetto al semplice vcsh (anche se è necessario eseguire questa configurazione una sola volta).

I punti di forza di questo metodo sono:

  • la possibilità di utilizzare script custom che vengono eseguiti al momento del checkout/update
  • la possibilità di fare il checkout dei repository in un percorso diverso dalla $HOME

Firefox e Thunderbird con Wayland

- Posted in linux by

Sia Firefox sia Thunderbird si avviano di default con il collaudato (e per certi versi obsoleto e insicuro) protocollo X11 per la gestione delle finestre.

È però possibile, con versioni recenti dei due prodotti, forzare l'avvio con Wayland, impostando una variabile d'ambiente.

Per firefox il comando da eseguire è:

MOZ_ENABLE_WAYLAND=1 firefox

Per thunderbird, similmente, occorre digitare:

MOZ_ENABLE_WAYLAND=1 thunderbird

È possibile verificare in firefox quale gestore di finestre si sta usando digitando sulla barra degli indirizzi about:support e cercando il valore per la variabile "Protocollo finestra" ("Window protocol" per la versione inglese)

enter image description here

Ultimamente mi è capitato di dover lavorare con file di testo generati da script powershell, in particolare dall'utility Out-File.

Il problema che ho trovato è stato nell'encoding del file generato da Powershell, che nel mio caso era UTF16-Little Endian, un encoding che mal si sposa con le utility di parsing dei file della bash.

Per scoprire con quale encoding ci stiamo confrontando, ci viene in aiuto il comando file; infatti Out-File supporta parecchi encoding in output (https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/out-file?view=powershell-6#parameters), quindi nel caso questa guida è da aggiustare con l'encoding che fa al caso vostro.

Il primo passo, come detto, è scoprire con quale encoding si ha a che fare:

[user@pc ~]$ file -i output_powershell.txt 
output_powershell.txt: text/plain; charset=utf-16le

La desiderata è di ottenere un file in UTF8, con i carriage return di linux, ed ecco come fare:

iconv -f UTF-16LE -t UTF8 output_powershell.txt | dos2unix > converted_output.txt

In caso manchi l'utiliy dos2unix è possibile installarla con il proprio gestore di pacchetti; per Arch ad esempio il comando è

sudo pacman -Su dos2unix

Il nostro file convertito è ora un ottimo candidato per passare sotto altri strumenti di parsing.

Buon lavoro!

Gli utenti di Gnome e KDE possono godere di azioni di crittazione/decrittazione di file direttamente dai rispettivi filemanager, cliccando con il tasto destro del mouse sul file interessato.
Thunar, il FileManager di Xfce, non presenta questa funzionalità integrata ma, grazie alle “Azioni personalizzate”, è possibile estenderne il comportamento; vediamo come fare.

Prerequisiti

Innanzitutto è necessario installare i pacchetti necessari; per Debian/Ubuntu il comando da dare è:

user@debby:~$ sudo apt install seahorse seahorse-nautilus seahorse-daemon

Seahorse è un’interfaccia grafica per gestire le chiavi GPG negli ambienti Gnome/Gtk, mentre del pacchetto seahorse-nautilus ci serve il binario seahorse-tool, come vedremo più avanti.

Azione personalizzata “Cifra..”

  • Aprire Thunar e selezionare il menu Modifica > Imposta azioni personalizzate, quindi:
  • Premere sul pulsante +
  • Nel campo Nome inserire “Cifra…”
  • Nel campo Descrizione inserire “cifra con GPG”
  • Nel campo Comando inserire “seahorse-tool -e %F”
  • Selezionare un’icona a proprio piacimento
  • Nel tab “Condizioni di visibilità” selezionare tutte le tipologie di file, escludendo le cartelle e come “Schema del file” mantenere il predefinito “*” Dato che un video vale più di mille parole, ecco qui sotto il riepilogo di quanto fatto: Azione personalizzata "Cifra..."

Azione personalizzata “Decifra..”

  • Aprire Thunar e selezionare il menu Modifica > Imposta azioni personalizzate, quindi:
  • Premere sul pulsante +
  • Nel campo Nome inserire “Decifra…”
  • Nel campo Descrizione inserire “decifra con GPG”
  • Nel campo Comando inserire “seahorse-tool -d %f”
  • Selezionare un’icona a proprio piacimento
  • Nel tab “Condizioni di visibilità” selezionare solo “Altri file” e come “Schema del file” impostare “.gpg;.pgp” Anche in questo caso ecco qui sotto il riepilogo a video di quanto fatto: enter image description here