2015-04-13 13 views
5

Utilizzo la VM (nel mio caso semplicemente boot2docker) per eseguire contenitori docker su host Windows. Per motivi di convenienza, i miei file sorgente sono mappati dal file system host, quindi i file di testo sono per impostazione predefinita utilizzando terminazioni di linea CRLF in stile Windows anziché terminazioni LF in stile Unix.Bash - esecuzione senza problemi di script con terminazioni di linea CRLF

Quando provo ad eseguire alcuni file di Sh dal contenitore finestra mobile, vado a prendere un errore

bash: ./script.sh: /bin/bash^M: bad interpreter: No such file or directory 

C'è un modo come avrei potuto in qualche modo dire a bash/sh interprete per convertire automaticamente \ r \ n per \ n ed eseguire un file?

Certo, potrei fare qualche pipelelling come questo cat script.sh | tr -d "\r" | sh o persino creare un alias per questo, ma non coprirebbe la situazione in cui uno script ne include un altro.

L'unica soluzione accettabile che ho trovato finora è quella di impostare Git per il checkout dei file sorgente in formato UNIX.

+0

puoi postare 'echo $ TERM'? – user2915097

+0

È contenitore docker standard, 'echo $ TERM' restituisce' stupido' – trebi

+0

prova 'export TERM = xterm' o' exec>/dev/tty 2>/dev/tty user2915097

risposta

1

La soluzione migliore che ho è assicurarsi di utilizzare editor (come Notepad ++ o Sublime Text) in grado di salvare direttamente con lo stile eol corretto.

In questo modo, non è necessario il file dos2unix nella sessione boot2docker.

2

Per alcuni script la soluzione ln -s /bin/bash /bin/bash^M avrà esito negativo.
Quindi creare uno script/bin/bash^M che dos2unix gli argomenti che ottengono ed eseguirli con "[email protected]".

Edit: ho provato con il seguente bash^M script:

#!/bin/bash 
PROG=$1 
shift 
dos2unix $PROG > /dev/null 2>&1 
$PROG "[email protected]" 

Questo non riuscirà quando il vostro script include altri script con un punto, in questo caso si dovrebbe evitare questo work-around and go per il formato Unix.
Hai detto che puoi effettuare il checkout in formato Unix, oppure puoi auto modificare i file.
E commit in git, è un miglioramento avere unix file memorizzati in git in formato unix. Quando vuoi veramente modificarli sotto Windows, modifica le impostazioni del tuo editor o dos2unix in seguito.

+0

Sembra un approccio intelligente! Così, quando creo il file '/ bin/bash^M', mi libererò dell'errore' bash: ./script.sh:/bin/bash^M: interprete non valido: nessun file o directory ', ma lo farò introdurre un altro errore 'script.sh: riga 2: $ '\ r': comando non trovato', dove la riga 2 dovrebbe essere riga vuota, ma l'interprete pensa che esista un comando chiamato' \ r. – trebi

+0

Ecco perché bash^M non dovrebbe chiamare direttamente bash, ma prima dos2unix/tr lo script che deve essere eseguito. –

0

immagino si potrebbe scrivere uno script come

#!/bin/bash 
#bash_run_unixified 
#unixify and run in bash 
dos2unix < "$1" | /bin/bash 

e assumendo è stato salvato in/urs/local/bin/bash_run_unixified con le autorizzazioni appropriate (sudo chmod o+r,o+x), allora si potrebbe precedere i propri script con

#!/usr/local/bin/bash_run_unixified 
#This script has CRLFs in it 

Se non si desidera che tali linee shebang inusuali, si potrebbe

$ ln -s /usr/local/bin/{bash_run_unixified,bash} 

e quindi utilizzare (come Walter A. note, potrebbe essere una buona idea per collegarlo al bash^M troppo)

#!/usr/bin/env bash 

come la vostra linea shebang (/usr/local/bin/ è normalmente più vicino all'inizio del vostro $PATH di /bin quindi il comando env dovrebbe selezionare lo bash che collega a bash_run_unixified).

(Parola di cautela: non ho provato niente di tutto questo)

2

si può commettere un file .gitattributes nella repo nella cartella principale di dire automaticamente Git di applicare fine riga LF a tutti i file .sh al momento del check-out, anche su Windows. In questo modo tu o altri sviluppatori non devi ricordarti di configurare Git su ogni macchina in cui cloni il repository.

# Set line endings to LF, even on Windows. Otherwise, execution within Docker fails. 
# See https://help.github.com/articles/dealing-with-line-endings/ 
*.sh text eol=lf 
Problemi correlati