Questions tagged «shebang»

我注意到，我从其他人那里获得的一些脚本具有shebang，#!/path/to/NAME而另一些（使用相同工具NAME）具有shebang #!/usr/bin/env NAME。 两者似乎都能正常工作。在教程中（例如，在Python上），似乎有人建议后者shebang更好。但是，我不太明白为什么会这样。 我意识到，要使用后一个shebang，NAME必须在PATH中，而第一个shebang没有此限制。 另外，对我来说，第一个似乎是更好的shebang，因为它精确指定了NAME的位置。因此，在这种情况下，如果存在多个版本的NAME（例如/ usr / bin / NAME，/ usr / local / bin / NAME），则第一种情况指定要使用的版本。 我的问题是，为什么第一个shebang优先于第二个？

458 shell-script  shebang 

如果创建具有以下内容的可执行文件并运行它，它将自动删除。 这是如何运作的？ #!/bin/rm

84 shell-script  files  rm  executable  shebang 

这可能是一个愚蠢的问题，但我仍然要问。如果我宣布了射手 #!/bin/bash 在的开头my_shell_script.sh，所以我总是必须使用bash调用此脚本吗？ [my@comp]$bash my_shell_script.sh 或者我可以使用例如 [my@comp]$sh my_shell_script.sh 我的脚本使用shebang确定正在运行的shell？kshShell 发生了同样的事情吗？我正在使用AIX。

84 scripting  executable  shebang 

我创建了一个bash脚本，但是当我尝试执行它时，我得到了 #!/bin/bash no such file or directory 我需要运行命令：bash script.sh它才能工作。 我怎样才能解决这个问题？

69 bash  shell-script  executable  shebang 

我对以下脚本（hello.go）感到困惑。 //usr/bin/env go run $0 $@ ; exit package main import "fmt" func main() { fmt.Printf("hello, world\n") } 它可以执行。（在MacOS X 10.9.5上） $ chmod +x hello.go $ ./hello.go hello, world 我还没有听说过Shebang开头//。当我在脚本顶部插入空白行时，它仍然有效。为什么该脚本有效？

60 shell  shell-script  osx  shebang  slash 

在我见过的大多数shell脚本中（除了我自己没有写过的脚本之外），我注意到shebang设置为#!/bin/sh。对于旧的脚本，这并不令我感到意外，但是在相当新的脚本中也是如此。 是否有理由宁愿使用/bin/shover /bin/bash，因为bash在十年前的许多Linux和BSD机器上，它普遍存在并且通常是默认的吗？

53 bash  shell  history  shebang 

在Shebang中，#!口译员与翻译员之间是否可以有空格？ 例如，#! /bin/bash。看来可行，但有人说这是不正确的。

47 shebang 

（有关Ubuntu-OSX兼容性以及易用性和POSIX，请参阅使用＃！/ bin / sh或＃！/ bin / bash） 如果我希望我的脚本使用bash shell，使用.bash扩展名是否确实会调用bash还是取决于系统配置/ 1st shebang行。如果两者都有效但又不同，哪个优先？ 我不确定是否要以.sh结束我的脚本以仅指示“ shell脚本”，然后让第一行选择bash shell（例如#!/usr/bin/env bash），还是仅以.bash结尾（以及第1行设置） ）。我希望bash被调用。

36 bash  shell  shebang 

所以，我以为我对此有很好的了解，但是只是进行了一次测试（以回应我不同意某人的对话），发现我的理解是有缺陷的... 尽可能详细地说明我在Shell中执行文件时会发生什么情况？我的意思是，如果我键入以下内容：如果./somefile some arguments在外壳中键入内容，然后按return键（somefile并存在于cwd中，并且我具有的读取和执行权限somefile），那么在幕后会发生什么？ 我以为答案是： Shell进行syscall exec，将路径传递给somefile 内核检查somefile并查看文件的幻数，以确定它是否是处理器可以处理的格式 如果幻数表示文件是处理器可以执行的格式，则 创建一个新流程（在流程表中有一个条目） somefile被读取/映射到内存。创建一个堆栈，执行跳转到的代码的入口点somefile，并ARGV初始化为参数数组（a char**，["some","arguments"]） 如果幻数是shebang，则exec()如上所述产生一个新进程，但是使用的可执行文件是shebang引用的解释器（例如/bin/bash或/bin/perl），somefile并传递给STDIN 如果文件没有有效的幻数，则发生类似“无效文件（不良幻数）：执行格式错误”的错误 但是有人告诉我，如果文件是纯文本，那么Shell会尝试执行命令（就像我键入一样bash somefile）。我不相信这一点，但我只是尝试了一下，这是正确的。因此，我显然对这里实际发生的事情有一些误解，并且想了解其机制。 当我在shell中执行文件时，会发生什么情况？（尽可能多的细节是合理的...）

