UtilitiesReference QNX Neutrino RTOS ® ®

(1)

QNX

^®

Software Development Platform 6.6

QNX

^®

Software Development Platform 6.6

QNX ^® Neutrino ^® RTOS

Utilities Reference

(2)

©

1996–2014, QNX Software Systems Limited, a subsidiary of BlackBerry. All rights reserved.

QNX Software Systems Limited 1001 Farrar Road

Ottawa, Ontario K2K 0B3 Canada

Voice: +1 613 591-0931 Fax: +1 613 591-3579 Email: info@qnx.com Web: http://www.qnx.com/

QNX, QNX CAR, Neutrino, Momentics, Aviage, and Foundry27 are trademarks of BlackBerry Limited that are registered and/or used in certain jurisdictions, and used under license by QNX Software Systems Limited. All other trademarks belong to their respective owners.

Electronic edition published: Thursday, March 6, 2014

(3)

About This Reference

The Utilities Reference describes the utilities, manager processes, and configuration files included with the QNX Neutrino RTOS. This reference is intended for everyone from end-users to system administrators.

See:

For information about:

A ¦ B ¦ C ¦ D ¦ E ¦ F ¦ G ¦ H ¦ I ¦ J ¦ K ¦ L ¦ M

¦ N ¦ O ¦ P ¦ Q ¦ R ¦ S ¦ T ¦ U ¦ V ¦ W ¦ X ¦ Y ¦ Z

Specific utilities

Utility Conventions (p. 23) An overview of the syntax for utilities

Commonly Used Environment Variables Environment variables

Selecting the Target System Targets for GNU utilities

What's New in this Reference?

A summary of changes to this reference

Glossary Terms used in QNX Neutrino

documentation

Your system might not include all of the things that this reference describes, depending on what software you've installed. For example, some utilities are included in a specific Board Support Package (BSP).

For information about licensing, see:

• the QNX Development Suite License Guide at

http://licensing.qnx.com/license-guide/

• the Third Party License Terms List at

http://licensing.qnx.com/third-party-terms/

• the matrix of all the versions of all our legal documents at http://licensing.qnx.com/document-archive/

19

(20)

Typographical conventions

Throughout this manual, we use certain typographical conventions to distinguish technical terms. In general, the conventions we use conform to those found in IEEE POSIX publications.

The following table summarizes our conventions:

Example Reference

if( stream == NULL ) Code examples

Command options -lR Commands make

Environment variables PATH

/dev/null File and pathnames

exit() Function names

Ctrl –Alt –Delete Keyboard chords

Username Keyboard input

Enter Keyboard keys

login:

Program output

stdin Variable names

parm1 Parameters

Navigator User-interface components

Options Window title

We use an arrow in directions for accessing menu items, like this:

You'll find the Other... menu item under Perspective ➝ Show View . We use notes, cautions, and warnings to highlight important messages:

Notes point out something important or useful.

Cautions tell you about commands or procedures that may have unwanted or undesirable side effects.

Warnings tell you about commands or procedures that could be dangerous to your files, your hardware, or even yourself.

20 About This Reference

(21)

Note to Windows users

In our documentation, we use a forward slash (/) as a delimiter in all pathnames, including those pointing to Windows files. We also generally follow POSIX/UNIX filesystem conventions.

21 Typographical conventions

(22)

Technical support

Technical assistance is available for all supported products.

To obtain technical support for any QNX product, visit the Support area on our website (www.qnx.com). You'll find a wide range of support options, including community forums.

22 About This Reference

(23)

Chapter 1 Utility Conventions

23

(24)

Syntax conventions

Most QNX Neutrino utilities follow standard conventions for argument syntax and behavior. These conventions are based on the utility conventions outlined in POSIX 1003.2-1992.

The syntax synopsis for each utility appears at the top of the page of its manual entry.

The utility name appears first, followed by other allowed command-line arguments, which include options, option arguments (e.g. “number” in -n number), and operands (e.g. the names of files to act on).

The syntax synopsis is the only reliable source for information about mutual exclusivity of options and about whether a command-line element is optional or required. This information isn't usually contained in the detailed option listings that appear after the syntax section.

