ExternalVendorCode/trick
1
0
Fork 0
mirror of https://github.com/nasa/trick.git synced 2025-01-18 18:56:31 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

man pages completely out of date

Browse Source 
First step to updating man pages, renaming pages to match executable name and deleting man pages for commands long gone.

refs #253
This commit is contained in:
Alex Lin 2016-06-20 11:22:45 -05:00
parent fb4601734f
commit 11fb71f036
8 changed files with 0 additions and 489 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
share/man/man1/Create_Token.1
View File

@ -1,37 +0,0 @@
.TH Create_Token.sh 1 "May 17, 2000" "Trick" "Trick User's Manual"
.SH NAME
Create_Token.sh \- Tokenize an HTML file
.SH SYNOPSIS
\fBCreate_Token.sh\fP [\fIdirectory_name\fP]
.SH DESCRIPTION
\fBCreate_Token.sh\fP is a bourne shell script whick executes Create_Token.
\fBCreate_Token\fP strips paths off of HREFs in html documents and replaces
them with a token (%%PATH_TOKEN%%). With no arguments \fBCreate_Token.sh\fP
will recursively convert all .html files to .token files starting in the
current distrctory on the local machine. If called with a directory name
\fBCreate_Token.sh\fP will use that directory name as the starting directory.
.SH FILES
.TP
.SH DEPENDENCY
.TP
\fBDependencies\fP: /bin/sh, echo, find
.TP
.SH "SEE ALSO"
All Trick model developers and users should go through the tutorial found
in the \fITrick Simulation Environment User Training Materials\fP.
The canonical reference for all Trick commands, files and utilities is the
\fITrick Simulation Environment User's Guide\fP. Information specific to a
given release of Trick tools is contained in the \fITrick Simulation
Environment Version Description\fP for that release.
.PP
.\" .SH DIAGNOSTICS
.\" How to determine why the command failed.
.SH BUGS
Known bugs will be placed in the \fIVersion Description Document\fP located in
$TRICK_HOME/docs area. If you would like to report a bug, contact
vetter@lincom-asg.com.
.SH AUTHORS
The \fBCreate_Token.sh\fP command was written by Greg Alexander and is maintained by the
Trick development staff. This man page was written by Greg Alexander,
address all discrepancies to grega@lincom-asg.com.

238
share/man/man1/MIS.1
View File