32 shell  kernel  exec  shebang 

我想知道是否存在通过shebang行（#!）将多个选项传递给可执行文件的一般方法。 我使用NixOS，在我编写的任何脚本中，shebang的第一部分通常是/usr/bin/env。然后我遇到的问题是，系统将所有后续内容解释为单个文件或目录。 例如，假设我想编写一个bash在posix模式下执行的脚本。编写shebang的幼稚方式是： #!/usr/bin/env bash --posix 但是尝试执行生成的脚本会产生以下错误： /usr/bin/env: ‘bash --posix’: No such file or directory 我知道这篇文章，但我想知道是否有更通用，更清洁的解决方案。 编辑：我知道对于Guile脚本，有一种方法可以实现我想要的内容，在手册的4.3.4节中进行了介绍： #!/usr/bin/env sh exec guile -l fact -e '(@ (fac) main)' -s "$0" "$@" !# 这里的窍门是，第二行（以开头exec）被Guile解释器解释为代码，sh但在#!... !#块中但作为注释，因此被忽略。 不可能将这种方法推广到任何解释器吗？ 第二次编辑：经过一番摸索之后，对于可以从中读取输入内容的解释器来说stdin，以下方法可行： #!/usr/bin/env sh sed '1,2d' "$0" | bash --verbose --posix /dev/stdin; exit; 但是，这可能不是最佳的，因为该sh过程一直持续到口译员完成工作为止。任何反馈或建议，将不胜感激。

32 scripting  environment-variables  posix  arguments  shebang 

在Apache httpd项目的“ support / apxs.in”脚本中，之后是带@符号的文本#!。也就是说，脚本的第一行是： #!@perlbin@ -w 这是Perl还是UNIX内核？换句话说，可以使用path/to/script/script_name.in？执行该脚本。 如果不是，那么使用#!？启动脚本的原因是什么？

26 scripting  perl  shebang 

我想在分离的屏幕上运行bash脚本。该脚本会多次调用一个程序，每次等待都花费很长时间。我的第一个想法是只打开一个屏幕，然后调用该脚本，但是似乎无法ctrl-a d在脚本运行时分离（by ）。因此，我进行了一些研究，发现此指令将shebang替换为以下内容： #!/usr/bin/screen -d -m -S screenName /bin/bash 但这也不起作用（选项无法识别）。有什么建议么？ PS这只是我现在想到的screen -dmS name ./script.sh，可能可以满足我的目的，但是我仍然很好奇如何将其合并到脚本中。谢谢。

25 shell-script  scripting  gnu-screen  shebang 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4天前关闭。 我可以假设已经zsh安装了足够的人来运行带有 #!/usr/bin/env zsh 如shebang？ 还是这会使我的脚本在太多系统上无法运行？ 澄清：我对最终用户可能要运行的程序/脚本感兴趣（例如在Ubuntu，Debian，SUSE，Arch＆c。上）

25 bash  zsh  portability  shebang 

是否可能有一个shebang，而不是指定解释程序的路径，而是使用解释程序的名称，然后让shell通过$ PATH找到它？ 如果没有，为什么？

24 shell  shebang 

简单的查询：我刚刚意识到我从未见过脚本顶部的shebang.bashrc，这使我认为系统在登录（${SHELL}）时使用默认的shell来提供源代码。我正在考虑这种情况的原因，即使用默认外壳程序以外的其他内容来运行登录脚本是否被视为一种坏习惯。

22 shell  bashrc  profile  shebang