A typical utility syntax line looks like this:

utilityname [-abcd] [-o arg | -p arg] infile... outfile

The example above shows a utility called utilityname that accepts the options -a, -b, -c, and -d — these options may be used alone or in any combination.

The utility also accepts the options -o and -p, both of which require an option argument, and which may not be used together (but may be used with the other options -abcd).

The utility requires two or more operands: one or more infile and exactly one outfile.

Interpreting utility syntax

Here are the main principles at work:

• When utilities have many options, the options may appear grouped together in the syntax like this:

utilname [-abcd]

which means that the options -a, -b, -c, and -d are supported.

• Options, option arguments, and operands enclosed in brackets ([ and ]) are optional and can be omitted. Note that the [ and ] symbols should never be included in the actual command.

• Arguments separated by | are mutually exclusive. Sometimes mutually exclusive arguments that relate to modes of operation are indicated with multiple syntax lines representing the different forms of the command.

24 Utility Conventions

(25)

• A trailing ellipsis mark (…) after options or operands indicates that the preceding item may be repeated. If the preceding item is optional, the ellipsis indicates that the item may occur zero or more times, e.g.:

utility [filename...]

If the item is mandatory, the ellipsis indicates it may occur one or more times, e.g.:

utility filename...

Invoking utilities

There are a number of general guidelines to follow when running utilities:

• An option may be followed by another option after a single dash (-) on the command line as long as each preceding option doesn't have an option argument. For example, the option string -abc is equivalent to -a -b -c. However, if -a accepts an option argument, then -abc would be equivalent to -a bc instead.

• Options and their option arguments should be specified with spacing as shown in their documentation. If the documentation says:

-n number

the number should be a separate command-line argument from the -n. But if the documentation refers to:

-nnumber

then number should appear in the same argument as -n without any intervening blanks. Utilities in QNX Neutrino and in POSIX-conforming systems permit both forms in all utilities unless otherwise stated, but you'll achieve the greatest portability by using the preferred form. This is particularly important when developing scripts that may be used on multiple (QNX Neutrino and non-QNX Neutrino) platforms.

• Options are usually listed in alphabetical order, but there's no restriction on the order that they may appear in the command line when used, unless otherwise indicated in the documentation for the utility. Note that in some utilities, mutually exclusive options override each other in a “last one wins” manner.

25 Syntax conventions

(26)

• All options and associated option arguments must precede any operands on the command line. For example, if you want to run the cp utility with the -R option, you may enter:

cp -R dir1 dir2

but not:

cp dir1 dir2 -R

• Decimal integers are accepted when numeric values are required in operands and option arguments, unless otherwise specified. Some utilities may support 0octal and 0xhex numbers as well without being documented as doing so. For this reason, don't precede decimal numbers with leading zeros.

• Integer numerical operands and option arguments must be in the range 0 to 2147483647 unless otherwise specified. If negative numbers are accepted, the acceptable range is -2147483647 to 2147483647.

• The argument -- (“dash dash”) may be placed on the command line as a delimiter indicating the end of options and the start of operands. This is particularly useful when the operands themselves might start with a dash. For example, to remove a file named “-t”, you would use:

rm -- -t

Utilities that don't accept any options also accept and discard a -- before their operands, unless otherwise indicated.

• Most utilities that accept filenames as operands (and sometimes as option arguments) accept the filename “-” to mean standard input, or, when unambiguous from its context, standard output.

26 Utility Conventions

(27)

File conventions

File pathnames specified on the command line are restricted to 255 characters. Some input files are specifically identified as “text files.” Text files are expected to contain ASCII text in newline-terminated lines that don't exceed 2048 characters, unless otherwise indicated.

27 File conventions

(28)

Signal conventions

Signal actions are inherited from the process that invokes the utility. Most utilities don't do any special processing upon receipt of a signal, but behave instead according to the system defaults. When a utility performs some action on receipt of a signal other than the default, it's documented as doing so.

Note that temporary files aren't left in place after a utility is terminated due to a signal, unless otherwise specified.

Servers and resident processes typically run only as root and ignore most signals (such as SIGPWR).

