主页 / unix / 问题

问题[shebang](unix)

Martin Hope
Joseph Sible-Reinstate Monica
Asked: 2022-06-17 18:49:36 +0800 CST
  • 2

outer.sh：

ls -l /proc/$$/exe
coproc cat
./inner.sh
kill $!

inner.sh：

ls -l /proc/$$/exe
set | grep COPROC || echo No match found
coproc cat
kill $!

当我运行时./outer.sh，会打印出来：

lrwxrwxrwx 1 joe joe 0 Jun 16 22:47 /proc/147876/exe -> /bin/bash
lrwxrwxrwx 1 joe joe 0 Jun 16 22:47 /proc/147879/exe -> /bin/bash
No match found
./inner.sh: line 3: warning: execute_coproc: coproc [147878:COPROC] still exists

既然COPROC并COPROC_PID没有设置在孩子身上，它怎么知道来自父母的那个能够给我这个警告？

此外，我发现如果我添加#!/bin/bash到顶部inner.sh，或者如果我调用bash ./inner.sh而不是仅仅./inner.shfrom outer.sh，那么警告就会消失。为什么这会改变任何东西，因为无论哪种方式都使用 bash 子进程运行？

bash shebang
Martin Hope
bk-se
Asked: 2022-03-20 19:30:10 +0800 CST
  • 1

据说在脚本中依赖 $0 是危险的（经常引用伪造它：exec -a ...）。是的，在我有写访问权限的目录中，我可以符号链接到一个脚本来伪造它的 $0。但是如何使 $0 指向我没有写访问权限的路径（例如下面的 /bin/pwd）？

下面，如果我的脚本使用 shebang，我无法实现它。当目标脚本使用shebang时可以完成吗？

$ (exec -a /bin/pwd /tmp/a0.sh)
no-shebang: argv0=/bin/pwd /proc/.../cmdline=/bin/bash^@--noediting^@-i^@

$ (exec -a /bin/pwd /tmp/a1.sh)
yes-shebang: argv0=/tmp/a1.sh /proc/.../cmdline=/bin/sh^@/tmp/a1.sh^@

$ head /tmp/a0.sh /tmp/a1.sh
==> /tmp/a0.sh <==
echo no-shebang: argv0="$0" /proc/.../cmdline=$(cat -v /proc/$$/cmdline)

==> /tmp/a1.sh <==
#!/bin/sh
echo yes-shebang: argv0="$0" /proc/.../cmdline=$(cat -v /proc/$$/cmdline)

也就是说，如果一个脚本（及其父目录）是写保护的，并且使用了 shebang，那么它对 $0 的使用是安全的（防止伪造另一个写保护的路径）？

这里使用（在 centos 7 上）bash 的 exec 语句作为 $0 的简单伪造。使用 execve() 的 C 程序不会有所不同吗？是否未能在 execve() 下游（在内核或 shebang-target 中）伪造它，而不是 bash 的 exec 太弱？

编辑：C 中的 execve() 也不会在 shebang 情况下伪造 $0，输出与上面相同：

#include <stdio.h>
int main(void) {
  char* argv[] = { "/bin/pwd", NULL };
  execve("/tmp/a1.sh", argv, NULL);
  perror(NULL);
}

我知道如果用户获得 root 权限，那么假 $0 是你的问题。但是我的带有shebang的写保护脚本不能被非root用户伪造$ 0（到另一个写保护路径）：$ 0（'just use exec -a ...'）的危险似乎是错误的。

scripting shebang
Martin Hope
dejanualex
Asked: 2019-08-01 13:29:08 +0800 CST
  • 1

我有一个python脚本，其中我有以下shebang#!/usr/bin/python 脚本权限是脚本-rwxrwxrwx. 1 user user 709 script.py的所有者与我用来运行脚本的用户相同。

我不明白为什么我在运行时得到 Permission denied./script.py但我可以使用python script.pyor运行它/usr/bin/python script.py。我错过了什么？

Linux 发行版是 RedHat 6

python shebang
Martin Hope
cheezsteak
Asked: 2019-07-04 09:05:54 +0800 CST
  • 0

我已经mill在 arch linux 上安装了 fish 作为我的默认 shell。由于文件/usr/bin/mill不是以 shebang 开头的，fish 不会执行该文件。相反，它响应

$ mill
Failed to execute process '/usr/bin/mill'. Reason:
exec: Exec format error
The file '/usr/bin/mill' is marked as an executable but could not be run by the operating system.

我可以执行 mill withbash -c 'mill'但我不想一直这样做。我也不想将其添加为 Mill 的别名。当脚本中没有shebang而不是失败时，是否可以将fish配置为始终使用sh或bash？或者可能存在操作系统级别的问题？

编辑： 米尔只是一个例子。我用不同的脚本多次遇到鱼的这个特性，我不应该编辑这些脚本。这就是为什么我正在寻找一种方法来永远避免使用该功能，而不是一次性修复。

fish shebang
Martin Hope
user9303970
Asked: 2018-02-04 04:49:33 +0800 CST
  • 12

我有一个由大约 20 个小.sh文件组成的项目。我将这些命名为“小”，因为通常没有文件有超过 20 行的代码。我采用了模块化方法，因为因此我忠于Unix 哲学，并且我更容易维护项目。

在每个.sh文件的开头，我放了#!/bin/bash.

简单地说，我理解脚本声明有两个目的：

  1. 它们帮助用户回忆执行文件所需的外壳程序（例如，几年后不使用该文件）。
  2. 他们确保脚本仅使用特定的 shell（在这种情况下为 Bash）运行，以防止在使用另一个 shell 时出现意外行为。

当一个项目开始从 5 个文件增长到 20 个文件或从 20 个文件增长到 50 个文件时（不是这种情况，只是为了演示），我们有 20 行或 50行脚本声明。我承认，尽管这对某些人来说可能很有趣，但对我来说使用 20 或 50 而不是每个项目只说 1 个（可能在项目的主文件中）感觉有点多余。

有没有办法通过在某个主文件中使用一些“全局”脚本声明来避免这种所谓的 20 或 50 行或更多的脚本声明行的冗余？

shell-script shebang