该脚本是通过/home/pi/.config/lxsessions/LXDE-pi/autostart
以下行调用的:
@bash /home/pi/Documents/openContent.sh /media/pi index.html http:/google.com
openContent.sh 是:
#!/bash
# $1 defines path we search
# $2 defines name of file we're searching for
# $3 defines default URL if we can't find the thing we're searching for
path="$(find $1 -name $2 | head -n 1)"
if [ -f "$path" ]; then
echo "content found at $path"
chromium-browser --incognito --kiosk $path
exit
else
echo "content was not found in $1
chromium-browser --incognito --kiosk $3
fi
当我启动后从终端运行脚本时,它按预期工作。如果我使用相同的参数进行搜索,它将从 USB 打开网页。如果我给它一个随机名称来搜索不存在的名称,它将打开 google.com (因为它在 /media/pi 中找不到它。这一切都很好
然而,当重新启动并从自动运行运行时,它总是会转到 google.com。如果我替换该行:
@sh /home/pi/Documents/openContent.sh /media/pi index.html http:/google.com
和:
@chromium-browser --incognito --kiosk /media/pi/DISK_IMG/index.html
它会打开页面 - 所以这似乎不是 USB 驱动器加载较晚的问题,或者我希望两者都不起作用。
我认为这只是我在 bash 脚本或在自动启动中传递参数时做错的事情,但我不知道是什么。有任何想法吗?
编辑:
我尝试sleep 30
在 openContent.sh 的顶部添加 a ,它起作用了。这有点令人不安,因为我真的不想在那里硬编码延迟。这是 find/USB 设备的一个已知问题吗?它们在 GUI/桌面环境之后加载一段时间?
这是有道理的,因为基本上 chromium 在文件系统准备好之前实际上无法尝试查看目录,所以如果我向它传递一个明确的 URL,它会信任我并去那里,当它开始查看时在那里,文件系统已准备就绪,但如果我先搜索,结果告诉我那里什么也没有。
答案1
因此,似乎在 /home/pi/.config/lxsessions/LXDE-pi/autostart
任何驱动器的执行和自动安装之间存在延迟,因此我修改了 bash 脚本,在第一分钟尝试查找该文件,然后回退到默认值。这通常会在最初几秒钟内触发,因此不会太脏,也不会太长。
我认为调用特定 URL 有效但尝试在启动时找到它却失败的原因是因为 chromium 启动和文件系统检查已安装驱动器之间的延迟大致相同,因此当 chrome 启动时,提供给 chrome 的 URL 有效。而在执行查找操作时,速度要快得多,并且在文件系统可以挂载驱动器之前返回 null,因此 chrome 会使用默认 URL 打开。
下面的代码可能可以通过打开默认文件作为第一个操作来优化,然后尝试查找真正的文件,成功时杀死 chrome,并使用正确的 URL 重新启动,但目前这是有效的:
#!/bin/bash
# $1 Defines the path that we will look in
# $2 Defines the name of the file we're looking for
# $3 Defines the path to a default file if not found
delayTime=1s
for i in {0..60}
do
path="$(find $1 -name $2 | head -n 1)"
if [ -f "$path" ];then
echo "content found at $path"
chromium-browser --incognito --kiosk $path
exit
else
echo "content was not found on attempt $i"
sleep $delayTime
fi
done
chromium-browser --incognito --kiosk $3
exit