Ubuntu 16.04
Bash 4.3.48
shellcheck当源文件表示脚本顶部的$variables时，为什么会失败？
这是一个简单的脚本：
#!/bin/bash
. .sourcefile
echo "Today is ${day}."
这是我的源文件：
day="Monday"
以下是来自的回复shellcheck：
me@myserver:~$ shellcheck start.sh
In start.sh line 5:
echo "Today is ${day}."
^-- SC2154: day is referenced but not assigned.
有没有办法让shellcheck知道$变量是在源文件中？
@Dash-o 解释了以下程序：
首先，在源文件声明上方的行中添加source 指令，如下所示：
# shellcheck source=/path/to/sourcefile
#!/bin/bash
# shellcheck source=./.sourcefile
. .sourcefile
echo "Today is ${day}."
接下来，在脚本之前shellcheck使用-x选项执行，如下所示：
shellcheck -x start.sh
me@myserver:~$ shellcheck …我正在编写一个脚本来为我的博客生成草稿.运行ShellCheck后,我一直看到弹出这个错误.这是什么意思,有人可以提供一个例子吗？
SC2129: Consider using { cmd1; cmd2; } >> file instead of individual redirects.
另外,我不确定我需要做什么才能将值传递$title给"Title"帖子的YAML中的字段......
#!/bin/bash
# Set some variables
var site_path=~/Documents/Blog
drafts_path=~/Documents/Blog/_drafts
title="$title"
# Create the filename
title=$("$title" | "awk {print tolower($0)}")
filename="$title.markdown"
file_path="$drafts_path/$filename"
echo "File path: $file_path"
# Create the file, Add metadata fields
echo "---" > "$file_path"
{
echo "title: \"$title\""
} >> "$file_path"
echo "layout: post" >> "$file_path"
echo "tags: " >> "$file_path"
echo "---" >> "$file_path"
# Open the …Shellsheck 是一个 shell 脚本的静态分析工具，可以在某些 Linux 系统上本地安装，也可以不安装在线使用来检查 bash 脚本是否存在一些错误。
测试环境：
主目录
#!/bin/bash
source ./sourcefile.sh
echo "Output from main.sh"
echo
echo
fkt_output_from_sourcefile_sh
echo
echo
echo "For closing window, press Enter or Ctl + C"; read -r
源文件.sh
#!/bin/bash
fkt_output_from_sourcefile_sh() {
echo "Output from sourcefile.sh"
}
我是如何在终端上运行它的：
shellcheck -x main.sh
终端输出（看起来工作正常）：
Output from main.sh
Output from sourcefile.sh
For closing window, press Enter or Ctl + C
通过 shellcheck …
假设我有一个shell脚本,test.sh它应该回显一些值.我希望能够通过具有glob扩展的环境变量传递这些值:
$ ls
1.js 2.js test.sh*
$ FOO="*.js" bash ./test.sh
1.js 2.js
你说容易!写吧
#!/bin/bash
echo $FOO
事实上,这是有效的.但它没有通过ShellCheck,后者通过使用隐式globbing /扩展(SC2086)来调用我们.(这是公平的;在原始代码中,回声线是cp $FOO $BAR,确实我们不想扩展$BAR;这个错误捕获了错误.)
所以,为了使这个更明确,我希望以下可能会起作用:
#!/bin/bash
array=( $FOO )
echo "${array[@]}"
但不是:我们最终得到了SC2206.
是否有规范的方式来做这种事情,这属于ShellCheck作者认为的最佳实践？(请随意使用www.shellcheck.net上的在线检查程序对其进行测试.)这完全是错误的做法吗？ShellCheck的作者似乎不太可能想到这个用例......
如果在printf(1)格式字符串中放入变量，ShellCheck会发出警告。为什么？
是：
printf "$file does not exist\n"
在某些方面不如：
printf "%s does not exist\n" "$file"
系统：Linux Mint 19（基于Ubuntu 18.04）。
编辑器：我使用带有 ShellCheck 插件的Visual Studio Code（官方网站）来即时检查错误、警告和提示。
是每个 shell 脚本编写者的必备工具。
尽管开发人员必须付出巨大的努力使其尽可能好，但它有时会产生不相关的警告和/或信息。
示例代码，带有此类消息（警告SC2120 + 直接相邻信息SC2119）：
am_i_root()
# expected arguments: none
{
# check if no argument has been passed
[ "${#}" -eq 0 ] || print_error_and_exit 1 "am_i_root" "Some arguments have been passed to the function!\\n\\tNo arguments expected.\\n\\tPassed: ${*}"
# check if the user is root
# this will return an exit code of the command itself …在检查 shell 脚本时如何删除 shellcheck 的警告“SC2154”？
#!/bin/bash
set -euo pipefail
IFS=$'\n\t'
echo "proxy=$http_proxy" | sudo tee -a /etc/test.txt
警告是“SC2154：引用了 http_proxy 但未分配。”
编辑：我想使用 sudo 将环境变量“http_proxy”写入 test.txt 文件。
if在bash中编写块时,shellcheck告诉我&&并且||更喜欢使用-a和-o.
为什么？它更快,或者只是简单的风格偏好使脚本看起来更干净？
我得到的具体信息是:
^-- SC2166: Prefer [ p ] || [ q ] as [ p -o q ] is not well defined.
我收到以下代码中第二行的 ShellCheck 警告 [SC2045]。可以忽略它，因为我在尝试最后一个之前确保目录不为空ls吗？
if [ "$(ls -A "$retryDir")" ] ; then
for thisRetryFile in $(ls "$retryDir"/*.tar.gz) ; do
scp -o ConnectTimeout=30 "$thisRetryFile" \
"$remoteUser@$remoteHost:$remotePath" >> "$BACKUPLOG"
done
fi
更新： 阅读帖子评论后。我已将行更改为：
for thisRetryFile in "$retryDir"/*.tar.gz ; do
这已删除警告。
我有以下 bash 脚本：
dpkg-query --show --showformat='${Status}\n' "$i" 2> \
/dev/null | grep "install ok installed" &> /dev/null
if [[ $? -eq 0 ]]; then
l_var_is_desktop="true"
fi
ShellCheck 实用程序 ( https://www.shellcheck.net/ ) 给出以下输出：
$ shellcheck myscript
Line 17:
if [[ $? -eq 0 ]]; then
^-- SC2181: Check exit code directly with e.g. 'if mycmd;', not indirectly with $?.
$
此警告的链接如下：https://github.com/koalaman/shellcheck/wiki/SC2181
修改这个的最好方法是什么。该命令实在太长，无法放入一行。我想避免使用 ShellCheck 忽略规则。
我尝试创建一个局部变量并存储命令的输出，但这打破了其他规则。