Always best to illustrate an answer with an example, so I'll use SSH as you don't specify what you're trying to do with raspi-config
The 2nd test should test for the change made the first time raspi-config
was executed. For instance, if the first time you executed raspi-config
was to enable SSH (which is probably the first thing 99.9% of most users do) you could test to see if SSH was enabled and (validating the first execution happened), then the action would be to execute raspi-config
the second time and delete the script after doing so:
#!/bin/bash
if [[ $(sudo systemctl list-unit-files|grep ssh.service|awk '{print $2}') = 'enabled' ]]; then
echo "SSH is ENABLED so raspi-config has been executed ONCE previously: Executing for 2nd time:"
sudo raspi-config
rm /etc/rc.local/thisScript.sh
else
echo "SSH *NOT* ENABLED so raspi-config NOT executed previously- starting now:"
sudo raspi-config
fi
The awk '{print $2}'
prints just the output of the first command: either enabled or disabled. The test could be rewritten to be !=
then do the action.
Of course if the reason you were executing raspi-config
was to set SSH to start on boot, you could write a script that does that directly without user input, substituting the SystemD command to enable SSH in lieu of running raspi-config
:
#!/bin/bash
if [[ $(sudo systemctl list-unit-files|grep ssh.service|awk '{print $2}') = 'enabled' ]]; then
sudo systemctl enable ssh.service
else
exit
fi
Anyhoo, lots of ways to skin this cat, but try for unattended configuration as your ultimate goal, scripting as much as possible to ensure consistency on rebuilds. HTH-
raspi-config
is a tool made for user interaction. It doesn't make sense to use it for automatic configuration.raspi-config
commands can be executed outside of the utility directly from the CLI. But yes, one's goal should be unattended, scripted configuration without user interaction being required. Full scripting is the only way you assure consist and reproducible results.