Question

Some issue arise when sourcing one of your env file (a series of variable exporting)

for instance:

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

results in

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

=> "/bin" seems to overwrite the begining of the variable instead of suffixing it..

Any idea?

By the way every time we source this file, an error message is reported:

": Command not found"

Which is weird.. This message appears even though we comment its whole content.

The invoked shell at the begining seems good #!/bin/sh, or #!/bin/bash.

What about control characters? How to screen them on linux?

Was it helpful?

Solution

This will fix the line endings in the file:

dos2unix my_env.sh

There's no need for a shebang in a file that's only going to be sourced since it is run in the current shell anyway. However, as a comment it might be informative for human readers.

OTHER TIPS

": Command not found" is the error I've seen when a UNIX/Linux shell script has been (mis-)handled by an MS Windows system. For example if it was checked out using a WebCVS, modified using Notepad or WordPad, and then re-submitted.

(It's complaining that it can't find the [Ctrl-M] executable --- which is a perfectly valid, though extremely inconvenient and somewhat suspicious filename for UNIX/Linux).

Run the file through GNU cat -A or the od -x or hexdump commands to see these (and verify my diagnosis ... or run it through tr -d with the appropriate quoting and shell "verbatim" handling for your system. (For example tr -d '[Ctrl-V],[Ctrl-M]' under Bash on a typical Linux system).

Depending on your version of tr you might be able to use: tr -d '\r' or tr -d \015 (015 is the octal for CR, "carriage return" or ^M --- MS-DOS used to used CR/LF pairs as line termination, which is just one of the many reasons that MS-DOS can rot in the forsaken abyss when it comes to interoperability. Line terminators of single characters cause no real issues for anyone else ... but PAIRS cause real conversion issues when everything else in the history of mainstream computing used single characters for this).

Oh, yeah, vim has a handy set ff (a.k.a. set fileformat option which can handle UNIX, MacOS, and MS-DOS line termination conventions from any copy of vim regardless of which platform you're on. I seem to recall the vim default is to detect which types of line termination a file is using and leave it unchanged (and to default to your platform's native for any new files, of course).

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top