Shell:目录中的/和//有区别吗?
我正在 Shell 中制作这个小程序:
#***************************************************************
# Function.
# NAME: chk_df
# Synopsis:
# Check if a local directory (dirName) exist and has a file (fileName).
#
#
# The return codes are the following:
# 99 : dirName does not exists
# 0 : dirName exists and has fileName
# 1 : dirName exists and has not fileName
#
# Parameters:
# In values: dirName <string> fileName <string>
# Out values: returnCode <int>
#
# How to use:
# chk_df dirName fileName
#***************************************************************
chk_df(){
# Check the number of arguments that could be passed.
# In this case, two, dirName, fileNAme.
if [[ ${#@} != 2 ]]; then
echo "Error ...Use [Function]: chk_df <dirName> <fileName>"
echo "Ex: chk_df /foo lola.txt"
exit
fi
DIR=$1
FILE=$2
[[ ! -d $DIR ]] && return 99
[[ -d $DIR && ! -e $DIR/$FILE ]] && return 1
[[ -d $DIR && -e $DIR/$FILE ]] && return 0
}
因为我需要检查文件是否在目录中,所以我做了这个(可怕的?)补丁 $DIR/$FILE ,但这样的事情可能会发生:
I) If we do: chk_df /foo lola.txt
We get: /foo/lola.txt
II) If we do: chk_df /foo/ lola.txt
We get: /foo//lola.txt [Notice the //]
在这两种情况下,代码似乎都有效。 为什么?我读到反斜杠的作用就像空格。那么,我可以在没有未知问题的情况下输入 n 反斜杠吗?
我可以就这样保留它吗?否则会带来问题?有区别吗? UNIX 假设的方法正确吗?
额外问题:为什么我不能用负数进行回报?这是:返回-1
I'm making this tiny program in Shell:
#***************************************************************
# Function.
# NAME: chk_df
# Synopsis:
# Check if a local directory (dirName) exist and has a file (fileName).
#
#
# The return codes are the following:
# 99 : dirName does not exists
# 0 : dirName exists and has fileName
# 1 : dirName exists and has not fileName
#
# Parameters:
# In values: dirName <string> fileName <string>
# Out values: returnCode <int>
#
# How to use:
# chk_df dirName fileName
#***************************************************************
chk_df(){
# Check the number of arguments that could be passed.
# In this case, two, dirName, fileNAme.
if [[ ${#@} != 2 ]]; then
echo "Error ...Use [Function]: chk_df <dirName> <fileName>"
echo "Ex: chk_df /foo lola.txt"
exit
fi
DIR=$1
FILE=$2
[[ ! -d $DIR ]] && return 99
[[ -d $DIR && ! -e $DIR/$FILE ]] && return 1
[[ -d $DIR && -e $DIR/$FILE ]] && return 0
}
Because I need to check if a file is in a directory, I did this (horrible?) patch $DIR/$FILE , but things like this could happen:
I) If we do: chk_df /foo lola.txt
We get: /foo/lola.txt
II) If we do: chk_df /foo/ lola.txt
We get: /foo//lola.txt [Notice the //]
In both cases the code seems to work. Why? I read that backslash acts like a space. So, could I put n backslash without unknown problems?
Could I leave it like that or it will bring problems? Is there a difference? UNIX assume it to the right way?
EXTRA QUESTION: why I can not do the returns with negative numbers? This is: return -1
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
根据 POSIX 标准,
/
、//
或任何连续斜杠字符串具有相同的含义,但它们可能有一个路径开头的含义不同(因此/foo
和//foo
可能表示不同的对象)。 Linux 不使用此例外,因此任意数量的连续斜杠始终与单个/
含义相同。(例外是为了满足其他使用前导
//
来表示网络路径的类 Unix 系统的需求。)/
,//
, or any string of consecutive slashes have the same meaning according to the POSIX standard, with the exception that they may have a different meaning at the beginning of a path (so/foo
and//foo
may denote different objects). Linux does not use this exception, so any number of consecutive slashes always means the same thing as a single/
.(The exception is there to cater to the needs of other Unix-like systems that use leading
//
to denote a network path.)没有区别。
// = /
There are no difference.
// = /
原则上,您可以根据需要使用任意多个
/
分隔符(直到您开始达到PATH_MAX
或其他一些硬性限制):您将遇到的一个问题是,如果你曾经想测试两个路径是否相同[*],因为 /usr/bin/less 和 /usr/bin//less 是相同的路径,但是不同的字符串。在比较之前规范化路径可能很有用。
[*] 忽略不同路径可以引用同一个对象的事实。
You can, in principle, use as many
/
separators as you want (until you start hittingPATH_MAX
or some other hard limitation):One problem you'll run into is if you ever want to test that two paths are the same[*], because /usr/bin/less and /usr/bin//less are the same path but are different strings. It can be useful to canonicalise paths before comparison.
[*] Ignoring the fact that different paths can refer to the same object.