@ -1,238 +0,0 @@
.TH MIS 1 "7 July 97" "Trick" "Trick User's Manual"
.SH NAME
MIS \- run the Trick Module Interface Specification processor.
.SH SYNOPSIS
\fBMIS\fP [\fB-d\fP] [\fB-c\fP] [\fIsource_file.c\fP]
.SH DESCRIPTION
The Module Interface Specification processor reads source code files and
adds module interface information to the module catalog. \fBMIS\fP also
generates Hypertext Mark-up Language (HTML) which serves as online
documentation of the source code.
.PP
\fBMIS\fP must be executed in the version directory which holds the source
code to be processed. If source file(s) are specified on the
command line, only those source file(s) are processed, otherwise all source
files in the current working directory are processed. \fBMIS\fP understands
*nix wild card characters in the filename supplied on the command line.
.PP
\fBMIS\fP must be performed on all source code files in a version directory
prior to running \fBCP\fP(1) on simulations which use the code in that
directory. This is to ensure that the object code link list is constructed
properly by \fBCP\fP(1) (the module catalog contains information on object
code dependencies).
.SS Options
.TP
\fB-d\fP
Debug mode. \fBMIS\fP will echo source files to the screen as
they are processed. This helps the user find his interface errors.
.TP
\fB-c\fP
Do not trap the common UNIX and USER signals. This feature allows a core to be
dumped.
.TP
.SH "SOURCE FILE FORMAT"
The source language files must have certain features to be successfully
processed by \fBMIS\fP. These include a special comment header at the
beginning of each function, and a special format for the function entry point
and calling arguments.
.PP
A comment header must precede each function and have the following syntax:
.sp
.nf
.ne 11
\fB/* PURPOSE: (\fIpurpose\fP)
REFERENCES:
(((\fIauthor\fP) (\fItitle\fP) (\fIpublication\fP) (\fIpublisher\fP) (\fIdate\fP) (\fIpage\fP)
\fR[\fB((\fIauthor\fP) (\fItitle\fP) (\fIpublication\fP) (\fIpublisher\fP) (\fIdate\fP) (\fIpage\fP))\fR] . . .\fP)
ASSUMPTIONS AND LIMITATIONS: ((\fIassumption 1\fP) \fR[\fP(\fIassumption 2\fP)\fR] . . .\fP)
CLASS: (\fImodule_classification\fP)
LIBRARY DEPENDENCY: ((\fIobject.o\fP) \fR[\fP(\fIobjectN.o\fP)\fR] . . . [\fP(\fIlib.a\fP)\fR] . . .\fP)
PROGRAMMERS:
(((\fIname\fP) (\fIemployer\fP) (\fIdate\fP) (\fICR#\fP) (\fIdescription\fP))
\fR[\fP((\fIname\fP) (\fIemployer\fP) (\fIdate\fP) (\fICR#\fP) (\fIdescription\fP))\fR] . . .\fP)
*/\fR
.fi
.sp
Since parentheses are used as field delimiters within the comment header,
it is impossible to use parentheses within the fields. The PURPOSE section
should be a brief description of what the function does. The REFERENCES section
may contain any number of references, with each reference possessing an author,
title, publisher, date, and page number. Notice how the parentheses are nested.
The ASSUMPTIONS AND LIMITATIONS section may contain any number of assumptions
or limitations. The CLASS field may contain any of the module
classifications listed in the "Module Classifications" section below.
.PP
The LIBRARY DEPENDENCY section must reference all object code files which the
current module directly depends upon, beginning with the current module's
object file. To understand direct dependence, assume that \fIthis.c\fP calls
\fIthat.c\fP, which calls \fIanother.c\fP. \fIthis.c\fP should have
\fIthat.o\fP in it's LIBRARY DEPENDENCY section, but not \fIanother.o\fP.
\fBCP\fP(1), \fBmake_build\fP(1), and \fBmake\fP(1) are responsible for
sorting out indirect dependencies and doing the right thing.
Directory paths which begin with a "/" character (like a *nix absolute path)
are assumed to be relative to the \fIbin_${TRICK_HOST_CPU}\fP directory. Directory
paths which begin with a character other than "/" (like a *nix relative path)
are assumed to be relative to the module version directory.
For the purposes of the LIBRARY DEPENDENCY section, assume that the object
files remain in the version directory (even though the Makefiles generated by
\fBmake_build\fP(1) move the object files to the
\fIbin_${TRICK_HOST_CPU}/model/version\fP directory).
.PP
The PROGRAMMERS section may contain any number of programmer records, each of
which contains the programmer's name, employer, date of file modification,
the associated Change Request number, and a brief description of the
modification.
.PP
The function entry point syntax follows standard ANSI C syntax and must come
after the comment header. Between the comment header and the entry point, any
valid C code or preprocessor directives are permissible. The Trick function
entry point syntax requires several comments - one for the function return
value and one for each calling argument. All functions which have a
CLASS other than N/A should have their calling arguments passed as pointers
(by reference). By default, the executive passes only addresses to the
functions it calls. There exists syntax for the \fIS_define\fP file which
allows a developer to pass arguments by value rather than by address, but
always using "call by reference" will ensure consistency and reduce
confusion. The Trick function entry point syntax follows:
.sp
.nf
.ne 3
[\fIreturn type\fP] \fBmodule_name( \fR[\fIvoid\fP)\fR] \fB/* RETURN \fIunits description\fP */
\fR[\fIarg1_type arg1\fB, /* IN | INOUT | OUT: \fIunits description\fP */\fR]\fP
\fR[\fIarg2_type arg2\fB, /* IN | INOUT | OUT: \fIunits description\fP */\fR]
.fi
.sp
The function entry point must be immediately followed by a comment which
specifies the function return value's measurement units and description.
Likewise, each calling argument must also be followed by a comment which
specifies the calling argument's usage in the function, either IN, INOUT, or
OUT, the argument's measurement units, and a brief description of the
argument.
.SS "Module Classifications"
.TP
\fBN/A\fP
.br
Not applicable -- the module's execution is not managed by the executive, but
by another module.
.TP
\fBasynchronous\fP
The executive does not wait for the module to complete before returning to
normal job scheduling.
.TP
\fBasynchronous_mustfinish\fP
The executive does not wait for the module to complete before returning to
normal job scheduling, but the job must finish before its next regularly
scheduled time or the executive will initiate a shutdown.
.TP
\fBautomatic\fP
This module classification reschedules its own next call time.
.TP
\fBderivative\fP
This module classification defines derivatives of the Equations of Motion (EOM).
.TP
\fBdynamic_event\fP
Provides a continuous time dependent equation whose root defines a
discontinuous event in the system EOM. Evaluation of the function returns an
estimate of the time remaining before reaching the root.
.TP
\fBeffector\fP
This module classification is typically used to model control system effectors.
It provides an interface between the simulated control system and the simulated
forces.
.TP
\fBeffector_emitter\fP
Similar to the \fBeffector\fP class, but used for the "action" portion of an
action-reaction effector system.
.TP
\fBeffector_receiver\fP
Similar to the \fBeffector\fP class, but used for the "reaction" portion of an
action-reaction effector system.
.TP
\fBenvironment\fP
Time dependent boundary conditions.
.TP
\fBfreeze\fP
.br
This module classification executes cyclically during simulation FREEZE mode
only.
.TP
\fBfreeze_init\fP
This module classification is executed once at the time of FREEZE mode
initialization.
.TP
\fBinitialization\fP
This module classification is executed only once (at simulation time = zero).
.TP
\fBintegration\fP
Equations of motion state integration function.
.TP
\fBlogging\fP
Simulation data recording or displaying.
.TP
\fBrandom\fP
.br
Execution of this module classification is scheduled according to a Gaussian
distribution. The mean and standard deviation of the desired cyclic period
are furnished to the executive.
.TP
\fBrestart\fP
Similar to the \fBinitialization\fP classification, but only executed when
simulation is being restarted from a checkpoint file.
.TP
\fBscheduled\fP
Typical flight software and hardware subsystems. The module is scheduled for
execution periodically.
.TP
\fBsensor\fP
.br
This module classification is typically used to model control system sensors.
It provides an interface between the simulated dynamics and the simulated
control system.
.TP
\fBsensor_emitter\fP
Similar to the \fBsensor\fP class, but used for the emitter portion of an
integrated multi-component sensor system.
.TP
\fBsensor_receiver\fP
Similar to the \fBsensor\fP class, but used for the receiver portion of an
integrated multi-component sensor system.
.TP
\fBsensor_reflector\fP
Similar to the \fBsensor\fP class, but used for the reflector portion of an
integrated multi-component sensor system.
.TP
\fBshutdown\fP
This class of module is executed once at simulation termination (e.g. you may
have some hardware that you'd like to safe before shutting off its control
system).
.TP
\fBunfreeze\fP
This class of module executes once at the time of FREEZE mode termination.
.SH FILES
.TP
\fIcatalog/modules\fP
Contains catalog information about the modules.
.TP
\fIhtml/\fP
This directory gets the generated Hypertext Mark-up Language which documents
the source files.
.SH "SEE ALSO"
\fBcatalog\fP(1), \fBCP\fP(1), \fBmake_build\fP(1)
.PP
All Trick model developers and users should go through the tutorial found
in the \fITrick Simulation Environment User Training Materials\fP.
The canonical reference for all Trick commands, files and utilities is the
\fITrick Simulation Environment User's Guide\fP. Information specific to a
given release of Trick tools is contained in the \fITrick Simulation
Environment Version Description\fP for that release.
.\" .SH DIAGNOSTICS
.\" How to determine why the command failed.
.SH BUGS
Known bugs will be placed in the \fIVersion Description Document\fP located in
$TRICK_HOME/docs area. If you would like to report a bug, contact
vetter@lincom-asg.com.
.SH AUTHORS
The \fBMIS\fP command was written by Rob Bailey and is maintained by the
Trick development staff. This man page was written by Rick Sykes,
address all discrepancies to sykes@lincom-asg.com.

