In bash, to detect whether a command COMMAND is available, the following statement shall be executed. (Note that I configured bash to be the default shell, instead of zsh.)

type COMMAND...

For example, type detects that the command cp is available and that the command foo is unavailable.

$ type cp
cp is /bin/cp

$ type foo
-bash: type: foo: not found

Note that you can pass two or more commands to type.

$ type cp foo
cp is /bin/cp
-bash: type: foo: not found

However, type is useless to detect the genuine availability of commands SetFile and GetFileInfo, that is, to detect whether SetFile and GetFileInfo are truly usable.

SetFile and GetFileInfo belong to Commandline Developer Tools for Xcode. macOS 12 Monterey does not automatically come with Xcode nor Commandline Developer Tools. Hence, SetFile and GetFileInfo are supposed to be unavailable if neither Xcode nor Commandline Developer Tools is installed. Thus, I expected type SetFile GetFileInfo to deny their availability. On the contrary, type affirmed their availability.

$ type SetFile GetFileInfo
SetFile is /usr/bin/SetFile
GetFileInfo is /usr/bin/GetFileInfo

Then, I executed SetFile and GetFileInfo in Terminal. However, macOS complained that SetFile and GetFileInfo were unusable.

The "SetFile" command requires the command line developer tools.
Would you like to install the tools now?

The "GetFileInfo" command requires the command line developer tools.
Would you like to install the tools now?

These error messages were not displayed in Terminal; but a GUI dialog box popped up in the desktop outside Terminal, asking the user to click either the "Install" or "Cancel" button.

How can the genuine availability of SetFile and GetFileInfo be tested quietly without causing any user interaction?

Let me ask some more questions related to this above question. On one occasion, I clicked the "Install" button to let the Commandline Developer Tools (CLDT) be installed. I thought that the Commandline Developer Tools (CLDT) would be installed into "/Applications/Xcode.app". However, the installation of CLDT neither created the directory "/Applications/Xcode.app" nor installed CLDT into it. Where was CLDT installed to?

Comparing before and after the installation of CLDT, has the binary file "/usr/bin/SetFile" changed?

I speculated that "/usr/bin/SetFile" depended on a library or framework from CLDT. If this is the case, where is the CLDT library or framework?

  • Using type, or which, or whence correctly indicates that there is a command there named SetFile. You want the OS to tell you whether it is the one you want, a different definition of "correct". That's not something the OS can know. Commented Aug 12, 2022 at 18:15
  • Also, nowhere does anything say that binaries named SetFile and/or GetFile are not supposed to be available just because the CLT is not installed. Like other parts of the system, shims are provided to install missing/wanted tools. Commented Aug 12, 2022 at 18:19

1 Answer 1


If you want to know if the CLT is installed, one method is to look for the receipt with pkgutil:

$ pkgutil --pkg-info=com.apple.pkg.{CLTools_Executables,CLTools_Base,DeveloperToolsCLI,DeveloperToolsCLILeo} 2>/dev/null | sed -n 's/^version: //p'

Which will return either null, or the version that is installed, as shown here.

$ pkgutil --pkg-info=com.apple.pkg.{CLTools_Executables,CLTools_Base,DeveloperToolsCLI,DeveloperToolsCLILeo} 2>/dev/null | sed -n 's/^version: //p'

If you want to know the path to which the CLT is installed, use xcode-select(1).

$ xcode-select -p      

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .