Skip to main content

Hello All,

'grep' has been a great tool in my tiny script for many years running from Jamf Remote(deprecated).

...now, through Jamf Pro Policies, the grep command is getting a 'Usage Error':

**************************************************************************************************

Script result: usage: grep [-abcdDEFGHhIiJLlMmnOopqRSsUVvwXxZz] [-A num] [-B num] [-C[num]]
[-e pattern] [-f file] [--binary-files=value] [--color=when] [--context[=num]] [--directories=action] [--label] [--line-buffered] [--null] [pattern] [file ...]

**************************************************************************************************

....Basic form of my tiny script:

**************************************************************************************************

#!/bin/bash

#ENV variable for current logged in user = $LOGNAME

for home in $(ls /Users | grep -v $LOGNAME | grep -v Shared)

do rm -rf /Users/$home
done

**************************************************************************************************

I tried redoing the grep command like this:

**************************************************************************************************

#!/bin/bash

#ENV variable for current logged in user = $LOGNAME

for home in $(ls /Users | grep -invert-match $LOGNAME | grep -invert-match Shared)

do rm -rf /Users/$home
done

**************************************************************************************************

...still get the same error:

Script result: usage: grep [-abcdDEFGHhIiJLlMmnOopqRSsUVvwXxZz] [-A num] [-B num] [-C[num]]
[-e pattern] [-f file] [--binary-files=value] [--color=when] [--context[=num]] [--directories=action] [--label] [--line-buffered] [--null] [pattern] [file ...]

I've asked a senior Apple admin about this & his suggestion was the '-invert-match' usage... I've searched 

for a better way to use grep?  Also, some alternatives with same results...but all look like 3rd party tools that need

to be installed?  

This was a really handy way to keep mobile AD accounts from building up on machines over time.  Now, I have to 

login to each machine to run the same script.  Looking for a better way!  Any pointers would be greatly appreciated!

Thank You in advance!  ~Patrick

I can't be sure, but it may have to do with your use of $LOGNAME in the script, which I assume is meant to get the logged in user? See, the problem here is that Jamf Pro policy run scripts will always run as root, and $LOGNAME returns the name of the user running the command, so it would be returning root when run from a policy, not the actual logged in user.


There are significantly better ways to get the logged in username in a script


That being said, I don't necessarily see why using LOGNAME would throw a grep usage error. If anything, it would not end up excluding your current user from the accounts to be removed. Problematic, but still not something that should cause grep to spit out a usage error. Unless... the $LOGNAME variable is actually pulling nothing at all. In which case, grep WOULD throw a usage error since the script is giving it nothing to 'grep' against.


In cases like these, it can be extremely helpful to sprinkle in a bunch of echo's in the script in places to output what the script it seeing. So put in an echo "LOGNAME variable: $LOGNAME" in your case. See what the policy log shows. You might find out what the issue is.

I can't be sure, but it may have to do with your use of $LOGNAME in the script, which I assume is meant to get the logged in user? See, the problem here is that Jamf Pro policy run scripts will always run as root, and $LOGNAME returns the name of the user running the command, so it would be returning root when run from a policy, not the actual logged in user.


There are significantly better ways to get the logged in username in a script


That being said, I don't necessarily see why using LOGNAME would throw a grep usage error. If anything, it would not end up excluding your current user from the accounts to be removed. Problematic, but still not something that should cause grep to spit out a usage error. Unless... the $LOGNAME variable is actually pulling nothing at all. In which case, grep WOULD throw a usage error since the script is giving it nothing to 'grep' against.


In cases like these, it can be extremely helpful to sprinkle in a bunch of echo's in the script in places to output what the script it seeing. So put in an echo "LOGNAME variable: $LOGNAME" in your case. See what the policy log shows. You might find out what the issue is.


Thank You for your reply,

Actually, I've not always had that in there....this is something I usually run when no-one is logged in.

I tested it again with '$LOGNAME' removed....still gets the same error:

*********************************************************************************************************************

Script result: usage: grep [-abcdDEFGHhIiJLlMmnOopqRSsUVvwXxZz] [-A num] [-B num] [-C[num]]
[-e pattern] [-f file] [--binary-files=value] [--color=when] [--context[=num]] [--directories=action] [--label] [--line-buffered] [--null] [pattern] [file ...]

*********************************************************************************************************************

What would be the difference from Jamf Remote running the script successfully & now Jamf Pro Policies throwing the usage error on the exact same thing?  Puzzling :-p  ~Patrick

Thank You for your reply,

Actually, I've not always had that in there....this is something I usually run when no-one is logged in.

I tested it again with '$LOGNAME' removed....still gets the same error:

*********************************************************************************************************************

Script result: usage: grep [-abcdDEFGHhIiJLlMmnOopqRSsUVvwXxZz] [-A num] [-B num] [-C[num]]
[-e pattern] [-f file] [--binary-files=value] [--color=when] [--context[=num]] [--directories=action] [--label] [--line-buffered] [--null] [pattern] [file ...]

*********************************************************************************************************************

What would be the difference from Jamf Remote running the script successfully & now Jamf Pro Policies throwing the usage error on the exact same thing?  Puzzling :-p  ~Patrick


Yes, Jamf Remote tended to run things as the current user, or at least as the "Jamf admin" account that got created during enrollment. A Jamf Pro policy on the other hand, especially ones that run on the check-in trigger, will run as the root account, since the check-in is initiated by a LaunchDaemon. So there is a difference. Don't feel bad. Lots of people get tripped up by this difference. We've all run into this at one time or another.


That being said, this is just a best guess. I can't be sure that's part of the cause here. You should put an echo or two into the script like I mentioned and see what gets returned. It may help solve the issue.

I use a similar command to search through user accounts...


ls -l /Users | /usr/bin/awk '{print $9}' | /usr/bin/grep -viE '(shared|Guest|.DS_Store|.localized)'

In mine the search is case insensitive, it will not show Shared or shared. I think that is the i that does that and the E is a pattern search, so anything with shared in it will be excluded.


I run this via Jamf with no issues. The awk is to strip the lines down to just the folder name. I also use the quotes and brackets around the search terms to allow for more things to exclude.


Give this a test and see if it works for you.


 

Also try defining the ls as a variable, and then use the variable in the for loop. It might be happier with that.


localaccounts=$(ls -l /Users | /usr/bin/awk '{print $9}' | /usr/bin/grep -viE '(shared|Guest|.DS_Store|.localized)')

 

Also try defining the ls as a variable, and then use the variable in the for loop. It might be happier with that.


localaccounts=$(ls -l /Users | /usr/bin/awk '{print $9}' | /usr/bin/grep -viE '(shared|Guest|.DS_Store|.localized)')

 


Hello Paul,

That's certainly a nice line of code for sure!  Thank You for this!

In further testing, I'm thinking I have a 'Product Issue' which will

require involving Jamf Support.  I tried a script with all 'grep' commands

removed to see if I can get anything...still got the exact same usage error.

Script here:

 

Very strange indeed!!!! 😮  ~Patrick

Turns out, anything I do with Scripts in the Jamf Pro Web Interface does not translate or get written to the configured distribution point / file share. If I upload a script through Jamf Admin, it shows in the list of the Web Interface but shows nothing for the script & no category.  This is wild.

Reply


Terms & ConditionsCookie settings