28 Utility Conventions

(29)

Exit status conventions

Utilities normally return zero for successful completion and values greater than zero when unsuccessful. Some utilities return different nonzero numbers according to the reason they failed. Beware of testing for a specific nonzero number to indicate failure.

(In most cases utilities that may return different nonzero numbers are explicitly documented as doing so. However, you should not rely on this.)

For some utilities, the exit status may reflect only the success or failure of the last action taken (of many). In these cases, this behavior is explicitly documented in the

“Exit status” section.

In the ksh (p. 1029), you can use $? to get the exit status of the last command. For more information, see “Parameters (p. 1040)” in the documentation for ksh.

29 Exit status conventions

(30)

Error conventions

Utilities may fail for many reasons ranging from incorrect usage to underlying system failure. The documentation for the utilities doesn't attempt to outline the exact behavior for all possible modes of failure.

In all cases, unless otherwise specified, every error results in a diagnostic message printed to standard error.

When an error occurs, the utility stops the processing of the current operand and proceeds to process the next operand in the sequence. If a utility fails to process one operand but succeeds on others, the exit status still reflects failure. For utilities that recurse through a filesystem (e.g. find), if an action cannot be performed on one file within a hierarchy, the utility stops processing that file and goes on to the subsequent files in the hierarchy.

When an unrecoverable error occurs (e.g. insufficient memory), the utility prints a diagnostic message to standard error and exits immediately.

30 Utility Conventions

(31)

Chapter 2 A

The QNX Neutrino resource managers and utilities are described here in alphabetical order.

A ¦ B ¦ C ¦ D ¦ E ¦ F ¦ G ¦ H ¦ I ¦ J ¦ K ¦ L ¦ M ¦ N ¦ O ¦ P ¦ Q ¦ R ¦ S ¦ T ¦ U ¦ V ¦ W ¦ X ¦ Y ¦ Z The following are described elsewhere:

See:

For information about:

gawk (p. 869) awk

This chapter describes the utilities, etc. whose names start with “A”.

31

(32)

ability

Change the ability set of the invoking process (QNX Neutrino)

Syntax:

ability [ability-spec...]

Runs on:

QNX Neutrino

Options:

ability-spec

Specify an ability to be allowed or disallowed. The ability-spec argument is a comma-separated list that contains the following, as required, ignoring the case of the strings:

• the ability identifier, as defined in <sys/procmgr.h>, but omitting the PROCMGR_AID_ prefix (e.g., specify setuid for

PROCMGR_AID_SETUID)

• allow or deny

• lock if you want to prevent the process from changing the ability

• root, nonroot, or all to specify the applicable domain

• inherit or noinherit

If the ability accepts a subrange, the above may be followed by a colon and a comma-separated list of subranges, in one of the following forms:

• two numbers separated by a hyphen (e.g., 4-27)

• one number followed by a hyphen (e.g., 4- indicates 4 and greater)

• a single number

Description:

The ability utility lets you allow or deny abilities for the invoking process. You can specify multiple abilities.

If you specify allow, deny, lock, root, nonroot, or all without an ability name, the action applies to all abilities not specifically mentioned in another -A option.

For more information about abilities, see the entry for procmgr_ability() in the QNX Neutrino C Library Reference.

32 A

(33)

Exit status:

0 All abilities were successfully parsed and applied.

1 An error occurred.

Examples:

Deny forking while running as root, but allow the process to set _CS_HOSTNAME when non-root:

ability root,deny,fork nonroot,allow,confset:2

33 ability

(34)

addr2line

Convert addresses into line number/file name pairs (GNU)

Syntax:

addr2line_variant [options] [addr ...]

where addr2line_variant depends on the target platform, as follows:

addr2line_variant Target platform

ntoarmv7-addr2line ARMv7

ntox86-addr2line x86

Runs on:

Linux, Microsoft Windows

Description:

The addr2line utility translates program addresses into file names and line numbers.

Given an address and an executable, it uses the debugging information in the executable to figure out which file name and line number are associated with a given address.

For detailed documentation, see the GNU website at http://www.gnu.org/.

