“：未找到命令”
在获取一个 env 文件（一系列变量导出）时会出现一些问题
例如，
...
export MY_ROOT=/Soft/dev/blah/blah
export MY_BIN=${MY_ROOT}/bin
...
：结果
$. my_env.sh
$echo $MY_BIN
/bint/dev/blah/blah
=> “/bin”似乎覆盖了变量的开头而不是为其添加后缀..
有什么想法吗？
顺便说一句，每次我们获取此文件时，都会报告一条错误消息：
": Command not found"
这很奇怪。即使我们注释了其全部内容，也会出现此消息。
开头调用的 shell 看起来不错 #!/bin/sh 或 #!/bin/bash。
那么控制字符呢？如何在linux上筛选它们？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
“：命令未找到”是我在 MS Windows 系统（错误）处理 UNIX/Linux shell 脚本时看到的错误。例如，如果使用 WebCVS 签出，使用记事本或写字板修改，然后重新提交。
（它抱怨找不到 [Ctrl-M] 可执行文件——这是一个完全有效的文件名，但对于 UNIX/Linux 来说非常不方便且有些可疑）。
通过 GNU cat -A 或 od -x 或 hexdump 命令运行文件来查看这些（并验证我的诊断...或运行通过
tr -d进行适当的引用和 shell“逐字”处理（例如tr -d '[Ctrl-V],[Ctrl-M]'）。在典型 Linux 系统上的 Bash 下，您可能可以使用
tr -d '\r'或tr，具体取决于您的（015 是 CR 的八进制，“回车”或 ^M --- MS-DOS 曾经使用 CR/LF 对作为行终止符，这只是 MS 的众多原因之一-当涉及到互操作性时，DOS 可能会在被遗弃的深渊中腐烂，单个字符的行终止符不会对其他人造成任何真正的问题......但是当主流计算历史上的其他所有内容都使用单个字符时，配对会导致真正的转换问题）哦tr版本 。 -d \015，是的，
vim有一个方便的set ff（又名set fileformat该选项可以处理任何vim副本中的 UNIX、MacOS 和 MS-DOS 行终止约定，无论您使用的是哪个平台。我似乎记得 vim 默认是检测文件正在使用哪种类型的行终止并保持不变（当然，对于任何新文件默认为您平台的本机）。": 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 -Aor theod -xorhexdumpcommands to see these (and verify my diagnosis ... or run it throughtr -dwith the appropriate quoting and shell "verbatim" handling for your system. (For exampletr -d '[Ctrl-V],[Ctrl-M]'under Bash on a typical Linux system).Depending on your version of
tryou might be able to use:tr -d '\r'ortr -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,
vimhas a handyset ff(a.k.a.set fileformatoption which can handle UNIX, MacOS, and MS-DOS line termination conventions from any copy ofvimregardless of which platform you're on. I seem to recall thevimdefault 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).这将修复文件中的行结尾：
在只需要获取源的文件中不需要 shebang，因为它无论如何都在当前 shell 中运行。然而，作为评论，它可能为人类读者提供信息。
This will fix the line endings in the file:
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.