Open PinkShellos opened 4 months ago
This is definitely something I plan to add, but likely will be a few more weeks before I am able to put engineering time to it
I'm working on a PR for it at the moment. I'm just trying to find the right place to put it in the code so it makes sense and doesn't overcomplicate the existing code.
Currently, the I have a check inside wait_for_user
as well as a separate check function below the implementation of it to add into the arguments.
I haven't done any testing of it, but I'll push the PR once I have something that looks workable for folks to try out.
I recommend the following:
Create a new function that checks for the true
boolean in the configuration file. Lets call it check_run_at_loginwindow
If that option is set to true
you can change the function wait_for_user
to contain the code you want it to contain in order to run at login window. Then you don't have to worry about later "if/then" statements, we always just run the wait_for_user
function at the appropriate time and it either actually waits for the user or runs the new "run at loginwindow" code.
We may also want to find/replace (carefully) the name of the wait_for_user
function so that it makes more sense now. Something like loginwindow_action
We need to also be careful this doesn't step on the silent_mode
options, because that already changes wait_for_user
and silent mode should supercede the new run at loginwindow functionality.
Wanted to run this potential solution by you to see how you felt about it:
function check_run_at_loginwindow(){
showAtLoginWindowSetting=$($pBuddy -c "Print ShowAtLoginWindow" "$BaselineConfig")
if [ "$showAtLoginWindowSetting" = "true" ]; then
showAtLoginWindow="true"
else
showAtLoginWindow="false"
fi
}
I then decided to better preserve your original code by using a case
statement:
function loginwindow_action(){
# default loginwindow setting to false, change if true
showAtLoginWindow="false"
check_run_at_loginwindow
case "$showAtLoginWindow" in
"true")
debug_message "Baseline has been set to run at loginwindow, skip verified user check.";;
"false" | *)
#Set our test to false
verifiedUser="false"
#Loop until user is found
while [ "$verifiedUser" = "false" ]; do
#Get currently logged in user
currentUser=$( echo "show State:/Users/ConsoleUser" | scutil | awk '/Name :/ { print $3 }' )
else #Verify the current user is not root, loginwindow, or _mbsetupuser
if [ "$currentUser" = "root" ] \
|| [ "$currentUser" = "loginwindow" ] \
|| [ "$currentUser" = "_mbsetupuser" ] \
|| [ -z "$currentUser" ]
then
#If we aren't verified yet, wait 1 second and try again
sleep 1
else
#Logged in user found, but continue the loop until Dock and Finder processes are running
if pgrep -q "dock" && pgrep -q "Finder"; then
uid=$(id -u "$currentUser")
log_message "Verified User is logged in: $currentUser UID: $uid"
verifiedUser="true"
fi
fi
fi
debug_message "Disabling verbose output to prevent logspam while waiting for user at timestamp: $(date +%s)"
set +x
done
debug_message "Re-enabling verbose output after finding user at timestamp: $(date +%s)";;
esac
}
I used a find/replace to swap wait_for_user
with loginwindow_action
as well. I'm updating the PR with these commits now, but let me know what you think.
I am good with this format, however, it does not appear that this accounts for --silent
mode, which also needs to skip the wait_for_user
function
Perhaps we need to think of this more like "Run mode"
Is the "Run mode" "Original Flavor, Silent, or LoginWindow" ? What do you think?
If so, --silent
should override any other mode that may also be configured
That actually makes way more sense to treat it as such. So then you could just call --loginwindow
as an argument and then we don't need to modify the existing codebase. I'm going to retract the PR for now and revert my changes so I can start fresh.
I've been thinking on this.
I think the goal needs to be: Determine which runmode we have by reading all of the relevant configuration profile keys, then at the step where wait_for_user
is running we instead run a function like initiate_runmode
.
So read the config to see if silent is there, read the config to see if runatloginwindow is there (also read the command line arguments for both)
Then do one if/elif statement:
initiate_runmode(){}
function with what we want to happen for silent moderunatloginwindow
mode is enabled: create the initiate_runmode(){}
function with what we want to happen for loginwindow modeinitiate_runmode(){}
basically gets the current wait_for_user
codeWhat do you think?
I rebased from main
instead of dev
, hopefully that doesn't cause issues with the PR. I did submit the PR to dev
.
Thats awesome, I look forward to reviewing when I am able.
I don't have any changes in the works in the dev
branch, so i think I can point the PR to the right place when needed.
Thank you for your contribution!
Computer labs and shared resource computers often need to be redeployed without a user logged in to have them provisioned before a user needs it.
SwiftDialog 2.5.0 added support for a
--loginwindow
flag that can be executed by a LaunchDaemon to enable this functionality.I propose setting up a
ShowAtLoginWindow
key that validates SwiftDialog 2.5.0 or newer is installed, skips the logged in user check, and runs SwiftDialog with the--loginwindow
flag.