Contributing author:

GNU

34 A

(35)

addvariant

Add a new OS, CPU, or VARIANT directory structure to a source tree

Syntax:

addvariant [-c] [-i init_lvls] [[os_name] cpu_name] variant_name

Runs on:

Linux, Microsoft Windows

Options:

-c

Add the created directory structure to the CVS repository on the next cvs commit.

-i init_lvls

Create the initial common.mk and Makefile files in the current working directory. The Makefile contains a line defining the level(s) contained in the directory structure. Specify init_lvls as OS, OS/CPU, or OS/CPU/VARI ANT (use a slash (/) or a dash (-) to separate multiple levels).

os_name

The name of the operating system to add (e.g. nto, linux).

cpu_name

The name of the CPU to add (e.g. arm, x86).

variant_name

The name of the variant to add (e.g. o, a.le)

Description:

The addvariant utility is a shell script that creates a directory structure for your source tree. It also ensures that each level of this structure contains necessary files used by the make (p. 1166) utility.

Using addvariant to create your variant directory structure enables you to take advantage of the makefile rules of the QNX Neutrino build environment. For more

35 addvariant

(36)

information on these rules, see the Conventions for Recursive Makefiles and Directories appendix of the QNX Neutrino Programmer's Guide.

The project level includes a file called common.mk. This file contains any “special”

flags and settings needed for compilation and linking.

Each level in the directory structure needs a properly constructed Makefile with appropriate macros and include files. At most levels, Makefile includes recurse.mk, the file used by higher-level makefiles to recurse into lower-levels. The Makefile at the lowest level of the directory tree (the variant level) includes the common.mk file from the project level instead of recurse.mk.

If requested, addvariant also adds the directories and files it has created to CVS, ready for your next cvs commit.

Dealing with GNU projects

The utility begins by checking to see the projects conform to a GNU-type structure.

If the current working directory (CWD) contains files named configure and Makefile.in, addvariant assumes that the project is configured in the GNU style. In that case, it automatically squashes the directory levels (as described below) into a single OS-CPU-VARIANT level and creates GNUmakefile files in the newly created directories along with a recursing Makefile to take advantage of them.

After you've run addvariant, create an executable shell script called build-hooks file in the root of the project. This script defines some shell functions that make invokes to build your project properly; for more information, see “GNU configure”

in the Conventions for Recursive Makefiles and Directories appendix of the QNX Neutrino Programmer's Guide.

Creating the initial files

The addvariant utility either creates and installs standard Makefile and common.mk files in the CWD, or, if these files already exist, edits them to add the same standard script lines used for recursing.

Creating the subdirectories and files

Starting from the CWD, the addvariant utility searches down into the directory tree looking in each Makefile for a line starting with LIST. This line indicates the particular directory level the Makefile is placed in, like this:

• LIST=OS (if three levels are specified)

• LIST=CPU (if two levels are specified)

• LIST=VARIANT (if one level is specified)

The utility then decides whether to create a subdirectory by looking at the:

• LIST macro

• *_name options

36 A

(37)

• current subdirectories

If needed, addvariant then creates an appropriately named subdirectory containing a suitable Makefile.

This process continues down into the directory structure until all the required directories have been created and populated with the necessary recursing Makefile.

Squashing levels

The addvariant utility has the ability to “squash” directory levels together. If you enter the command:

addvariant -i OS/CPU/VARIANT nto x86 o

addvariant creates a recursing Makefile in the CWD structure that has a line like this:

LIST=OS CPU VARIANT

and then creates a single subdirectory called nto-x86-o.

Any subsequent invocation of addvariant in the tree notices this squashing of the directory levels and automatically generates the appropriate directory structure.

For more information, see Andrew Oram and Steve Talbott, Managing Projects with make, O'Reilly and Associates, 1991.

Examples:

Create a two-level directory called nto-x86/o:

addvariant -i OS/CPU nto x86 o

Create the opposite two-level scheme, nto/x86-o:

addvariant -i OS nto x86/o

For detailed examples, see “Examples of creating Makefiles” in the Conventions for Recursive Makefiles and Directories appendix of the QNX Neutrino Programmer's Guide.

