Joshua Daniel Franklin update.

This commit is contained in:
Christopher Faylor 2002-07-08 16:30:01 +00:00
parent e47e6f0e30
commit 597f5d3801
1 changed files with 121 additions and 62 deletions

View File

@ -120,8 +120,9 @@ identical to <literal>-w</literal> and <literal>-s</literal> together.
</para>
<para>Caveat: The <literal>-l</literal> option does not work if the
<em>check_case</em> parameter of <em>CYGWIN</em> is set to <em>strict</em>,
since Cygwin is not able to match any Windows short path in this mode.
<emphasis>check_case</emphasis> parameter of <emphasis>CYGWIN</emphasis>
is set to <emphasis>strict</emphasis>, since Cygwin is not able to match
any Windows short path in this mode.
</para>
<para>The <literal>-p</literal> option means that you want to convert
@ -169,16 +170,110 @@ other formats.
</sect2>
<sect2 id="dumper"><title>dumper</title>
<screen>
Usage: dumper [OPTION] FILENAME WIN32PID
Dump core from WIN32PID to FILENAME.core
-d, --verbose be verbose while dumping
-h, --help output help information and exit
-q, --quiet be quiet while dumping (default)
-v, --version output version information and exit
</screen>
<para>The <command>dumper</command> utility can be used to create a
core dump of running Windows process. This core dump can be later loaded
to <command>gdb</command> and analyzed. One common way to use
<command>dumper</command> is to plug it into cygwin's Just-In-Time
debugging facility by adding
<screen>
error_start=x:\path\to\dumper.exe
</screen>
to the <emphasis>CYGWIN</emphasis> environment variable. Please note that
<literal>x:\path\to\dumper.exe</literal> is Windows-style and not cygwin
path. If <literal>error_start</literal> is set this way, then dumper will
be started whenever some program encounters a fatal error.
</para>
<para>
<command>dumper</command> can be also be started from the command line to
create a core dump of any running process. Unfortunately, because of a Windows
API limitation, when a core dump is created and <command>dumper</command>
exits, the target process is terminated too.
</para>
<para>
To save space in the core dump, <command>dumper</command> doesn't write those
portions of target process' memory space that are loaded from executable and
dll files and are unchangeable, such as program code and debug info. Instead,
<command>dumper</command> saves paths to files which contain that data. When a
core dump is loaded into gdb, it uses these paths to load appropriate files.
That means that if you create a core dump on one machine and try to debug it on
another, you'll need to place identical copies of the executable and dlls in
the same directories as on the machine where the core dump was created.
</para>
</sect2>
<sect2 id="getfacl"><title>getfacl</title>
<screen>
Usage: getfacl [-adn] FILE [FILE2...]
Display file and directory access control lists (ACLs).
-a, --all display the filename, the owner, the group, and
the ACL of the file
-d, --dir display the filename, the owner, the group, and
the default ACL of the directory, if it exists
-h, --help output usage information and exit
-n, --noname display user and group IDs instead of names
-v, --version output version information and exit
When multiple files are specified on the command line, a blank
line separates the ACLs for each file.
</screen>
<para>
For each argument that is a regular file, special file or
directory, <command>getfacl</command> displays the owner, the group, and the
ACL. For directories <command>getfacl</command> displays additionally the
default ACL. With no options specified, <command>getfacl</command> displays
the filename, the owner, the group, and both the ACL and the default ACL, if
it exists. For more information on Cygwin and Windows ACLs, see
see <Xref Linkend="ntsec"> in the Cygwin User's Guide.
The format for ACL output is as follows:
<screen>
# file: filename
# owner: name or uid
# group: name or uid
user::perm
user:name or uid:perm
group::perm
group:name or gid:perm
mask:perm
other:perm
default:user::perm
default:user:name or uid:perm
default:group::perm
default:group:name or gid:perm
default:mask:perm
default:other:perm
</screen>
</sect2>
<sect2 id="kill"><title>kill</title>
<screen>
Usage: kill [-f] [-signal] [-s signal] pid1 [pid2 ...]
kill -l [signal]
-f, --force force, using win32 interface if necessary
-l, --list print a list of signal names
-s, --signal send signal (use kill --list for a list)
-h, --help output usage information and exit
-v, --version output version information and exit
kill -l [signal]
-f, --force force, using win32 interface if necessary
-l, --list print a list of signal names
-s, --signal send signal (use kill --list for a list)
-h, --help output usage information and exit
-v, --version output version information and exit
</screen>
<para>The <command>kill</command> program allows you to send arbitrary
@ -188,17 +283,30 @@ also send program-specified signals such as SIGUSR1 to trigger actions
within the program, like enabling debugging or re-opening log files.
Each program defines the signals they understand.</para>
<para>Note that, unless you specific the <literal>-f</literal> option,
the "pid" values are the Cygwin pids, not the Windows pids. To get a
list of running programs and their Cygwin pids, use the Cygwin
<para>You may need to specify the full path to use <command>kill</command>
from within some shells, including <command>bash</command>, the default Cygwin
shell. This is because <command>bash</command> defines a
<command>kill</command> builtin function; see the <command>bash</command>
man page under <emphasis>BUILTIN COMMANDS</emphasis> for more information.
To make sure you are using the Cygwin version, try
<screen>
$ /bin/kill --version
</screen>
which should give the Cygwin <command>kill</command> version number and
copyright information.
</para>
<para>Unless you specific the <literal>-f</literal> option, the "pid" values
used by <command>kill</command> are the Cygwin pids, not the Windows pids.
To get a list of running programs and their Cygwin pids, use the Cygwin
<command>ps</command> program. <command>ps -W</command> will display
<emphasis>all</emphasis> windows pids.</para>
<para>The <command>kill -l</command> option prints the name of the
given signal, or a list of all signal names if no signal is given.</para>
<para><command>kill -h</command> just displays the kill usage message.</para>
<para>To send a specific signal, use the <literal>-signN</literal>
option, either with a signal number or a signal name (minus the "SIG"
part), like these examples:</para>
@ -238,10 +346,8 @@ SIGSTOP 17 sendable stop signal not from tty
SIGTSTP 18 stop signal from tty
SIGCONT 19 continue a stopped process
SIGCHLD 20 to parent on child stop or exit
SIGCLD 20 System V name for SIGCHLD
SIGTTIN 21 to readers pgrp upon background tty read
SIGTTOU 22 like TTIN for output if (tp-&gt;t_local&amp;LTOSTOP)
SIGIO 23 input/output possible signal
SIGPOLL 23 System V name for SIGIO
SIGXCPU 24 exceeded CPU time limit
SIGXFSZ 25 exceeded file size limit
@ -815,51 +921,4 @@ print the message but does return the non-zero exit code.</para>
</sect2>
<sect2 id="dumper"><title>dumper</title>
<screen>
Usage: dumper [OPTION] FILENAME WIN32PID
Dump core from WIN32PID to FILENAME.core
-d, --verbose be verbose while dumping
-h, --help output help information and exit
-q, --quiet be quiet while dumping (default)
-v, --version output version information and exit
</screen>
<para>The <command>dumper</command> utility can be used to create
core dump of running windows process. This core dump can be later loaded
to gdb an analyzed. One common way to use <command>dumper</command> is to
plug it into cygwin's Just-In-Time debugging facility by adding
<screen>
error_start=x:\path\to\dumper.exe
</screen>
to <em>CYGWIN</em> environment variable. Please note that
<literal>x:\path\to\dumper.exe</literal> is win32-style and not cygwin
path. If <literal>error_start</literal> is set this way, then dumper will
be started whenever some program encounters fatal error.
</para>
<para>
<command>dumper</command> can be also be started from command line to create
core dump of any running process. Unfortunately, because of windows API
limitation, when core dump is created and <command>dumper</command> exits,
the target process is terminated too.
</para>
<para>
To save the space in core dump, <command>dumper</command> doesn't write those
portions of target process' memory space that are loaded from executable and
dll files and are unchangeable, such as program code and debug info. Instead,
<command>dumper</command> saves paths to files which contain that data. When
core dump is loaded into gdb, it uses these paths to load appropriate files.
That means that if you create core dump on one machine and try to debug it on
other, you'll need to place identical copies of executable and dlls in the same
directories as on machine where core dump has been created.
</para>
</sect2>
</sect1>