-/bin/sh not found

本文探讨了在分析动态库时遇到的问题,并通过改进脚本来解决了一个遗漏的关键库ld-linux-so.2的问题。文章详细介绍了脚本的修改过程,包括路径扩展和依赖库的获取方法。

      1 #! /bin/bash
      2 LIB_CUR_REL=
      3 LIB_CUR_ABS=
      4
      5 get_binary_dependency()
      6 {
      7     readelf -d $1 | grep NEEDED | sed -n 's,.*\[\(.*\)\],\1,p'
      8 }
      9
     10 expand_path()
     11 {
     12     LIB_CUR_ABS=
     13     for i in /lib /usr/lib ${LD_LIBRARY_PATH}
     14     do
     15         for j in $@
     16         do
     17             if [ -f ${i}/${j} ]
     18             then
     19                 LIB_CUR_ABS="${LIB_CUR_ABS} ${i}/${j}"
     20             fi
     21         done
     22     done
     23 }
     24
     25 get_abs_dependency()
     26 {
     27     TMP=$(get_binary_dependency $@)
     28 }
     29
     30 LIB_CUR_REL="$(get_binary_dependency $@)"
     31 expand_path ${LIB_CUR_REL}
     32
     33 #for i in ${LIB_CUR_ABS}
     34 #do
     35 #   echo $i
     36 #done
     37
提取应用程序中所需的动态库,基本上对了,不过今天用这个分析出动态库的时候还是少了一个,ld-linux-so.2(动态编译后执行当然需要它了!!)

当然了分析动态库还未结束,因为分析出来的动态库还依赖其它文件,这个脚本没有做进一步分析

<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]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值