以.test而非./test的身份执行

假设我与可执行文件位于同一文件夹中，则需要输入以下内容才能执行该文件：

./file

我宁愿不必键入/，因为/我很难键入。

有没有更简单的方法来执行文件？理想情况下，只是一些简单的语法，例如：

.file

或其他方式，但比必须在/该处插入字符要容易。

也许有某种方法可以在/bin目录中放置某些内容，或为解释器创建别名，以便可以使用：

p file

它可以是“危险的”，但您可以拥有。在您的路径中。

正如其他人所说，这可能很危险，因此请务必确保。在PATH的末尾而不是开始。

../至少在现代的Bash shell中会自动完成（键入.并按Tab），因此您不必使用复杂或不安全的（如PATH修改）解决方案。

如果它不能自动完成，则可能需要安装“ bash-completion”软件包。

或者..也许在bashrc文件中给解释器起别名，然后简单地

   p  file

可以编写这样的函数：

p() {
 ./"$@"
}

在你的~/.bashrc。然后，您将可以p app arguments代替运行./app arguments。该解决方案适用于任何类型的可执行文件，包括脚本和二进制文件。

"$@"扩展为传递给函数的参数的引号列表（保留glob或变量扩展中的所有特殊字符），并且，正如@Scott指出的那样，bash它足够聪明./，可以保留在它们的第一个中，保留其余部分。

你可以把.你的$PATH加入如PATH=$PATH:.你/etc/profile，这样你就可以执行file只是写file，除非是在你的路径（例如一些其他的文件夹/usr/bin/）。请注意，这通常不是一个好主意。

不好的原因：假设您不完全信任目录的内容-您已经从某个地方下载了目录，并且想在运行它之前进行研究，或者您是系统管理员正在帮助您用户，方法是查看用户的主目录等。您想列出目录，因此尝试键入ls，但是哎呀，您输入了错字，最后却键入了sl。这个恶意目录的作者预料到了这一点，并在其中放置了一个名为“ sl”的shell脚本，该脚本运行“ rm -rf --no-preserve-root /”（或更恶意的东西，例如安装一个rootkit）。

（感谢@Muzer的解释）

例如，您可以致电口译员

bash test

在这种情况下，即使脚本没有shebang行（例如#!/bin/bash）或可执行位，它也将运行。您还必须知道正确的解释器才能运行它。您可以先阅读文件的shebang行，以确保您调用了正确的解释器，例如shebang行显示

#!/usr/bin/env python3

你会打电话

python3 test

据我所知，除非在env路径中包含文件，否则无法实现它，因此只需键入即可运行它： file

.file无法使用，因为那是另一个文件名。这是一个名为.file而不是的文件./file。

我觉得斜线可能很难为您输入，因为可能是非英文版式？在这种情况下，这也发生在我身上，因此我经常通过在Windows中按Alt + Shift来交换键盘布局为英文（我从ssh使用Linux）

人们建议增加.对PATH，这是危险的，因为它创建了一个风险，你会意外地运行种植在世界可写目录中的恶意程序。但是，如果你有几个目录，你自己可执行程序和只能通过你写的，那么它的安全（相当安全的？）把这些导演（IES）进入PATH，加入这样一行

PATH=$PATH:~/dev/myprog1:~/dev/myprog2

到您的~/.bashrc文件。当然，这意味着您可以从文件系统中任何位置的那些目录之一运行程序。例如，您可以cd /etc输入foo，它将运行~/dev/myprog1/foo。这有一个小缺点，即您不能在多个目录中包含多个目录中的同名程序。具体来说，如果您foo 同时在~/dev/myprog1和中都调用了程序，则只能~/dev/myprog2通过指定路径来运行第二个程序。同样，如果您有~/dev/myprog1/cat-但为什么要这么做？

如果只有几个程序可以使用，则另一种方法是为其定义别名：

alias gizmo='./gizmo'
alias gonzo='./gonzo'

或者，您可以称呼别名.gizmo，.gonzo 如果您觉得更直观。

实际上，在某种程度上，这与.放入您的服务器具有相同的安全风险PATH。如果恶意用户可以读取你的.bashrc，看看你的别名，那么他可能把恶意软件称为gizmo和gonzo随机目录中的希望，你会运行它。最好使它们使用绝对路径名：

alias gizmo='~/dev/myprog1/gizmo'
alias gonzo='~/dev/myprog2/gonzo'

顺便说一句，您应该避免命名可执行文件test，因为这是Shell内置命令，并且只能通过指定路径或其他技巧来使用该名称运行程序。

为了进一步扩展Zanna关于解释器的答案（对不起，没有评论）：动态加载器（ld.so）是本机可执行文件（又名二进制ELF文件）的“解释器” ，但它通常不理解您想要的语法：

$ /usr/lib/ld-linux-x86-64.so.2 program
program: error while loading shared libraries: program: cannot open shared object file
$ /usr/lib/ld-linux-x86-64.so.2 ./program
<program is launched>

（此外，除非您符号链接ld.so到路径中，否则仍然需要编写/s）

如果允许我们开始配置东西

mkdir -p ~/.local/bin
cat > ~/.local/bin/x << 'EOF'
#!/bin/sh
N="$1"
shift
exec "./$N" "$@"
EOF
chmod a+x ~/.local/bin/x

大多数现代发行版已经在$ PATH中包含〜/ .local / bin（如果没有，则添加export PATH="$HOME/.local/bin:$PATH"到您的文件~/.profile中）。然后，您可以使用x file来运行./file。

不要尝试定义.命令。该命令. script已script在当前shell中运行。这允许script为当前外壳定义环境变量。

如果允许我们创建帮助程序脚本，则可以创建一个将pwd添加到PATH的帮助程序，然后运行

. pathhelper    #adds pwd to path
file            #now it can be run without ./

这样可以避免添加“。” 到该路径，并在某处可能想要在其中运行的每条路径污染您的.profile。

我们可以使该方法更进一步，方法是创建一个辅助程序，该辅助程序将使用经过修改的PATH启动新的Shell。如果使用目录作为参数（默认使用pwd），则其功能类似于pushd编辑路径的a。您可能需要注意，退出子Shell时对其他环境变量的任何更改都将丢失，但是在长时间运行的Shell中，您的PATH变量不会杂乱无章。根据您的工作流程，这可能是有利的。

:outer shell prompt$; subshellpathhelper    # launches a subshell with modified PATH
: subshell prompt $ ; file                  # in the subshell it can be run without ./

但是我想，如果您想运行它，您可能会破解pushd，popd因此他们可以对路径进行相同的修改，而无需创建子shell，否则将丢失其他更改。

pushd --path ~/some/path/    # normal pushd plus adds target to path
file                         # it can be run without ./ until you popd

（您不能这样做，cd因为它没有的类似物popd。）

您还可以创建一对专门的助手来仅推送和弹出PATH条目。最有效的方法实际上取决于您的使用模式。

. script.sh只要您要执行的脚本在当前目录中，就可以使用语法。

您还可以在解释器之前添加前缀，例如sh或bash。例：bash script.sh