新安装的linux系统,如果进行精简安装可能会出现bash:command not found 的提示,大家在安装的时候可以选择默认安装basic的组件,一般即可.到时候可以再升级.   如果新装的系统,运行一些很正常的诸如:shutdown,fdisk的命令时,悍然提示:bash:command not found.那么 首先就要考虑root 的$PATH里是否已经包含了这些环境变量. 主要是这四个:/bin ,/usr/bin,/sbin,/usr/sbin. 四个主要存放的东东: ./bi

linux下执行shell脚本时报错:-bash: ./a.sh: /bin/bash^M: bad interpreter: No such file or directory. 原因是windows下的文件是dos格式,即每一行结尾以\r\n来标识,而linux下的文件是unix格式,行尾则以\n来标识. 查看文件格式有三种方法: 1.cat -A <filename>,如果输出结果中行末尾是^M$,则是dos格式,如果行末尾只是$,则是unix格式. 2.vim <filename

#!/bin/bash是指此脚本使用/bin/bash来解释执行. 其中,#!是一个特殊的表示符,其后,跟着解释此脚本的shell路径. bash只是shell的一种,还有很多其它shell,如:sh,csh,ksh,tcsh,... 我们可以通过以下一个示例来进行实验,了解#!/bin/bash的使用. 1)#!/bin/bash只能放在第一行,如果后面还有#!,那么只能看成是注释. 这里有三个脚本(脚本都要使用”chmod +x  scriptname“命令来获得可执行权限): tbash1

PS背景:我在公司做sdk 的pc端开发,所以经常会在win下编译通过之后跑到linux下再运行一次已确保能支持多平台. 今儿在win下跑完一程序,然后放到linux下跑的时候,我用指令: [plain] view plain copy sudo ./build.sh 但是却没有任何反应.于是我换了指令,用 [plain] view plain copy chmod u+x build.sh   ./build.sh 报错 "build.sh  /bin/bash^M: 坏的解释器:没有那个文件

bash.dash(/bin/bash和/bin/sh) 原文:http://www.cnblogs.com/dkblog/archive/2011/04/02/2003822.html Linux中的shell有多种类型,其中最常用的几种是Bourne shell(sh).C shell(csh)和Korn shell(ksh).三种shell各有优缺点.Bourne shell是UNIX最初使用的shell,并且在每种UNIX上都可以使用.Bourne shell在shell编程方面相当优秀

错误: /bin/bash^M: bad interpreter: 没有那个文件或目录 解决方案: 运行脚本时出现了这样一个错误,打开之后并没有找到所谓的^M,查了之后才知道原来是文件格式的问题,也就是linux和windows之间的不完全兼容...具体细节不管,如果验证: vim test.sh:set ff?如果出现fileforma＝dos那么就基本可以确定是这个问题了.:set fileformat=unix:wq!