37
share/man/man1/Replace_Token.1
View File

@ -1,37 +0,0 @@
.TH Replace_Token.sh 1 "May 17, 2000" "Trick" "Trick User's Manual"
.SH NAME
Replace_Token.sh \- Resolve tokens in an HTML file
.SH SYNOPSIS
\fBReplace_Token.sh\fP [\fIdirectory_name\fP]
.SH DESCRIPTION
\fBReplace_Token.sh\fP is a bourne shell script whick executes Replace_Token.
\fBReplace_Token\fP resolves tokens in .token files created by Create_Token.sh
and converts them to proper .html files. With no arguments \fBReplace_Token.sh\fP
will recursively convert all .token files to .html files starting in the
current distrctory on the local machine. If called with a directory name
\fBReplace_Token.sh\fP will use that directory name as the starting directory.
.SH FILES
.TP
.SH DEPENDENCY
.TP
\fBDependencies\fP: /bin/sh, echo, find
.TP
.SH "SEE ALSO"
All Trick model developers and users should go through the tutorial found
in the \fITrick Simulation Environment User Training Materials\fP.
The canonical reference for all Trick commands, files and utilities is the
\fITrick Simulation Environment User's Guide\fP. Information specific to a
given release of Trick tools is contained in the \fITrick Simulation
Environment Version Description\fP for that release.
.PP
.\" .SH DIAGNOSTICS
.\" How to determine why the command failed.
.SH BUGS
Known bugs will be placed in the \fIVersion Description Document\fP located in
$TRICK_HOME/docs area. If you would like to report a bug, contact
vetter@lincom-asg.com.
.SH AUTHORS
The \fBReplace_Token.sh\fP command was written by Greg Alexander and is maintained by the
Trick development staff. This man page was written by Greg Alexander,
address all discrepancies to grega@lincom-asg.com.