37 addvariant

(38)

applypatch

Install or uninstall a patch (QNX Neutrino)

Since this utility modifies the installation tree, you must run it as a privileged user. It also requires the environment be properly set. On Linux, if you use

sudo

(as would be the case on Ubuntu), you must also specify the -E option to preserve the environment. In this case, however, the

PATH

environment variable is set to a safe one for security reasons, so you need to specify the full path to the utility:

sudo -E $QNX_HOST/usr/bin/applypatch patchfile

Syntax:

Install a patch:

applypatch [-b] [-c] [-d path] [-F] [-H] [-v] patch_file

List the installed patches:

applypatch -l

Uninstall a patch:

applypatch -U num

Runs on:

Linux, Microsoft Windows

Options:

-b

Don't make a backup.

If you specify the -b option, you won't be able to uninstall this patch or any patches applied after it. We don't recommend this option for general use.

-c

Extract the patch contents only. No metadata will be recorded, nor will any backup file be generated. This is useful when pulling out individual files for testing, but we don't recommend this option for general use.

-d path

38 A

(39)

Specify the destination path. This path will be the root directory used for extracting the patch contents as well as for storing the patch metadata. The default is the currently active QNX Neutrino installation.

-F

Turn off prompting by forcing a “yes” answer to all queries. Normally newer files aren't overwritten by older files from the patch. This option disables that check. This means locally updated files may be silently replaced by an older version from the patch.

-H

(QNX Neutrino 6.5.0 and later) Install all host-side files in the patch. By default, applypatch installs only those for the current host OS.

The version of

applypatch

in 6.4.1 installs host-side files for all host OSs.

-l

List the patches, ordered from newest to oldest (based on installation time).

-v

Be verbose. Display some information on progress and activities.

-U num

Uninstall the patch with the specified ID number, num.

Due to the nature of the patching process, any patch that was installed after patch ID num will be uninstalled as well. In effect, you'll roll back to the state the system was in just before patch ID num and all subsequent patches were applied.

Description:

The applypatch utility installs and uninstalls QNX Neutrino patches, and also lists the installed patches. It's installed in $QNX_HOST/usr/bin and supports our current patch tar (p. 1890) files.

On Windows, run

applypatch

in

cmd.exe.

This utility first backs up any files which will be overwritten and then extracts the patch files.

39 applypatch

(40)

If you've applied a sequence of patches, you can uninstall them only in reverse order.

If you select a patch (Patch ID X) for uninstallation, then any patches installed since Patch ID X are also marked for uninstallation. A warning and list of affected patches is printed and confirmation requested for this situation.

40 A

(41)

aps

Manage adaptive scheduler partitions

Syntax:

aps show [-d delay] [-f shorthand] [-l] [-v...]

[partition_name ...]

aps create -b budget [-B critical_budget] partition_name aps modify [-b budget] [-B critical_budget] partition_name aps modify [-y bankruptcy_policy ...] [-S scheduling_policy...]

[-s security_policy ...] [-w windowsize_ms]

Runs on:

QNX Neutrino

Options:

-B milliseconds

Specify the critical CPU budget, in milliseconds. The default is 0.

-b budget

Specify the CPU budget as a percentage.

-d delay

The delay period, in tenths of a second, when using the -l option. The default is 50.

-f shorthand

Display the information specified by shorthand:

• all — all the below

• overall_stats — information about the last bankruptcy

• scheduler — parameters for the thread scheduler, including the current security setting, bankruptcy policy, and the size of the averaging window

• partitions — information about the partitions, including their names, IDs, parent IDs, budgets, critical budgets, and the process and thread IDs of the last thread to go bankrupt

41 aps

(42)

• usage — the amount of budget and critical budget that each partition is currently using

The default is usage.

-l

(“el”) Loop mode; display the information at the interval specified by the -d option.

-S scheduling_policy …

Specify the policies for the adaptive partitioning scheduler. Each scheduling_policy must be one of:

• normal

• freetime_by_ratio

The default is normal. For more information about the policies, see

