Remove almost all instances of "try and <verb>" from the docs.
There is one remaining place in the fdp-primer, but that needs a bit more work. Inspired by: docs/36462 (Gary W. Swearingen <swear@blarg.net>) Reviewed by: ceri, trhodes
This commit is contained in:
parent
4b70a8662d
commit
67a1702cec
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=12715
13 changed files with 32 additions and 25 deletions
en_US.ISO8859-1
articles
committers-guide
contributing
cvs-freebsd
filtering-bridges
books
developers-handbook/policies
faq
fdp-primer
handbook
basics
contrib
cutting-edge
introduction
policies
|
@ -585,11 +585,11 @@
|
|||
</itemizedlist>
|
||||
|
||||
<para>You will almost certainly get a conflict because
|
||||
of the <literal>$Id: article.sgml,v 1.106 2002-03-27 12:40:02 murray Exp $</literal> (or in FreeBSD's case,
|
||||
of the <literal>$Id: article.sgml,v 1.107 2002-04-07 23:52:25 keramida Exp $</literal> (or in FreeBSD's case,
|
||||
<literal>$<!-- stop expansion -->FreeBSD<!-- stop expansion -->$</literal>) lines, so you will have to edit
|
||||
the file to resolve the conflict (remove the marker lines and
|
||||
the second <literal>$Id: article.sgml,v 1.106 2002-03-27 12:40:02 murray Exp $</literal> line, leaving the original
|
||||
<literal>$Id: article.sgml,v 1.106 2002-03-27 12:40:02 murray Exp $</literal> line intact).</para>
|
||||
the second <literal>$Id: article.sgml,v 1.107 2002-04-07 23:52:25 keramida Exp $</literal> line, leaving the original
|
||||
<literal>$Id: article.sgml,v 1.107 2002-04-07 23:52:25 keramida Exp $</literal> line intact).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
@ -1683,7 +1683,7 @@ docs:Documentation Bug:nik:</programlisting>
|
|||
course) but CVS makes it unnecessary to have an ongoing
|
||||
dispute raging when it is far easier to simply reverse the
|
||||
disputed change, get everyone calmed down again and then
|
||||
try and figure out how best to proceed. If the change
|
||||
try to figure out what is the best way to proceed. If the change
|
||||
turns out to be the best thing after all, it can be easily
|
||||
brought back. If it turns out not to be, then the users
|
||||
did not have to live with the bogus change in the tree
|
||||
|
@ -1740,7 +1740,7 @@ docs:Documentation Bug:nik:</programlisting>
|
|||
to continue to attract new members. There will be
|
||||
occasions when, despite everyone's very best attempts at
|
||||
self-control, tempers are lost and angry words are
|
||||
exchanged, and the best we can do is try and minimize the
|
||||
exchanged. The best thing that can be done in such cases is to minimize the
|
||||
effects of this until everyone has cooled back down. That
|
||||
means that you should not air your angry words in public
|
||||
and you should not forward private correspondence to
|
||||
|
|
|
@ -89,7 +89,7 @@ FreeBSD Entities//EN"> %freebsd;
|
|||
<para>If you run FreeBSD-current and have a good Internet
|
||||
connection, there is a machine <hostid
|
||||
role="fqdn">current.FreeBSD.org</hostid> which builds a full
|
||||
release once a day — every now and again, try and install
|
||||
release once a day—every now and again, try to install
|
||||
the latest release from it and report any failures in the
|
||||
process.</para>
|
||||
</listitem>
|
||||
|
|
|
@ -20,7 +20,7 @@
|
|||
<holder role="mailto:stijn@win.tue.nl">Stijn Hoop</holder>
|
||||
</copyright>
|
||||
|
||||
<pubdate role="rcs">$Date: 2002-04-05 08:16:31 $</pubdate>
|
||||
<pubdate role="rcs">$Date: 2002-04-07 23:52:32 $</pubdate>
|
||||
|
||||
<releaseinfo>$FreeBSD$</releaseinfo>
|
||||
|
||||
|
@ -114,7 +114,7 @@
|
|||
|
||||
<para>Next, we will copy the FreeBSD <filename>CVSROOT</filename>
|
||||
sources into your own repository. If you are accustomed to
|
||||
<application>CVS</application>, it might occur to you to try and
|
||||
<application>CVS</application>, you might be thinking that you can just
|
||||
import the scripts, in an attempt to make synchronizing with later
|
||||
versions easier. However, it turns out that
|
||||
<application>CVS</application> has a deficiency in this area:
|
||||
|
|
|
@ -181,7 +181,7 @@ firewall_logging="YES"</programlisting>
|
|||
will not be activated and the firewall, being in 'open' mode, will not
|
||||
avoid any operations.</para>
|
||||
|
||||
<para>If there are any problems, you should try and sort them out now
|
||||
<para>If there are any problems, you should sort them out now
|
||||
before proceeding.</para>
|
||||
</sect1>
|
||||
|
||||
|
@ -322,7 +322,7 @@ add drop log all from any to any</programlisting>
|
|||
|
||||
<para>That is, drop packets that are coming in from the outside claiming
|
||||
to be from our network. This is something that you would commonly do to
|
||||
be sure that someone does not try and evade the packet filter, by
|
||||
be sure that someone does not try to evade the packet filter, by
|
||||
generating nefarious packets that look like they are from the inside.
|
||||
The problem with that is that there is <emphasis>at least</emphasis> one
|
||||
host on the outside interface that you do not want to ignore: the
|
||||
|
|
|
@ -38,7 +38,7 @@
|
|||
to the maintainer for review before being committed. Only if the
|
||||
maintainer does not respond for an unacceptable period of time, to
|
||||
several emails, will it be acceptable to commit changes without review
|
||||
by the maintainer. However, it is suggested that you try and have the
|
||||
by the maintainer. However, it is suggested that you try to have the
|
||||
changes reviewed by someone else if at all possible.</para>
|
||||
|
||||
<para>It is of course not acceptable to add a person or group as
|
||||
|
|
|
@ -705,8 +705,14 @@
|
|||
|
||||
<listitem>
|
||||
<para>The document's format. We produce the documentation in a
|
||||
number of different output formats to try and make it as
|
||||
flexible as possible. The current formats are;</para>
|
||||
number of different output formats. Each format has its own
|
||||
advantages and disadvantages. Some formats are better suited
|
||||
for online reading, while others are meant to be aesthetically
|
||||
pleasing when printed on paper. Having the documentation
|
||||
available in any of these formats ensures that our readers
|
||||
will be able to read the parts they are interested in, either
|
||||
on their monitor, or on paper after printing the documents.
|
||||
The currently available formats are:</para>
|
||||
|
||||
<informaltable frame="none">
|
||||
<tgroup cols="2">
|
||||
|
@ -970,7 +976,7 @@ File: +DESC (ignored)</screen>
|
|||
<para>Channel <literal>#FreeBSD</literal> on
|
||||
<ulink URL="http://www.efnet.org/index.php">EFNet</ulink>
|
||||
is a FreeBSD forum, but do not go there for tech
|
||||
support or to try and get folks there to help you avoid
|
||||
support or try to get folks there to help you avoid
|
||||
the pain of reading man pages or doing your own research.
|
||||
It is a chat channel, first and foremost, and topics there
|
||||
are just as likely to involve sex, sports or nuclear
|
||||
|
|
|
@ -143,8 +143,8 @@
|
|||
<para>This processing simply confirms that the choice of elements, their
|
||||
ordering, and so on, conforms to that listed in the DTD. It does
|
||||
<emphasis>not</emphasis> check that you have used
|
||||
<emphasis>appropriate</emphasis> markup for the content. If you were
|
||||
to try and mark up all the filenames in your document as function
|
||||
<emphasis>appropriate</emphasis> markup for the content. If you
|
||||
tried to mark up all the filenames in your document as function
|
||||
names, the parser would not flag this as an error (assuming, of
|
||||
course, that your DTD defines elements for filenames and functions,
|
||||
and that they are allowed to appear in the same place).</para>
|
||||
|
@ -694,7 +694,7 @@ nsgmls:example.sgml:6:8:E: end tag for "HEAD" which is not finished</screen>
|
|||
<sect3>
|
||||
<title><filename>catalog</filename> files</title>
|
||||
|
||||
<para>If you use the syntax above and try and process this document
|
||||
<para>If you use the syntax above and process this document
|
||||
using an SGML processor, the processor will need to have some way of
|
||||
turning the FPI into the name of the file on your computer that
|
||||
contains the DTD.</para>
|
||||
|
|
|
@ -319,7 +319,7 @@
|
|||
</orderedlist>
|
||||
|
||||
<para>If there are any problems then whoever is looking at the
|
||||
submission will get back to you to try and work them out.</para>
|
||||
submission will get back to you to work them out.</para>
|
||||
|
||||
<para>If there are no problems your translation will be committed
|
||||
as soon as possible.</para>
|
||||
|
|
|
@ -890,8 +890,9 @@ Swap: 256M Total, 38M Used, 217M Free, 15% Inuse
|
|||
send—some of them have a specific meaning, others are interpreted
|
||||
by the application, and the application's documentation will tell you
|
||||
how that application interprets signals. You can only send a signal to
|
||||
a process that you own. If you try and send a signal to someone else's
|
||||
process it will be ignored. The exception to this is the
|
||||
a process that you own. If you send a signal to someone else's
|
||||
process with &man.kill.1; or &man.kill.2; permission will be denied.
|
||||
The exception to this is the
|
||||
<username>root</username> user, who can send signals to everyone's
|
||||
processes.</para>
|
||||
|
||||
|
@ -983,7 +984,7 @@ Swap: 256M Total, 38M Used, 217M Free, 15% Inuse
|
|||
&prompt.root; <userinput>/bin/kill -s HUP 198</userinput></screen>
|
||||
|
||||
<para>In common most with Unix commands, &man.kill.1; will not print any
|
||||
output if it is successful. If you try and send a signal to a
|
||||
output if it is successful. If you send a signal to a
|
||||
process that you do not own then you will see <errorname>kill:
|
||||
<replaceable>PID</replaceable>: Operation not
|
||||
permitted</errorname>. If you mistype the PID you will either
|
||||
|
|
|
@ -74,7 +74,7 @@
|
|||
<para>If you run FreeBSD-current and have a good Internet
|
||||
connection, there is a machine <hostid
|
||||
role="fqdn">current.FreeBSD.org</hostid> which builds a full
|
||||
release once a day — every now and again, try and install
|
||||
release once a day — every now and again, try to install
|
||||
the latest release from it and report any failures in the
|
||||
process.</para>
|
||||
</listitem>
|
||||
|
|
|
@ -1048,7 +1048,7 @@ Script done, …</screen>
|
|||
|
||||
<screen>&prompt.root; <userinput>make -DNOPROFILE=true installworld</userinput></screen>
|
||||
|
||||
<para>otherwise it would try and install profiled libraries that
|
||||
<para>otherwise it would try to install profiled libraries that
|
||||
had not been built during the <command>make buildworld</command>
|
||||
phase.</para>
|
||||
</note>
|
||||
|
|
|
@ -481,7 +481,7 @@
|
|||
to that point suffering rather severely from almost a year's worth
|
||||
of neglect. As the patchkit swelled ever more uncomfortably with
|
||||
each passing day, we were in unanimous agreement that something
|
||||
had to be done and decided to try and assist Bill by providing
|
||||
had to be done and decided to assist Bill by providing
|
||||
this interim <quote>cleanup</quote> snapshot. Those plans came to
|
||||
a rude halt when Bill Jolitz suddenly decided to withdraw his
|
||||
sanction from the project without any clear indication of what
|
||||
|
|
|
@ -44,7 +44,7 @@
|
|||
to the maintainer for review before being committed. Only if the
|
||||
maintainer does not respond for an unacceptable period of time, to
|
||||
several emails, will it be acceptable to commit changes without review
|
||||
by the maintainer. However, it is suggested that you try and have the
|
||||
by the maintainer. However, it is suggested that you try to have the
|
||||
changes reviewed by someone else if at all possible.</para>
|
||||
|
||||
<para>It is of course not acceptable to add a person or group as
|
||||
|
|
Loading…
Reference in a new issue