关于-/bin/sh: 命令:not found的解决办法

本文详细介绍了在移植Linux内核和文件系统至mini2440开发板时,遇到-/bin/sh:/usr/bin/helloworld:notfound错误的原因及解决方法。通过查找和拷贝缺失的库文件libgcc_s.so.1和libc.so.6,最终成功运行helloworld程序。

原文: http://blog.chinaunix.net/uid-20539088-id-115759.html

关于mini2440上-/bin/sh: 命令:not found的解决办法

我按照mini2440的移植手册移植了linux内核和文件系统不同的是我用的交叉编译器是最新的4.4.1而没有用天嵌科技提供的交叉编译器,当我移植好了yaffs文件系统,想写个helloworld程序在开发板上测试下,我把编译好的helloworld文件放到yaffs文件系统的/usr/bin目录下,但当我运行/usr/bin/helloworld命令是提示“-/bin/sh: /usr/bin/helloworld: not found”,一开始我以为是helloworld没有运行权限,不过我给了它运行权限还是提示同样的错误。我在网上搜了下找到了原因:只所以提示“-/bin/sh: /usr/bin/helloworld: not found”这个,是因为我没有拷helloworld所需的库文件。那怎么才能知道helloworld需要哪些库文件呢,可以这样,在命令行输入arm-linux-readelf -a helloworld 命令然后在输出的内容中找到Program Headers:节这里就有helloworld所需的库文件(关于readelf可以参考这里< http://blog.youkuaiyun.com/eroswang/archive/2007/12/25/1967243.aspx>)如下图:
读者注: ($arm-linux-readelf -a helloworld | grep -A 20 "Program Headers" )
使用这个命令,定位更快。其中grep -A 20 表示打印匹配行后面20内容。

 
     看来我们需要ld-linux.so.3这个库,在你的交叉编译器中找到这个库文件把它拷到我们文件系统的/lib目录中然后烧到开发板中再次运行/usr/bin/helloworld结果提示“/usr/bin/helloworld: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory”有效果了,最起码不是前一个错误提示了,这就证明方法对头,我们看一下上面的错误这次直接提示所需的库文件了,我们按提示把libgcc_s.so.1拷到文件系统的/lib中,然后再次运行,又提示“/usr/bin/helloworld: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory”还是少库文件,我们再把这个也拷到文件系统的/lib中,这次总算是行了,终于看到“hello world”。
参考文章:< http://www.cnblogs.com/nick123/archive/2009/12/01/1614919.html>


====================================分割线=======================================

我遇到这个问题了,但是我记得之前已经将需要的库文件、连接器都已将拷贝好了,但是还是提示同样的问题

后来发现我拷贝的是3.4.5(韦东山)里面的库文件和连接器,而我后来些的字符设备测试程序使用4.4.3(mini2440)编译的,它们编译出来依赖的库不一样,so.....

我又重新用3.4.5版本的编译器重新编译了测试程序,然后就成功了。

注:我自己的交叉编译工具的PATH在/etc/profile文件中定义,修改后输入命令:$source /etc/profile 使得更改立即对当前shell生效,注意是当前shell,如果你更改之后没经历过重启,那么每次打开一个shell都要source 一下才能生效哦,这个要注意。




<think>我们正在处理用户的问题:“shell script error c not found”。根据用户描述,错误提示是“c: not found”,这通常表示脚本尝试执行一个名为“c”的命令,但系统找不到该命令。 结合引用资料和常见问题,可能的原因包括: 1. 脚本中存在Windows换行符(CRLF)导致解析错误(如引用[1][2][3]所述),但注意错误信息是“c: not found”,而不是“\r: command not found”,所以可能不是换行符问题。 2. 命令“c”确实不存在于系统中,可能是命令名称错误或路径问题。 3. 脚本中可能有一个变量扩展后形成“c:”开头的字符串,被当作命令执行。 然而,用户错误信息是“c: not found”,注意有一个冒号。在类Unix系统中,冒号(:)是一个特殊的命令(空操作,返回true)。但这里错误是“c: not found”,意味着系统试图执行一个名为“c:”的命令,而不是“:命令。 因此,我们需要检查脚本中是否有一行写的是“c:”或者类似的东西。常见的情况可能是: - 用户在脚本中写了Windows风格的路径,例如“c:\path\to\something”,但在类Unix系统中,这会被解释为命令“c:”后面跟着参数“\path\to\something”,而“c:命令不存在。 - 脚本中可能有一个拼写错误,将某个命令写成了“c:”。 解决思路: 1. 检查脚本中是否有“c:”这样的行,特别是在路径表示时。 2. 确保脚本中使用的命令在系统中存在,并且路径正确。 另外,根据引用[4]提到的“shell not found”错误,虽然不直接相关,但也提示我们注意脚本执行环境是否配置正确。 具体步骤: 1. 使用文本编辑器打开脚本,查找“c:”字符串。 2. 如果确实有“c:”这样的行,考虑将其修改为Unix风格的路径(如使用正斜杠,且避免使用盘符)或者检查命令拼写。 3. 如果脚本需要引用Windows路径,确保使用正确的转义或者使用其他方式(如挂载点)来访问。 例如,在类Unix系统中,通常没有C盘的概念,如果需要访问Windows分区,通常需要挂载到某个目录(如/mnt/c)。因此,在脚本中直接写“c:\path”是无效的。 如果用户是在Cygwin环境下(如引用[1]所述),那么C盘通常被映射到/cygdrive/c,所以应该使用“/cygdrive/c/path/to/file”的形式。 因此,建议用户检查脚本中是否有类似“c:\...”的路径,并修改为Unix风格路径。 如果没有发现明显的“c:”行,那么可能是变量扩展导致的,可以尝试在运行脚本时加上调试选项(如`bash -x script.sh`)来跟踪执行过程。 生成相关问题: 1. 如何将Windows路径转换为Cygwin下的路径? 2. 在Linux中如何访问Windows分区? 3. Shell脚本中如何避免命令未找到的错误? 4. 如何调试Shell脚本的执行? 5. 在Shell脚本中如何处理文件路径的跨平台兼容性?</think>### Shell 脚本报错 "c: not found" 的原因与解决方法 根据错误提示 "c: not found",结合引用资料分析,主要原因如下: 1. **Windows 换行符问题**(最常见原因) 在 Windows 创建的脚本包含 `\r`(回车符),而类 Unix 系统(Linux/macOS)无法识别。当脚本执行时,系统会将 `\r` 解释为命令的一部分,导致尝试执行名为 `c:` 的无效命令(错误信息中的 `c` 可能源自 `\r` 的误解析)[^1][^2][^3]。 2. **路径格式错误** 脚本中使用了 Windows 风格的路径(如 `c:\path\to\file`),在 Unix 系统中会被解析为执行命令 `c:`(后跟参数 `\path\to\file`),而 `c:` 不是有效命令[^3]。 3. **环境配置问题** CI/CD 环境(如 GitLab Runner)或容器中缺少 Shell 解释器,导致基础命令无法识别[^4]。 --- ### 解决方案 #### 方法 1:转换换行符(推荐) ```bash # 安装转换工具(Cygwin/Linux/macOS) sudo apt-get install dos2unix # Debian/Ubuntu brew install dos2unix # macOS # 转换脚本格式 dos2unix your_script.sh ``` 转换后脚本中的 `\r` 会被移除,避免命令解析错误[^1][^2]。 #### 方法 2:检查并修正路径 将 Windows 路径改为 Unix 风格: ```diff - c:\data\file.txt + /mnt/c/data/file.txt # Linux 挂载路径 + /cygdrive/c/data/file.txt # Cygwin 路径 ``` #### 方法 3:显式指定 Shell 解释器 在脚本第一行添加 shebang: ```bash #!/bin/bash # 或 #!/bin/sh ``` #### 方法 4:验证执行环境 在 CI/CD 配置中明确指定 Shell: ```yaml # GitLab CI 示例 job: script: - echo "Hello" before_script: - export SHELL=/bin/bash # 显式设置 Shell ``` --- ### 调试技巧 1. 使用 `cat` 显示隐藏字符: ```bash cat -A your_script.sh # 显示 ^M(即 \r) ``` 2. 手动移除 `\r`: ```bash sed -i 's/\r$//' your_script.sh ``` > **关键提示**:此错误常见于跨平台编辑脚本。建议在 Unix 系统中编辑脚本,或在编辑器中设置换行符为 `LF`(如 VS Code 右下角选择)[^2][^3]。 ---
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值