“Scheduling policies” in the entry for SchedCtl() in the QNX Neutrino C Library Reference.

-s security_policy …

Specify the security policies to add to the system. Each security_policy must be one of:

• root0_overall

• root_makes_partitions

• sys_makes_partitions

• parent_modifies

• nonzero_budgets

• root_makes_critical

• sys_makes_critical

• root_joins

• sys_joins

• parent_joins

• join_self_only

• partitions_locked

• recommended

• flexible

• basic

• none

42 A

(43)

The default is none. For more information about the policies, see the description of SCHED_APS_ADD_SECURITY in the entry for SchedCtl() in the QNX Neutrino C Library Reference.

Once you've added a security policy, you can't remove it, except by rebooting the system.

-v...

Be verbose; display more information with the show command:

• -v — display the budget usage over the last averaging window, window 2 (typically 10 times the length of the averaging window), and window 3 (typically 100 times the length of the averaging window)

• -vv — display the budget usage and critical budget usage over the last averaging window, window 2, and window 3

-w windowsize_ms

Set the size of the averaging window, in milliseconds, for the system. You can set the window size to any value from 8 ms to 400 ms.

If you change the tick size of the system at runtime, do so before defining the adaptive partitioning scheduler's window size. That's because QNX Neutrino converts the window size from milliseconds to clock ticks for internal use.

For more information, see “Choosing the window size” in the System Considerations chapter of the Adaptive Partitioning User's Guide.

-y bankruptcy_policy …

Set the bankruptcy policy for the system to the specified items. Each bankruptcy_policy must be one of:

• cancel_budget — set the offending partition's critical budget to zero, which forces the partition to be scheduled by its percentage CPU budget only. This also means that a second bankruptcy can't occur.

• log — not currently implemented.

• reboot — cause the system to crash with a brief message identifying the offending partition. This is the most severe response, suggested for use while testing a product, to make sure bankruptcies are never ignored.

You probably shouldn't use this option in your finished product.

• basic — deliver bankruptcy-notification events and make the partition out-of-budget for the rest of the scheduling window (nominally 100 ms).

43 aps

(44)

• recommended — the combination of cancel_budget and log.

• none — do nothing.

The default is basic. For more information about the policies, see “Handling bankruptcy” in the entry for SchedCtl() in the QNX Neutrino C Library Reference.

Description:

Use the aps command to create, modify, and query adaptive partitions from the command line, as well as to set the averaging window, and the security and bankruptcy policies for the entire system.

You can't include slashes ( / ) in a partition name.

To launch an application into a partition, use the -Xaps option to the on (p. 1417) command.

Examples:

Create a partition called Drivers with a budget of 20% and a critical budget of 5 milliseconds:

aps create -b 20 -B 5 Drivers

Change the Drivers partition's budget to 25% and its critical budget to 7 milliseconds:

aps modify -b 25 -B 7 Drivers

Specify a bankruptcy policy of recommended and a security policy of root_makes_partitions for the entire system:

aps modify -y recommended -s root_makes_partitions

Display the amount of the budget and critical budget that the partitions are using, every 2 seconds:

aps show -l -d 20 -f usage

Since usage is the default shorthand for the -f option, the above command is the same as:

aps show -l -d 20

44 A

(45)

ar

Create and maintain library archives (POSIX)

Syntax:

ar_variant -key_letter[mod [relpos]] archive [member…]

ar_variant -M [ <mri-script ]

where ar_variant depends on the target platform, as follows:

ar_variant Target platform

ntoarmv7-ar ARMv7

ntox86-ar x86

Runs on:

Linux, Microsoft Windows

Description:

The ar program creates and modifies archives, and extracts members from them. An archive is a single file holding a collection of other files in a structure that makes it possible to retrieve the original individual files (called members of the archive).

The original files' contents, mode (permissions), timestamp, owner, and group are preserved in the archive; you can restore them on extraction. The ar utility can maintain archives whose members have names of any length.

For detailed documentation, see the GNU website at http://www.gnu.org/.

Contributing author:

GNU

45 ar

(46)

arp

Address Resolution Protocol (ARP) display and control

Syntax:

arp [-n] hostname arp [-nv] -a arp [-v] -d -a

arp [-v] -d hostname [pro [iface_name]]

arp -s hostname ether_addr [temp] [pub [pro [iface_name]]]

arp -f filename Runs on:

QNX Neutrino

Options:

-a

Display all of the current ARP entries.

-d hostname

Delete an entry for the specified host. Only the superuser can use this option.

-f filename

Load the ARP cache with entries found in the specified file. Entries in the file should be of the form:

hostname ether_addr [pub] [temp]

with argument meanings as given for the -s option.

-n

Don't try to resolve hostnames.

-s hostname ether_addr [temp] [pub [pro [iface_name]]]

Create an ARP entry for the host hostname with the Ethernet address ether_addr. The Ethernet address is given as six hex bytes separated by colons.

If pub is given, the entry is “published.” That is, this system acts as an ARP server, responding to requests for hostname, even though the IP address that's mapped to hostname isn't the address of this system.

46 A

(47)

The entry is permanent unless the word temp is given in the command.

Specify the pro string to create or delete a proxy-only ARP entry.

The iface_name argument is the name of the interface (e.g. fxp0).

-v

Be verbose.

hostname

A host name or the IP address.

Description:

The arp utility displays and modifies the Internet-to-Ethernet address translation tables used by the Address Resolution Protocol (ARP).

With no options, the utility displays the current ARP entry for hostname. The host may be specified by name or by number, using Internet dot notation.

License:

This utility is based on copyright software of The Regents of the University of California;

for licensing information, see the Third Party License Terms List at http://licensing.qnx.com/third-party-terms/.

47 arp

(48)

asa

Translate line-printer control sequences to newlines/form feeds (POSIX)

Syntax:

asa [filename...]

Runs on:

QNX Neutrino

Options:

None.

Description:

The asa utility writes its input files to standard output, mapping carriage control characters from the files to line-printer control sequences. If you specify - for a file name, asa reads from standard input.

All characters in column position 1 are removed from the input, and the following actions are performed, depending on the character:

Space

The rest of the line is output without change.

0 A newline (\n) character is output, followed by the rest of the input line.

1 A form-feed character (0x0C) is output, followed by the rest of the input line.

+

The newline of the previous line is replaced with a carriage return (0x0D), followed by the rest of the input line.

Any other character in column 1 is left unchanged.

Exit status:

0

48 A

(49)

All input files were output successfully.

>0

An error occurred.

49 asa

(50)

/etc/autoconnect

Automatic TCP/IP connection-configuration script

Name:

/etc/autoconnect

Description:

The /etc/autoconnect script is run when an application needs to establish a TCP/IP connection to a remote host. This file can be in any form (e.g. a shell script or an executable), and contains all of the necessary commands required to create the connection.

To activate the script, define the environment variable AUTOCONNECT and set its value to 1.

If there's no route to a remote host (see route (p. 1680), ifconfig (p. 957), or the options to io-pkt* (p. 1007)), or there are no nameservers defined (see

/etc/nsswitch.conf (p. 1369)) and a hostname can't be resolved, the autoconnect script is run. The exit status of the script determines whether or not a retry is attempted:

Zero

The socket library attempts the action again.

Nonzero

It doesn't retry because the script failed.

One time you might use this feature is when you have a dialup ISP account for internet access. The ppp link is established only when an application needs to reach a host over the link. When the link is terminated depends on inactivity timeouts specified by the client or server, errors, or other events. The autoconnect script only launches commands to establish a connection; it doesn't terminate the connection.

Suppose that a host is configured with only the localhost interface, and no nameservers.

You need to create a script:

pppd connect "/bin/chat -v -f /etc/chat" defaultroute \ +resconf 115200 updetach /dev/ser2

exit

The chat (p. 99) utility is used to dial the service provider. The important option here is the updetach option. This option daemonizes pppd (p. 1560) after the PPP interface has been configured. This way, the script doesn't exit until the interface is configured.

If an application attempts to resolve a hostname, the application blocks while a connection to an ISP is established, which provides a nameserver and a default route.

50 A

(51)