124
share/man/man1/catalog.1
View File

@ -1,124 +0,0 @@
.TH CATALOG 1 "May 17, 2000" "Trick" "Trick User's Manual"
.SH NAME
catalog \- view and/or delete items from the Trick module catalog
.SH SYNOPSIS
\fBcatalog\fP [\fB-c\fP \fImodule_class_search_name\fP] |
[\fB-d\fP<\fBm\fP|\fBs\fP|\fBe\fP|\fBp\fP> <\fIid_number\fP> [\fI-noconfirm\fP]] |
[\fB-e\fP [\fIenumerated_type_search_name\fP]] |
[\fB-initialize\fP] |
[\fB-m\fP[\fBS\fP] [\fImodule_search_name\fP]] |
[\fB-o\fP \fImodule_id_number\fP]
[\fB-rebuild\fP] |
[\fB-repair\fP] |
[\fB-s\fP [\fIstructure_search_name\fP]] |
[\fB-h\fP] |
[\fB-i\fP] |
[\fB-versions\fP] |
[\fB-v\fP] |
[\fB-b\fP] |
[\fB-a\fP] |
[\fB-p\fP [<\fIsearch_string\fP>]]
.SH DESCRIPTION
\fBcatalog\fP is a view port into the module catalog (which is stored in binary
format). Executed without arguments, \fBcatalog\fP lists all enumerated types,
data structure typedefs, and modules in the catalog.
.SS Options
.TP
\fB-c\fP
List all modules in the catalog whose classification contains
\fImodule_class_search_name\fP string (case sensitive).
.TP
\fB-d\fP
If \fIversion_dir\fP is supplied, \fBcatalog\fP deletes all enumerated types,
structures and modules associated with the specified version directory. The
\fIversion_dir\fP is specified relative to \fB${TRICK_HOME}/module_source\fP.
If \fBm\fP, or \fBs\fP, or \fBe\fP are supplied with an \fIid_number\fP, the
specified module, data structure, or enumerated type is deleted from the
catalog.
.TP
\fB-e\fP
List all enumerated types in the catalog, or if
\fIenumerated_type_search_name\fP is supplied, list all enumerated types
which contain \fIenumerated_type_search_name\fP search string (case sensitive).
.TP
\fB-initialize\fP
Create a master catalog file in the current directory, including
various required paths to sim_services, etc.
.TP
\fB-i\fP
Same as catalog -initialize
.TP
\fB-m\fP
List all modules in the catalog, or if \fImodule_search_name\fP is supplied,
list all modules which contain \fImodule_search_name\fP search string (case sensitive).
.TP
\fB-o\fP
Lists complete (nested) list of object dependencies for the specified
\fImodule_id_number\fP.
.TP
\fB-rebuild\fP
Look through all include paths found in the user's \fB${TRICK_CFLAGS}\fP environment
variable for catalog files. Any which are found are added to the master
catalog in the current directory.
.TP
\fB-b\fP
Same as catalog -rebuild
.TP
\fB-repair\fP
Look through all entries in the current catalog file, and delete those
paths which do not contain catalog directories.
.TP
\fB-s\fP
List all data structure typedefs in the catalog, or if
\fIstructure_search_name\fP is supplied, list all data structure typedefs
which contain \fIstructure_search_name\fP search string (case sensitive).
.TP
\fB-h\fP
Echo catalog help screen.
.TP
\fB-versions\fP
Lists the current version and owner of all catalog database files within the current list of catalog directories.
.TP
\fB-v\fP
Same as catalog -versions.
.TP
\fB-a\fP
Echo ALL catalog source directories, modules, enumerated types, structure types to the screen.
.TP
\fB-p\fP
Echo all source directories to the screen. If the <\fIsearch_string\fP> argument is included, only those directory names which contain <\fIsearch_string\fP> are echoed.
.TP
.SH FILES
.TP
\fIcatalog/depends\fP
Contains dependency information.
.TP
\fIcatalog/enumerated\fP
Contains information about the enumerated data types.
.TP
\fIcatalog/modules\fP
Contains information about the modules.
.TP
\fIcatalog/structures\fP
Contains information about the data structures.
.SH "SEE ALSO"
All Trick model developers and users should go through the tutorial found
in the \fITrick Simulation Environment User Training Materials\fP.
The canonical reference for all Trick commands, files and utilities is the
\fITrick Simulation Environment User's Guide\fP. Information specific to a
given release of Trick tools is contained in the \fITrick Simulation
Environment Version Description\fP for that release.
.PP
\fBCP\fP(1), \fBICG\fP(1), \fBMIS\fP(1)
.\" .SH DIAGNOSTICS
.\" How to determine why the command failed.
.SH BUGS
Known bugs will be placed in the \fIVersion Description Document\fP located in
$TRICK_HOME/docs area. If you would like to report a bug, contact
vetter@lincom-asg.com.
.SH AUTHORS
The \fBcatalog\fP command was written by Rob Bailey and is maintained by the
Trick development staff. This man page was written by Rick Sykes,
address all discrepancies to sykes@lincom-asg.com.

