Windows Terminal è una versione modernizzata dell’interfaccia a riga di comando di Windows. Come spesso accade, Microsoft è arrivata buona ultima nella inclusione di un terminale moderno e versatile per il suo sistema operativo, ma le si deve dare atto di averci messo impegno. Lo ha fatto con un progetto open-source, il che è già un buon inizio, e con un buon coinvolgimento della comunità.
Il repository del progetto sitrova su GitHub mentre il blog per tenersi aggiornati sulle novità è nella area DevBlog .
In questo articolo vorrei condividere alcuni piccoli dettagli che possono aiutare a rendere produttivo il lavoro con questo strumento, dettagli da aggiungersi a questo utile post.
La configurazione del terminale si esegue tramite l’apposito file JSON accessibile dal menu con la freccia in basso. Si può ovviamente usare qualsiasi editor di testo per modificarlo, anche se è preferibile usarne uno con la sintassi evidenziata per semplificare la digitazione.
Il file non si adegua esattamente allo standard JSON in quanto quest’ultimo non prevede i commenti, mentre il file di configurazione di WT, invece, li include usando //: questo genera alcuni errori in un editor che verifica la sintassi JSON. L’utente deve ricordarsi di ingorarli.
// To view the default settings, hold "alt" while clicking on the "Settings" button.
// For documentation on these settings, see: https://aka.ms/terminal-documentation
{
"$schema": "https://aka.ms/terminal-profiles-schema",
"defaultProfile": "{GUID}",
"profiles":
{
"defaults":
{
// Put settings here that you want to apply to all profiles
},
"list": [
Il codice qui sopra è la prima parte della configurazione standard. All’interno dell’array “list” vengono elencati le voci di ognuna delle finestre che possono essere aperte in WT.
Per aggiungere una nuova voce, prima di tutto bisogna assegnarle un identificatore univoco nella forma di un GUID.
Ci sono vari modi per generarne uno: tramite una semplice ricerca si possono trovare diversi siti internet, inoltre si può generare tramite PowerShell con il comando
[guid]::NewGuid()
In sistemi LInux si può usare la utility uuidgen che fa parte del pacchetto uuid-runtime.
Una volta ottenuto l’identificativo, si può procedere a creare le proprie sezioni personalizzate.
Una cosa che io trovo molto comoda è la possibilità di avviare il “vecchio” interprete dei comandi, però con la opzione di auto completamento dei nomi di file e directory.
Ho aggiunto quindi una sezione così
{
// Make changes here to the cmd.exe profile
"guid": "{GUID}",
"name": "cmd /f:on",
"commandline": "cmd.exe /f:on",
"hidden": false
},Per qualche ragione il normale comando che si può digitare in “Run” di Windows non funziona ed è necessario aggiungere l’estensione .exe
Un altro uso interessante è quello di lanciare lo stesso interprete, però con privilegi elevati:
{
// Make changes here to the cmd.exe profile
"guid": "{GUID}",
"name": "cmd runas admin",
"commandline": "runas /user:administrator \u0022cmd.exe /f:on\u0022",
"hidden": false
},In questo caso è importante notare che il segno degli apici deve essere sostituito dal suo codice per essere incluso nel valore del parametro.
Windows 10 include anche un client per SSH, di conseguenza una interessante possibilità è includere un terminale verso un server remoto Linux, per esempio, direttamente in WT
{
// SSH local linux machine
"guid": "{GUID}",
"name": "SSH server Linux",
"icon": "https://www8.hp.com/it/it/images/i/hpi/header-footer/caas-hf-v3.2/hpi-favicon.ico",
"commandline": "ssh user@server",
"hidden": false
},In questo esempio vediamo un’altra interessante personalizzazione ovvero l’uso di una icona non necessariamente in un file locale. Per identificare visivamente questo server, ho usato l’icona del produttore: per evitare di salvare immagini localmente e mantenerle in caso di cambio di macchina, è possibile referenziare icone direttamente da internet.
WT è sicuramente un prodotto ancora acerbo è ha ampio spazio di crescita, tuttavia si tratta di uno strumento versatile per l’utilizzatore di Windows che permette di mantenere ordinate connessioni eterogenee all’interno dello stesso tool.
In particolare, mi piace focalizzare l’attenzione sulla immagine che mi sembra la più rappresentativa: un giorno tutte le pagine HTTP saranno trattate come Not secure. Ovvero, non sarà più HTTPS a essere una sicurezza in più, ma HTTP a esserne una in meno!