When the script exits with a status of zero, the socket library retries and the application continues, assuming that the function succeeded. If an exit status of non-zero is returned, the socket library returns the original error to the application.

51 /etc/autoconnect

(52)

(53)

Chapter 3 B

The QNX Neutrino resource managers and utilities are described here in alphabetical order.

A ¦ B ¦ C ¦ D ¦ E ¦ F ¦ G ¦ H ¦ I ¦ J ¦ K ¦ L ¦ M ¦ N ¦ O ¦ P ¦ Q ¦ R ¦ S ¦ T ¦ U ¦ V ¦ W ¦ X ¦ Y ¦ Z This chapter describes the utilities, etc. whose names start with “B”.

53

(54)

basename

Return the nondirectory portion of pathname (POSIX)

Syntax:

basename string [suffix]

Runs on:

QNX Neutrino, Microsoft Windows

Options:

string

A string of text.

suffix

A string of text.

Description:

The basename utility is useful primarily for extracting the filename portion of a pathname, but since it performs only string operations, you can use it with any string.

The basename utility prints to standard output a substring of its string argument, plus a newline character. The basename utility forms this substring by doing the following, in order:

1. Discarding any trailing slash (/) characters.

2. Discarding all characters up to and including the last slash character.

3. Deleting the string argument's suffix, provided you've specified a suffix operand that's identical to the string operand's suffix.

If suffix is equal to the remaining string, the suffix isn't removed (e.g. if suffix is prog.c and the remaining string is prog.c, the suffix .c isn't removed).

The result is a null string only if string is a null string (""). In this case, basename outputs a single newline character.

If string consists entirely of slash characters, basename prints a single slash, followed by a newline character.

You'll use the basename utility most often within shell scripts, where it's normally invoked inside back-ticks (`...`), or contained in $(...).

UtilitiesReference QNX Neutrino RTOS ® ®

QNX

Software Development Platform 6.6

QNX

Software Development Platform 6.6

QNX ® Neutrino ® RTOS

Utilities Reference

1996–2014, QNX Software Systems Limited, a subsidiary of BlackBerry. All rights reserved.

QNX Software Systems Limited 1001 Farrar Road

Ottawa, Ontario K2K 0B3 Canada

Voice: +1 613 591-0931 Fax: +1 613 591-3579 Email: info@qnx.com Web: http://www.qnx.com/

QNX, QNX CAR, Neutrino, Momentics, Aviage, and Foundry27 are trademarks of BlackBerry Limited that are registered and/or used in certain jurisdictions, and used under license by QNX Software Systems Limited. All other trademarks belong to their respective owners.

Electronic edition published: Thursday, March 6, 2014

Table of Contents

About This Reference ...19

Typographical conventions ...20

Technical support ...22

Chapter 1: Utility Conventions ...23

Syntax conventions ...24

Interpreting utility syntax ...24

Invoking utilities ...25

File conventions ...27

Signal conventions ...28

Exit status conventions ...29

Error conventions ...30

Chapter 2: A ...31

ability ...32

addr2line ...34

addvariant ...35

applypatch ...38

aps ...41

ar ...45

arp ...46

asa ...48

/etc/autoconnect ...50

Chapter 3: B ...53

basename ...54

bc ...56

bison ...64

bootpd ...65

/etc/bootptab ...68

brconfig ...74

bunzip2 ...78

bzcat ...79

bzip2 ...80

bzip2recover ...82

Chapter 4: C ...83

c++filt ...84

calib-touch ...85

QNX

Neutrino

RTOS

cam-cdrom.so ...89

cam-disk.so ...91

cam-optical.so ...93

cat ...95

CC, cc ...97

cfgopen ...98

chat ...99

chattr ...107

chgrp ...109

chkdosfs ...111

chkfsys ...114

chkqnx6fs ...121

chmod ...124

chown ...129

cksum ...131

clear ...133

cmp ...134

comm ...136

confstr ...138

coreinfo ...140

cp ...141

cpio ...151

cron ...155

crontab ...157

csplit ...161

ctags ...163

cut ...166

Chapter 5: D ...169

QNX ^® Neutrino ^® RTOS