最近遇到一个有趣的问题,让我搞清楚Linux如何选择当前执行脚本的shell 执行cts的的 media stress test 需要安装 android-cts-media-1.0.zip 把这个文件解开,发现有一个 copy_media.sh 脚本,就是用 adb push 向 android devices 复制文件,很简单的一个脚本,执行起来却有错 $./copy_media.sh 1920x1080 1920x1080 ./copy_media.sh: 22: [: 1920x1080

如果是在windows下编辑的脚本,到了linux下运行时会报出这样的错误/bin/bash^M:bad interpreter: No such file or directory这时因为编码的问题,需要进行编码转换.使用sudo vim xxx打开文件,:set ff可以看到当前的格式,应该是dos,使用set ff=unix,更改其格式,然后保存退出,就能正常的运行程序了

一.故障现象 1.用secure CRT连接服务器时显示: /bin/bash:No such file or directory 翻译成中文是:没有此类文件或目录 2.直接登录服务器执行命令时显示: /lib/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory 翻译成中文大概的意思是:找不到/lib/ld-linux-x86-64.so.2文件 只有cd命令可以正常使用 二.故障原因 1.背景介绍 此服务器需

一.linux下编译make文件报错“/bin/bash^M: 坏的解释器 参考文章:http://blog.csdn.net/liuqiyao_01/article/details/41542101#comments 自己测试的结果: [1]使用windows 下的编辑工具 新建文件doc2unix.sh #!/usr/bin/env bash # test PID=$(ps -aef | grep nginx | grep -v grep | grep master |awk '{print

一直以为在shell脚本中#都是代表着注释功能,同样在脚本开始的#!/bin/sh也只是告诉用户这是一个shell脚本,而最近顺手查了下,才发现不是这个意思,分享下面的文章. 转自:http://www.cnblogs.com/EasonJim/p/6850319.html 一.意思 #!/bin/sh是指此脚本使用/bin/sh来解释执行,#!是特殊的表示符,其后面跟的是此解释此脚本的shell的路径. $ cat /etc/shells可以查看系统支持的shell格式 其实第一句的#!是对脚

摘自:https://blog.csdn.net/danson_yang/article/details/65629948 Linux useradd 与 adduser的区别, /sbin/nologin 与 /bin/bash 2017年03月24日 14:03:54 danson_yang 阅读数:11942更多 个人分类: linux   一.useradd 与 adduser的区别 添加用户 1. 在root权限下,useradd只是创建了一个用户名,如 (useradd  +用户名

一.意思 #!/bin/sh是指此脚本使用/bin/sh来解释执行,#!是特殊的表示符,其后面根的是此解释此脚本的shell的路径. 其实第一句的#!是对脚本的解释器程序路径,脚本的内容是由解释器解释的,我们可以用各种各样的解释器来写对应的脚本. 比如说/bin/csh脚本,/bin/perl脚本,/bin/awk脚本,/bin/sed脚本,甚至/bin/echo等等. #!/bin/bash同理. 二.区别 GNU/Linux操作系统中的/bin/sh本是bash (Bourne-Again

对于linux上需要执行 的shell脚本,通常第一行的内容是 #!/bin/bash 当然有很多时候不规范的写法可以忽略掉这一句,执行起来好像也是ok,结果没什么不一样 .. 这只是因为在我们常用 的linux系统上默认都是执行/bin/bash来执行我们的shell脚本,但是如果有些用户使用的是csh,那么缺少第一行的"#!/bin/bash的shell脚本执行结果就可能存在语法不兼容的问题,导致结果异常或者根本不能执行. Shell脚本和我们常用的C语言或者C++语言编写编译出来的bin执

#!/bin/bash是指此脚本使用/bin/bash来解释执行. 其中,#!是一个特殊的表示符,其后,跟着解释此脚本的shell路径. bash只是shell的一种,还有很多其它shell,如:sh,csh,ksh,tcsh,... 我们可以通过以下一个示例来进行实验,了解#!/bin/bash的使用. 1)#!/bin/bash只能放在第一行,如果后面还有#!,那么只能看成是注释. 这里有三个脚本(脚本都要使用”chmod +x  scriptname“命令来获得可执行权限): tbash1

今天遇到一个很诡异的问题,一直运行很正常的shell脚本失败了,只是昨天增加了一个参数而已. 报错信息: /bin/bash^M: bad interpreter: No such file or directory 后来发现root cause, 昨天修改文件的时候在windows中修改保存,然后上传的. 文件被识别成dos格式. 在此的命令模式下使用以下命令可以查看: : set ff 返回结果:  fileformat=dos 修改文件格式为Unix,使用下面的命令: :set ff=un

#!/usr/bin/env bash #在不同的系统上提供了一些灵活性. #!/usr/bin/bash #将对给定的可执行文件系统进行显式控制. 通过/usr/bin/env运行程序,用户不需要去寻找程序在系统中的位置(因为在不同的系统,命令或程序存放的位置可能不同),只要程序在你的$PATH中: 通过/usr/bin/env运行程序另一个好处是,它会根据你的环境寻找并运行默认的版本,提供灵活性. 不好的地方是,有可能在一个多用户的系统中,别人在你的$PATH中放置了一个bash,可能出现错

概述 简单解释一下 shell 脚本卡头的 #!/bin/bash 水一篇, 少一篇 背景 shell 脚本中的注释 通常是 以# 卡头的行 但是有时候执行 shell 的时候, 会有这种内容 #!/bin/bash 1. #!/bin/bash 这不是注释 他是有意义的 shell 脚本执行 场景 一个 脚本 由 shell 执行 !/bin/bash 作用 指定 shell 2. 尝试 场景1: bash 脚本: test01.sh #!/bin/bash echo 'hello' 执行 命

[环境信息] Hadoop版本:2.4.0 客户端OS:Windows Server 2008 R2 服务器端OS:CentOS 6.4 [问题现象] 在通过Windows客户端向Linux服务器提交Hadoop应用时,会提示如下错误: org.apache.hadoop.util.Shell$ExitCodeException: /bin/bash: line 0: fg: no job control at org.apache.hadoop.util.Shell.runCommand(Sh

在windows下保存了一个脚本文件,用ssh上传到centos,添加权限执行nginx提示没有那个文件或目录.shell脚本放到/etc/init.d/目录下,再执行/etc/init.d/nginx,提示多了这句/bin/bash^M: bad interpreter.网上找了资料才知道如果这个脚本在Windows下编辑过,就有可能被转换成Windows下的dos文本格式了,这样的格式每一行的末尾都是以\r\n来标识,它的ASCII码分别是0x0D,0x0A.如果你将这个脚本文件直接放到Li

今天在用ssh Secure shell 连接虚拟机中的Ubuntu编写程序时,想比对一下两个源代码有什么差别,但是在一个ssh 客户端下不断的切换很是费劲.于是想着在主机中再添加一个用户.我原本用ssh Secure shell 登陆用的是root用户.于是想着添加一个sshConnect用户.于是在服务器的终端下通过使用 useradd命令和passwd命令添加了一个sshConnect用户,查看/etc/passwd 文件中的最后一行有sshConnect用户的数据. 但是当我通过ssh