In breve: ecco come abilitare la bash su Windows 10 in 3 semplici passaggi.

Windows 10 Anniversary è qui e come sapete ha anche qualche problemino.

Una delle nuove funzioni che vengono introdotte in questo nuovo aggiornamento è la bash per Windows, ve ne avevamo già parlato qui. Microsoft lo definisce “Windows Subsystem for Linux” e Dustin Kirkland l’ha già rinominata come “l’inverso di Wine”.

Per abilitare la Bash i passaggi sono abbastanza semplici ed intuitivi, prima pero’ due rapide delucidazioni:

  • Non è una macchina virtuale;
  • Non è un container;
  • Non è una distro Linux.

Ma allora cos’è?

E’ un modo, pensato da Canonical in collaborazione con Microsoft, per eseguire applicazioni Linux (e i comandi Bash) nativamente su Windows. Per essere (poco) chiari funziona grazie ad un’interfaccia compatibile col kernel Linux. Chiaramente questo subsystem richiede meno risorse rispetto all’uso di un qualsiasi sistema operativo in macchina virtuale.

Detto cio’ possiamo iniziare con la mini-guida.

PRIMO PASSO : Attiviamo la modalità sviluppatore

Il primo passo da compiere è quello di attivare la modalità sviluppatore, o dev mode, che ci consente di installare qualsiasi app firmata e di utilizzare funzionalità di sviluppo avanzate.
Andiamo su Impostazioni di Windows > Aggiornamento e sicurezza > Per sviluppatori
Spuntiamo la voce chiamata > Modalità sviluppatore. Date conferma in caso di pop-up.
La modalità sviluppatore verrà ora installata e, al termine dell eoperazioni, riavviate il pc.
step-1-bash-on-windows

SECONDO PASSO: Attiviamo il sottosistema Windows per Linux

Dobbiamo installare la Bash. Nel menu start cerchiamo Programmi e funzionalità
programmi e funzionalità
Nella nuova schermata che ci si presenterà selezioniamo la voce Attivazione o disattivazione delle funzionalità di Windows.

Una volta fatto si aprirà una finestra di popup, Spuntiamo la voce Sottosistema Windows per Linux (Beta) e clicchiamo su Ok.

Ora partirà l’installazione della bash di Ubuntu su Windows. Una volta terminato il processo dovremo riavviare il PC.
windows-bash-step-2
TERZO PASSO: Completiamo l’installazione
Una volta riavviato il PC dal menu start cerchiamo Bash e lanciamo la Bash di Ubuntu.
bash-windows-step-4
A questo punto il sistema provvederà a scaricare i restanti file e a completare l’installazione della bash di Ubuntu su Windows 10.
step-5-ubuntu-on-bash-on-windows
Durante il processo vi verrà chiesto di scegliere il vostro nome utente UNIX e la password.
bash-1

E ora?

Usando la Bash vi sarà possibile utilizzare comandi quali grep, sed, awk, vi, emacs, nano, ssh, etc.

Vi ricordo che non potete aprire o modificare (nè tantomeno modificare) applicazioni Windows con questo metodo. Non è possibile modificare nemmeno impostazioni di Windows o chiavi di registro.

