": Comando no encontrado"

Question

Algunas problema surge al comprar uno de su archivo de env (una serie de variables de exportación)

por ejemplo:

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

resultados en

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

=> "/ bin" parece sobrescribir el comienzo de la variable en lugar de un sufijo a ella ..

¿Alguna idea?

Por cierto cada vez que nos fuente de este archivo, se informa de un mensaje de error:

": Command not found"

Lo que es raro .. Este mensaje aparece aunque se comenta todo su contenido.

La cáscara invocado en el comienzo parece buena #!/bin/sh, o #!/bin/bash.

¿Qué pasa con los caracteres de control? Cómo detectar ellos en Linux?

Answer 1

Esto solucionará los finales de línea en el archivo:

dos2unix my_env.sh

No hay necesidad de un tinglado en un archivo que sólo va a ser de origen ya que se ejecuta en el shell actual de todos modos. Sin embargo, como un comentario que podría ser de carácter informativo para los lectores humanos.

Answer 2

": Comando no encontrado" es el error que he visto cuando un script de shell de UNIX / Linux ha sido (mal) manejado por un sistema MS Windows. Por ejemplo, si se desprotegió utilizando una WebCVS, modificado usando el Bloc de notas o WordPad, y luego volver a presentar.

(Se queja de que no puede encontrar el [Ctrl-M] --- ejecutable que es un perfectamente válido, aunque el nombre de archivo extremadamente incómodo y algo sospechoso para UNIX / Linux).

Ejecutar el archivo a través cat -A GNU o la od -x o comandos hexdump para ver estos (y verificar mi diagnóstico ... o bien puede hacerlo a través tr -d con la adecuada cotización y Shell "Verbatim" manejo para el sistema. (Por ejemplo tr -d '[Ctrl-V],[Ctrl-M]' bajo bash en un sistema típico de Linux).

Dependiendo de la versión de tr es posible que pueda utilizar: tr -d '\r' o tr -d \015 (015 es el octal para CR, "retorno de carro" o ^ M --- MS-DOS utiliza para utilizado pares CR / LF como terminación de línea , que es sólo una de las muchas razones que MS-DOS puede pudrirse en el abismo abandonado cuando se trata de la interoperabilidad. los finales de línea de caracteres individuales no causan problemas reales para cualquier otra persona ... pero los pares causan problemas de conversión real cuando todo lo demás en la historia de la corriente principal de la computación utilizado caracteres individuales para esto).

Sí, vim tiene un set ff mano (opción alias set fileformat que puede manejar UNIX, MacOS, y MS-DOS convenciones de terminación de línea desde cualquier copia de vim independientemente de la plataforma que se encuentra. Creo recordar que el valor por defecto vim es detectar qué tipos de terminación de línea un archivo está utilizando y se deja sin cambios (y por defecto a nativo de su plataforma para los archivos nuevos, por supuesto).