53
share/man/man1/make_build.1
View File

@ -1,53 +0,0 @@
.TH MAKE_BUILD 1 "May 17, 2000" "Trick" "Trick User's Manual"
.SH NAME
make_build \- build a (Trick) Makefile
.SH SYNOPSIS
\fBmake_build\fP
.SH DESCRIPTION
\fBmake_build\fP generates a Makefile for a module source directory.
It must be executed within the module source directory which is to be
processed.
.PP
The Makefile produced by \fBmake_build\fP has the following maintenance targets:
.TP
\fBdepend\fP
Runs 'make_depend' in the model directory.
.TP
\fBclean\fP
Removes all object code generated by this model directory.
.TP
\fBreal_clean\fP
Removes all object code generated by this model directory, all source code
generated by \fBICG\fP in this model directory, and all HTML files in the
model_directory's \fIhtml\fP directory.
.TP
\fBlib <libname>\fP
Creates a Makefile for building library out of model source code.
.\" .SS Options
.\".TP
.\"\fB-option\fP
.\"option description.
.SH FILES
.TP
\fI`pwd`/Makefile\fP
This file is created, or replaced if it exists.
.SH "SEE ALSO"
\fBmake\fP(1)
.PP
All Trick model developers and users should go through the tutorial found
in the \fITrick Simulation Environment User Training Materials\fP.
The canonical reference for all Trick commands, files and utilities is the
\fITrick Simulation Environment User's Guide\fP. Information specific to a
given release of Trick tools is contained in the \fITrick Simulation
Environment Version Description\fP for that release.
.\" .SH DIAGNOSTICS
.\" How to determine why the command failed.
.SH BUGS
Known bugs will be placed in the \fIVersion Description Document\fP located in
$TRICK_HOME/docs area. If you would like to report a bug, contact
vetter@lincom-asg.com.
.SH AUTHORS
The \fBmake_build\fP command was originally written by Rob Bailey. It was
extensively modified by Zack Crues and is maintained by the
Trick development staff. This man page was written by Rick Sykes,
address all discrepancies to sykes@lincom-asg.com.

0
share/man/man1/CP.1 → share/man/man1/trick-CP.1
View File

0
share/man/man1/ICG.1 → share/man/man1/trick-ICG.1
View File

0
share/man/man1/kill_sim.1 → share/man/man1/trick-killsim.1
View File