Lo proverete? Che ne pensate?

  • Samael

    Staff, potreste togliere dalla moderazione il commento, per favore? Diventa veramente frustrante dover stare ogni volta a sperare che i propri post, anche se non contengono spam o altro, non vengano moderati e lasciati lì a marcire.

    Ho scritto un post in cui spiegavo il WSL anche un po’ nel dettaglio. Per favore, toglietelo dalla moderazione.
    E giacché colgo l’occasione per invitarvi a cambiare le policy relative alla moderazione dei commenti. In altri blog non c’è il blocco degli URL o casi di falsi positivi come questo, probabilmente perché hanno regole meno restrittive. Non si potrebbe fare qualcosa anche qui?

  • MoMy

    Mi accodo alla richiesta di @disqus_6kdfBr2BEC:disqus in più aggiungo la richiesta di sistemare la parte relativa ai messaggi disqus ove il link riporta all’ articolo e non al corpo del messaggio. Bye ^^

  • Ansem The Seeker Of Darkness

    Si potrà usare il bash per usare hard disk formattati in ext4, o comunque FS differenti da quelli windows?

    • Samael

      No, perché non è un kernel Linux, ma uno userland Ubuntu che gira sul kernel NT tramite traduzione di syscall.

      Il VFS incluso in Windows Subsystem for Linux è minimo e serve solo agli pseudo-fs /proc e /sys.

      Nel futuro non si sa, ma la vedo molto dura.

      • Ansem The Seeker Of Darkness

        peccato 🙁 sto punto non vedo che gran vantaggio porti, alla fine per ssh è molto più leggero usare putty o un suo fork

        • Samael

          Come ho scritto sopra è utile se devi lavorare su Python, Node, Ruby ecc.
          Tutti questi software girano principalmente su Linux/UNIX e la comunità ha ottimizzato sia le piattaforme che le librerie esterne per questi OS.
          Windows è trattato come un elemento di seconda classe, per non dire peggio.

          Questo ha fatto sì che una buona parte di DevOps e sviluppatori di soluzioni server-side cominciassero a vagliare una migrazione ad OSX o Linux per ottenere un buon supporto.
          E d’altronde non gli puoi nemmeno dare torto: loro devono comunque deployare su server Linux. Tanto vale mettere Linux sul desktop ed evitare di sbattersi nel far funzionare un ambiente di sviluppo su Windows.

          Su Ruby per esempio tra DevKit e flag da passare alle gem che devi compilare c’è da mettersi le mani nei capelli.
          Git gira da sempre più veloce su Linux e Linux riceve un supporto di prima classe. Docker è Linux-only.

          Quindi a che pro usare Windows?
          Essendo che Microsoft ha bisogno di Windows sul desktop per evitare di scomparire, in quanto gli serve per veicolare i suoi servizi (Azure), ha deciso di cercare di porre un freno alla fuga degli sviluppatori mettendo il WSL.
          Questo è anche il motivo per cui ha aggiunto capacità di compilazioni remote a Visual C++, in modo da chiamare gcc e compilare binari Linux direttamente da Windows.
          In sostanza, Microsoft non vuole perdere il desktop del futuro, che sarà sempre meno consumer e sempre più prosumer.

          • Ansem The Seeker Of Darkness

            capito, grazie mille!

  • Samael

    Onestamente la spiegazione su cos’è il WSL non è molto chiara, ma capisco bene che sia un argomento piuttosto complicato.

    Windows Subsystem for Linux (WSL) si basa su una traduzione di syscall.
    Bene, immaginate di andare in un paese straniero e di non parlare la lingua del posto. Come si può fare per comunicare? Ci sono due modi.

    1) fare gli italiani.
    – “Capo, what… cost… this… maglietta”
    – “I’m sorry, but I don’t understand what you’re saying.”
    – “This… la maglietta. Cost! (*gesto dei soldi con la mano*) Quanto?”

    2) chiamare un interprete.
    L’interprete ascolterà le vostre parole e le tradurrà all’interlocutore, e viceversa.
    Ecco, questo è esattamente ciò che fa WSL. Ogni applicazione per Linux usa syscall Linux, ovvero usa funzioni tipiche del nostro kernel per chiedere le risorse ecc. WSL intercetta queste chiamate e le traduce in chiamate proprie di NT (il kernel di Windows) affinché questo le recepisca e risponda di conseguenza.

    PS: per il problema di prima, ci sarebbe anche una terza via: studiare un po’ d’inglese; ma vabbe’…

    —————–
    Detto questo, scendiamo un po’ nel dettaglio (da qui in poi il focus è sugli utenti più esperti)

    In realtà non è affatto un metodo pensato da Canonical, perché questo è come lavora Windows di suo. Canonical l’ha solo sviluppato insieme a Microsoft.
    Windows è un sistema operativo composto da due parti separate: il kernel ed il subsystem Win32.
    Il subsystem Win32 è praticamente il Windows che tutti conosciamo.
    Quando si sviluppano applicazioni si usano le API di Win32. Queste API sono indipendenti dal kernel di Windows, tant’è che necessitano anch’esse di traduzione. NT riconosce solo il SUO set di API: Native API.
    Quando si chiama un’applicazione essa avrà syscall Win32 che vengono intercettate dal subsystem e tradotte in Native API.
    Su Windows non si scrivono quasi mai applicazioni che fanno chiamate dirette alle Native API per ridurre il gap prestazionale, perché sono per design offuscate. Non c’è una documentazione, e gli unici modi per capire come usarle sono:
    1) Affidarsi a reimplementazioni tipo WINE o ReactOS, rischiando di ritrovarsi con API obsolete;
    2) Fare reverse engineering.

    Detto questo, la traduzione di syscall Linux nelle alternative native non è niente di trascendentale. Altri sistemi operativi lo facevano già, tipo FreeBSD, SmartOS e OpenBSD (che l’ha rimossa recentemente).
    FreeBSD, per esempio, è ancora più elegante.
    Windows non può avviare applicazioni Linux direttamente, perché non ne riconosce il formato binario (NT usa PE, Linux e gli UNIX – eccetto OSX – usano ELF) e perché non riconosce il numero magico.
    Vi siete mai chiesti perché Windows fa ancora uso delle estensioni per capire con che tipo di file si sta avendo a che fare? Ecco, proprio per questo motivo.
    Il numero magico altro non è che una stringa presente nell’intestazione (i primi bit) dei binari. I sistemi UNIX leggono questo numero magico e usano l’interprete adeguato (ld-linux . so per i binari Linux).
    Tutti voi avrete usato almeno una volta un numero magico: lo shebang. #!/path/interprete è un numero magico che difatti va messo nell’intestazione del vostro script. Una volta messo il vostro file verrà identificato correttamente a prescindere dall’estensione.
    Windows non potendolo identificare deve usare un wrapper che lo legga e dica al sistema operativo che d’ora in avanti devono essere messi su i driver del subsystem (lxcore.sys/lxss.sys). Questo wrapper si chiama bash.exe. Nello screenshot sopra avete visto che dalla barra di Cortana è stata chiamata bash. Ma quella non è la bash di Linux, bensì il wrapper C:WindowsSystem32bash . exe che metterà su il subsystem, farà bind mount dei volumi di Windows in /mnt, metterà su degli pseudo-fs compatibili in /proc e /sys, lancerà una funzione chroot() in C:Users$VOSTRO_NOME_UTENTEAppDataLocallxssrootfs e poi chiamerà /bin/bash.
    Quindi concettualmente sì, non è poi tanto diverso da un container, anche se ha finalità differenti.
    Questo però vuol dire che le applicazioni Linux non potranno essere eseguite da fuori l’ambiente gestito da bash.exe.
    In sostanza è la stessa cosa che avviene con noi su WINE, di cui WSL è la controparte. Con WINE le applicazioni Windows vengono eseguite nel subsystem presente in ~/ . wine e non sono accessibili nativamente.
    Le differenze tra WINE e WSL sono che noi avviamo il subsystem con la singola transazione: ovvero, wine /path/binario. Su WSL invece si avvia bash.exe ed si accede alla console.
    L’altra differenza è che WSL fa traduzione delle syscall, mentre WINE no; o meglio non proprio. Il subsystem WINE fa capo ad un server centrale che replica il funzionamento di NT, ma che viene eseguito completamente in userspace: wineserver.
    In sostanza le applicazioni Windows che girano su WINE chiamano il subsystem Win32, come vi ho spiegato sopra; quest’ultimo traduce le chiamate in Native API tramite NTDLL, che a sua volta chiama il kernel ntoskrnl.exe. Solo che ntoskrnl.exe altro non è che un fantoccio, poiché il vero kernel è wineserver. Questo prende tutte le chiamate NT e, come una normale applicazione Linux, chiede le risorse al nostro kernel.
    Per questo a volte su WINE le applicazioni sono un po’ più lente, mentre WSL è praticamente a velocità nativa.
    Perché WINE opera completamente in userspace e chiede risorse come una normale applicazione Linux, mentre WSL è un driver che opera in kernel space.

    FreeBSD, come dicevo sopra, opera in maniera ancora più elegante.
    Essendo che entrambi i sistemi operativi fanno uso di formato binario ELF, entrambi hanno una voce nell’intestazione, chiamata brand.
    Essendo che Linux discende idealmente da UNIX System V ne ha ereditato il brand, che difatti è “UNIX – System V”.
    Per farvi un’idea date in un terminale readelf -h /bin/bash e leggete la dicitura SO/ABI.
    FreeBSD ha una dicitura personale per i suoi binari: il suo stesso nome.
    Quindi quando il loader dei binari di FreeBSD legge l’intestazione e vede che nel brand c’è scritto “FreeBSD”, allora sa che quello è un binario nativo e fine. Quando invece trova “UNIX – System V” allora capisce che è un binario Linux e lo esegue nella jail (la tecnologia di containerizzazione di FreeBSD) contenente una copia di CentOS 6 (prima Fedora 10).
    Naturalmente le cose non vanno sempre bene. Ci sono infatti binari Linux sbrandizzati e che FreeBSD di conseguenza non riesce a leggere. Per questi motivi loro hanno inventato un tool chiamato brandelf, che permette di applicare un brand custom chiamato “Linux” rendendo il binario di nuovo identificabile ed eseguibile.

    • Samael

      Sono riuscito a ripubblicarlo.
      Come al solito era un problema di falso positivo legato alla presenza dei “.”, che vengono scambiati per siti web e cadono vittima dei meccanismi di anti-spam.

      Colgo nuovamente l’occasione per rinnovare l’invito a cambiare le policy di moderazione. Questi falsi positivi sono la prova che le regole sono talmente restrittive da risultare dannose per tutti.

  • Stoccafisso

    non credo di utilizzare questa funzione. uso linux per quasi tutto e il windows 10 per un solo programma di scrittura musicale.

  • Samael

    STAFF:
    Scrivete immediatamente la news del giorno! 🙂

    PowerShell è open source ed è stata portata su Linux e Mac OS X!
    h t t p s : / / azure . microsoft . com/en-us/blog/powershell-is-open-sourced-and-is-available-on-linux/

No more articles