": Comando non trovato"

Question

Alcuni questione sorgono nell'acquisto di uno dei file ENV (una serie di esportazione variabile)

Per esempio:

...
export MY_ROOT=/Soft/dev/blah/blah
export MY_BIN=${MY_ROOT}/bin
...

risultati in

$. my_env.sh
$echo $MY_BIN
/bint/dev/blah/blah

=> "/ bin" sembra sovrascrivere l'inizio della variabile invece di suffisso esso ..

Qualche idea?

Tra l'altro ogni volta che noi fonte questo file, viene segnalato un messaggio di errore:

": Command not found"

che è strano .. Questo messaggio viene visualizzato anche se noi commentiamo tutto il suo contenuto.

La shell invocata agli inizi sembra buono #!/bin/sh o #!/bin/bash.

Che dire di caratteri di controllo? Come per lo screening di loro su linux?

Answer 1

Ciò risolverà la fine riga nel file:

dos2unix my_env.sh

Non c'è alcun bisogno di una baracca in un file che sta solo andando a essere di provenienza in quanto viene eseguito nella shell corrente in ogni caso. Tuttavia, come un commento che potrebbe essere informativo per i lettori umani.

Answer 2

": Command not found" è l'errore che ho visto quando uno script di shell UNIX / Linux è stato (mis-) gestito da un sistema MS Windows. Ad esempio, se è stata estratta utilizzando un webCVS, modificata utilizzando Blocco note o WordPad, e poi ri-presentato.

(Si dice che non è in grado di trovare il [Ctrl-M] eseguibile --- che è un perfettamente valida, anche se il nome del file estremamente scomodo e un po 'di sospetto per UNIX / Linux).

Esegui il file tramite GNU cat -A o od -x o comandi hexdump vedere questi (e verificare la mia diagnosi ... o correre attraverso tr -d con l'appropriato citando e shell "testualmente" la gestione del sistema. (Per esempio tr -d '[Ctrl-V],[Ctrl-M]' sotto bash su un tipico sistema Linux).

A seconda della versione di tr si potrebbe essere in grado di utilizzare: tr -d '\r' o tr -d \015 (015 è l'ottale per CR, "Carriage Return" o ^ M --- MS-DOS utilizzato per utilizzato coppie CR / LF come terminazione di linea , che è solo uno dei tanti motivi che MS-DOS può marcire nell'abisso abbandonata quando si tratta di interoperabilità. terminatori riga di caratteri singoli non causano problemi reali per chiunque altro ... ma COPPIE causare problemi reali di conversione quando tutto il resto in la storia della corrente principale di calcolo utilizzato singoli caratteri per questo).

Oh, sì, vim ha un set ff a portata di mano (opzione aka set fileformat in grado di gestire UNIX, MacOS, e le convenzioni di terminazione della linea MS-DOS da qualsiasi copia di vim a prescindere di quale piattaforma si è in. mi sembra di ricordare il default vim è quello di individuare quali tipi di terminazione di linea di un file sta usando e lasciarlo invariato (e di default per nativo della vostra piattaforma per tutti i nuovi file, ovviamente).