Closed gspannu closed 8 months ago
OK, will see what I can do but this may not be worth the time. macOS makes this sort of thing so difficult. I included the appropriate admin permission with the app but not sure why it didn't get triggered to prompt the user.
OK, will see what I can do but this may not be worth the time. macOS makes this sort of thing so difficult. I included the appropriate admin permission with the app but not sure why it didn't get triggered to prompt the user.
You are correct, it may not be worth the time trying to fix it (if it doesn't get fixed quickly).... As said earlier, there is a manual workaround anyway...
Great work... thanks.
I added a note to the README about the CLI. A few thoughts:
/usr/local/bin
. It would be better to create a softlink to the binary so that upgrading the app also upgrades the CLI target without requiring the CLI be re-installed./usr/local/bin
. This is also a problem on multi-user homebrew installations where one user installed homebrew and another user tries to use brew
which fails without su ORIGINAL_USER
.~/.local/bin
and ensure that's in the path. This would require modifying .zshrc
and I hate it when other apps do that. And it would fail if user is using a non-default shell.locationator-cli
app in its own repo that can be installed with pipx install locationator-cli
for example.If there was an open source example native macOS app that installed something in /usr/local/bin
that would be a good reference to see how they solved this. VS Code is one such example but I searched their source for any hints and came away with nil.
An alternative might be just to pop up a dialog box asking the user to copy the shell commands needed to the clipboard (to create /usr/local/bin
if it doesn't already exist and symlink the CLI to the App bundle)? They could then paste these into Terminal, hit Return, type in password and be done.
An alternative might be just to pop up a dialog box asking the user to copy the shell commands needed to the clipboard (to create
/usr/local/bin
if it doesn't already exist and symlink the CLI to the App bundle)? They could then paste these into Terminal, hit Return, type in password and be done.
Symlinking the CLI would be the best option… Option 1 in your previous post is the simplest option.
I agree… Just give the user a pop-up message to run the (copied to clipboard) command in Terminal. Simple, no errors, and updating the app will also update the CLI. Sounds like a good plan.
I got all the logic put in place and working to copy the install/remove commands to the clipboard and prompt user to execute them...only to realize that it still won't work for non-admin users. If user tries to run the commands without sudo they'll get "permission denied" but if they try to use sudo, they'll get: "username not in sudoers files. This incident will be reported" message. Most command line users are probably also sudo users but I wish Apple made this easier.
I got all the logic put in place and working to copy the install/remove commands to the clipboard and prompt user to execute them...only to realize that it still won't work for non-admin users. If user tries to run the commands without sudo they'll get "permission denied" but if they try to use sudo, they'll get: "username not in sudoers files. This incident will be reported" message. Most command line users are probably also sudo users but I wish Apple made this easier.
You are correct... that is a common issue.
The only way around this is to first do
su admin
(or whatever the administrator username is)
and then run all commands as sudo
That is what most users would need to do (who are non administrators)... I think if you just put the message in a pop-up to state that users need to create a symlink to the /Applications/....locationator and create this in a folder which is in their PATH statement (e.g. /usr/local/bin or /opt/homebrew/bin or similar)
I think a pop-up message that shows an example command line for /usr/local/bin will suffice...
I got all the logic put in place and working to copy the install/remove commands to the clipboard and prompt user to execute them...only to realize that it still won't work for non-admin users. If user tries to run the commands without sudo they'll get "permission denied" but if they try to use sudo, they'll get: "username not in sudoers files. This incident will be reported" message. Most command line users are probably also sudo users but I wish Apple made this easier.
You are correct... that is a common issue.
The only way around this is to first do
su admin
(or whatever the administrator username is) and then run all commands assudo
That is what most users would need to do (who are non administrators)... I think if you just put the message in a pop-up to state that users need to create a symlink to the /Applications/....locationator and create this in a folder which is in their PATH statement (e.g. /usr/local/bin or /opt/homebrew/bin or similar)
I think a pop-up message that shows an example command line for /usr/local/bin will suffice...
You may be able to do this via AppleScript...
The following command in AppleScript works, and it prompts for a admin username/ password.
do shell script "sudo ln -s /Applications/Locationator.app/Contents/Resources/locationator /usr/local/bin/locationator" with administrator privileges
You may be able to do this via AppleScript...
That's a good idea. I'll give this a try to verify the prompt works when called from the compiled app
Making progress....applescript runs and displays authentication dialog but does not execute correctly when run from the App bundle.
Making progress....applescript runs and displays authentication dialog but does not execute correctly when run from the App bundle.
![]()
This command executes from the shell...
osascript -e 'do shell script "sudo ln -s /Applications/Locationator.app/Contents/Resources/locationator /usr/local/bin/locationator" with administrator privileges'
You could also maybe place the commands in a text file, e.g. copyfiles.scpt (and then place this file within the app bundle) and then execute the command via osascript, something like...
osascript ./additionalfiles/copyfiles.scpt
This command executes from the shell...
Same command I'm running from AppleScript. The script runs, it's a permission issue...macOS is blocking the elevated permissions. Apple has tried to make this impossible.
The authorization succeeds...but the script doesn't have access and just fails
default 05:56:33.837652-0700 authd UID 501 authenticated as user X (UID 501) for right 'system.privilege.admin'
default 05:56:33.837781-0700 authd Validating credential X (501) for system.privilege.admin (engine 7476)
default 05:56:33.842010-0700 authd credential 501 is member of group admin (does satisfy rule) (engine 7476)
default 05:56:33.842282-0700 authd Succeeded authorizing right 'system.privilege.admin' by client
'/Library/Frameworks/Python.framework/Versions/3.11/Resources/Python.app' [81164] for authorization created by
'/Library/Frameworks/Python.framework/Versions/3.11/Resources/Python.app' [81164] (13,0) (engine 7476)
Why not just show a pop-up message with the complete osascript command and copy-to-cliopboard and request user to run it.
I don't think this is worth your time to make it super elegant... I understand as a programmer, you want to !
I don't think this is worth your time to make it super elegant...
I code as a hobby and get focused on interesting problems...this is, at the moment, an interesting problem. :-)
It looks like the sh
that gets run is sandboxed and can't see /usr/local/bin
:
Locationator 0.0.6 /bin/sh: ln -s /Users/rhet/code/locationator/dist/Locationator.app/Contents/Resources/locationator /usr/local/bin/locationator: No such file or directory
...this is, at the moment, an interesting problem. :-)
I can relate to that ... 😊
It looks like the
sh
that gets run is sandboxed and can't see/usr/local/bin
:
Locationator 0.0.6 /bin/sh: ln -s /Users/rhet/code/locationator/dist/Locationator.app/Contents/Resources/locationator /usr/local/bin/locationator: No such file or directory
Just a thought... (and you have likely already checked this).
Did you run the command using sudo... as the Admin user may still require sudo access.
Locationator 0.0.6 /bin/sh: sudo ln -s /Users/rhet/code/locationator/dist/Locationator.app/Contents/Resources/locationator /usr/local/bin/locationator: No such file or directory
Yes, tried both with / without sudo
I give up (for now), added your "copy osascript command to clipboard" idea and verified it works. Pushing a new release then will turn to the service. I still want to find a way to create the proper background helper in python that can do the privelleged install. Requires Service Framework and XPC and bunch of other pain....thanks Apple!
Hi folks! Funny I should find a completely different need to reverse geocode potentially solved by an Apple service meant for photos...
In any case, I'd love CLI access for what I'm doing and yes, I ran into the issue(s) above, even as admin. I can manage to write up some code work queries via the web server but I'd rather not.
For both free and paid reverse geocoding services, there's usually a limit imposed. For what I'm looking to do, I may hit that, and if so I'll report back (in another thread of course).
Did you try the latest release which has you copy commands into the Terminal for installing the CLI?
I did, and still had issues until I realized that at some point I lost sudo
permissions, even though I was admin.
Once I fixed that by re-enabling root
(with Directory Utility of all things), the workaround worked.
It's working as expected now, appreciate it!
Did you try the latest release which has you copy commands into the Terminal for installing the CLI?
Yes, the command line tool works with the latest version... and installed the CLI successfully. It prompted for a admin username/password (as expected).
I'm moving on to the next project...I think the current install/uninstall works well enough though it's not elegant. Closing this issue.
CLI tools cannot be installed from the menu item if the macOS user is a non-administrator (i.e. a regular user).
v0.0.6
I guess, that access to /usr/local/bin requires sudo access, hence it fails...
I temporarily fixed this by
sudo cp /Applications/Locationator.app/Contents/Resources/locationator /usr/local/bin