Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

pbs(8) [osx man page]

PBS(8)							    BSD System Manager's Manual 						    PBS(8)

pbs -- general helper tool SYNOPSIS
pbs [-debug] [-dump_pboard] [-dump_userdefs] [-flush_pboard] [-flush_userdefs] [-existing_languages] language1 language2 ... DESCRIPTION
pbs is an agent for the Services menu. It scans for and vends available Services, to populate the Services menu. pbs is NOT related to the pasteboard. The pasteboard is managed by the pboard agent. pbs normally runs the first time Services are needed in any login session. You may run it manually for debugging Services. If run without any options, pbs will scan for changed Services, cache them along with their English localization on a private pasteboard, and immediately update the Services menu in all running apps. It will also log about any invalid Services declarations in Info.plist. This is useful when developing or testing Services, because it immediately applies any changes. ServicesMenu.strings files for a localization are loaded only when an app running under that localization shows the Services menu. You may pass pbs language codes (e.g. "fr") to cause it to load that localization immediately. You may also pass the flag -existing_languages to reload already loaded localizations. pbs has additional options that are useful for debugging, in particular the -dump_pboard option. The complete list of options is: -debug Output debugging information regarding what pbs is doing. -dump_pboard Prints the private pasteboard containing the current Services information. You can use this to determine which apps are providing Ser- vices and where they are located on the filesystem. -dump_userdefs Prints the userdef cache of Services information. pbs caches Services information in its userdefs to avoid scanning the entire system every boot. Changed apps are still detected via FSEvents, so there is no need to flush the userdef cache when installing a new Service. -flush_pboard Erases the private pasteboard containing Services information. The next time the Services menu is shown, pbs will scan for changed Ser- vices and update the pasteboard. -flush_userdefs Erases the userdef cache. -flush Equivalent to -flush_pboard and -flush_userdefs, entirely resetting pbs. The next time Services information is needed, pbs will do a com- plete rescan for apps vending Services, and read their plist. Note: this rescan may be very expensive! HISTORY
First appeared in NextStep. pbs has historically had responsibilities that ranged from pasteboard management to Unicode glyph generation, but now it only does Services. Mac OS X June 1, 2006 Mac OS X

Check Out this Related Man Page

xpcservice.plist(5)					      BSD File Formats Manual					       xpcservice.plist(5)

xpcservice.plist -- XPC Service configuration keys and values DESCRIPTION
This document describes the keys-value pairs which configure an XPC Service. An XPC Service is a process which implements the server-side of an XPC connection. The service program is contained inside a Mac OS X bundle. The bundle contains an Info.plist. The XPC Service configu- ration settings are specified by keys and values defined in a dictionary included within the Info.plist. OVERVIEW
An application has a namespace which maps a service name to a running instance of the service program. The namespace is created dynamically and is unique to each application. The namespace is populated with the set of services embedded in the application bundle and embedded in the frameworks used by the application. System frameworks may have embedded XPC Services. Typically, a developer would not connect to this service directly. Instead, the developer would call an API function in the framework and that would contact the service. However, the name of XPC Service must be in the applica- tion's namespace so that the framework code can "see" and connect to the service. XPC Services are "launched-on-demand". They are only started when an application creates a connection to the service and sends a message to it. The service process can be terminated when it is inactive and has been idle for a a period of time. The service process can be started again upon receipt of a new message or connection request. XPC Services should be state-less so that they can come and go as needed. The results of a connection request to an XPC Service from two different applications depends upon the type of the service. The service type controls the policy used to create a new instance of the service. For example, a new connection request from two different applications to an Application-type service in a framework will result in a new instance of the service being created for each application. However, if two applications request the same User-type service, then only one instance of the service will be created for each user. Services embedded in an application bundle will only be visible to the containing application and will be, by definition, Applicaton-type services. A subsequent connection request from an application to a service will result in a new connection to an existing service. CF Bundle Keys These top-level Info.plist keys are required to be defined in the Info.plist file: CFBundleIdentifier <string> This key defines the name of the service; clients use this name to connect to the service. CFBundlePackageType "XPC!" This key identifies the bundle as being an XPC Service. XPCService <dictionary> This key defines a dictionary which contains the settings to configure the XPC Service. XPCService Dictionary Keys The XPC Service may be configured by setting these keys in the XPCService dictionary: ServiceType <string> (default: Application) The type of the XPC Service specifies how the service is instantiated. The values are: o Application Each application will have a unique instance of this service. o User There is one instance of the service process created for each user. o System There is one instance of the service process for the whole system. System XPC Services are restricted to reside in system frameworks and must be owned by root. RunLoopType <string> (default: dispatch_main) The RunLoop type specifies which style of runloop will be started once xpc_main has finished initializing. The values are: o dispatch_main xpc_main will call dispatch_main(). o NSRunLoop xpc_main will call [[NSRunLoop currentRunLoop] run]. JoinExistingSession <bool> (default: False) By default XPC Services are placed into their own unique audit session. If this key is true, then the service is placed into the session of the application requesting a connection to the service. EnvironmentVariables <dictionary> (default: none) A dictionary containing environment variables (represented as key-value pairs) which are set in the environment of the service process. SEE ALSO
plist(5) Darwin February 8, 2011 Darwin
Man Page