在bash脚本中-e和-ne是什么意思？

我是bash新手，我不知道是什么

在

中表示如果[！-e$1]

和

$1/*

在

中对于$1/*

中的myfile是什么意思。到目前为止，我一直认为，

if[！-e$1]

好像（不等于第一个参数）（这样做）。。。。这是正确的吗？但什么不等于第一个参数呢

对于$1/*

中的myfile，我不知道这意味着什么。 有什么帮助吗

#!/bin/bash

# number of expected arguments
EXPECTED_ARGS=1

# exit value if the number of arguments is wrong
E_BADARGS=1


if [ $# -ne $EXPECTED_ARGS ]
then
  echo "Usage: `basename $0` {arg}"
  exit $E_BADARGS
fi

if [ ! -e $1 ]
then
  echo "file $1 does not exist"
  exit $E_BADARGS
fi

for myfile in $1/*
do
if [ -d "$myfile" ]
then
  echo "$myfile (DIR)"
elif [ -f "$myfile" ]
then 
  echo "$myfile"
fi
done

$#

是一个变量，表示传递的参数数。此行检查它是否与另一个变量

$EXPECTED\u ARGS

不同（“不相等”）

if [ $# -ne $EXPECTED_ARGS ]

这是检查文件系统中是否存在

$1

$1

是一个，它是传递给脚本的第一个参数。有关在bash中使用if的更多信息

if [ ! -e $1 ]

预期

$1

是一个目录，并使用遍历目录中的每个文件。每个文件都加载到变量

$myfile

中

---

正如评论中提到的，脚本的现状存在一些问题。我会做一些不同的事情；这是第一次快速改进：

代码表示不存在，因此

if[！-e$1]

读取“如果（文件、目录或链接类型的）第一个参数不存在，则执行…”（

-e

是一个表示“存在”的文件测试操作符）

---

$1/*中myfile的

表示您的第一个参数是一个目录，并循环遍历该目录中的所有文件。
[
本身不是bash语法——它是
test
命令的别名。诚然，bash有自己的
test
内置版本，但它仍然以与
/usr/bin/test
或
/usr/bin>相同的语义运行/[
正在被调用，这是一个值得考虑的常规命令。为了完整性：可以通过键入
帮助测试
来找到bash内置的文档（而
人工测试
将为您提供非内置的
/usr/bin/[
）文档………这意味着，例如，
如果[< /代码>与<代码>完全不同，如果[；前者将要查找名为“文件”的文件，即“代码”> [< /代码>如果没有函数或别名共享该名称。BTW，请考虑运行代码以自动引用引用错误等。（另外，当我在kibitzing时——所有caps变量名实际上都是为shell保留的——与PS1、PWD等一样——以及系统——与PATH、LD_PRELOAD等一样，因此您自己的变量应该使用小写名称，以免冲突；请参阅规范的第四段，记住环境变量和shell变量iables共享一个名称空间）。我建议在这里演示良好的引用实践。除了正确使用带有空格的文件名&c外，
if[“$”-ne“$EXPECTED\u ARGS”]
也会更好地突出显示语法。：）。此外，并非所有这些情况下，在“$1”中对myfile引用明显的“f'rinstance”
都是好的/正确的/*
不是新手可能会猜到的，但关键是要了解作为
$1传递的目录名是否可以在IFS、globs或其他有趣的内容中包含字符。同意，脚本本身存在很多问题。我不想批评它，但还有很大的改进空间。@Laura，它不是“相等”，而是“存在”——告诉你磁盘上是否存在文件。
help test
的输出会告诉你这一点。正如我在回答中所说，e代表“存在”。它只是检查传递的第一个参数是否是存在的文件。这正是我要查找的！！好吧--由于缺少引号，它实际上做的事情比这更复杂。
[！-e$1]
字符串拆分，glob在将
$1
传递到
之前扩展其内容[
，这意味着它运行的实际测试命令可能更有趣。类似地，
对于$1/*
中的myfile，如果该目录名没有空格，则仅扩展到
$1
中命名的目录的内容；否则，仅扩展到
$1
的最后一段（在IFS中按字符分割）将被视为一个目录，其他段将作为单独的条目进行全局展开和迭代…如果您希望简单的描述是正确的，它需要是“$1”中的myfile的
[！-e“$1”]
和
/*
取而代之。@charlesduff希望我能像你一样理解shell编程。我才刚开始，所以我一直在寻找真正精简的答案，这样我就不会不知所措。@Laura，…事实上——解释错误代码在所有可能输入中的行为对解释者来说是一件很费事的事，对用户来说也是一件很费事读者要理解；以“要正确，就这样编写代码；这样编写代码时，它就这样工作”的形式给出的答案可能是平衡可读性、完整性和准确性这三个相互竞争的目标的最佳方式。
for myfile in $1/*