Rooba
/
mitogen
mirror of https://github.com/mitogen-hq/mitogen.git
1
1
Fork 0
Code Issues Packages Projects Releases Wiki Activity

docs: fix typo

This commit is contained in:
David Wilson 2018-02-12 10:30:29 +05:45
parent 4a6d55ced6
commit 4d9d21c808
2 changed files with 11 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
docs/examples.rst
View File

@ -36,8 +36,8 @@ neatly indented, and the purpose of the snippet seems clear.
2. How will the ``if`` statement behave if there is a problem with the machine,
and, say, the ``/bin/grep`` binary is absent?
3. Ignoring quoting, are there any other syntax problems?
4. If this snippet is pasted snippet from its original script into an
interactive shell, will it behave the same as before?
4. If this snippet is pasted from its original script into an interactive
shell, will it behave the same as before?
5. Can you think offhand of differences in how the arguments to ``sudo
...`` and ``ssh fileserver ...`` are parsed?
6. In which context will the ``*`` glob be expanded, if it is expanded at all?
@ -107,13 +107,13 @@ each stage:
'
Even with Python handling the heavy lifting of quoting each shell layer, and
and even if we fixed the aforementioned minor disk-wiping issue, I am still not
100% confident that I know precisely the argument handling rules for all of
``su``, ``sudo``, ``ssh``, and ``bash``.
even if the aforementioned minor disk-wiping issue was fixed, it is still not
100% clear that argument handling rules for all of ``su``, ``sudo``, ``ssh``,
and ``bash`` are correctly respected.
Finally, if any of the login shells involved may not be set to ``bash``, we
must introduce additional layers of quoting, in order to explicitly invoke
``bash`` at each stage, causing an explosion in quoting:
Finally, if any login shell involved is not ``bash``, we must introduce
additional quoting in order to explicitly invoke ``bash`` at each stage,
causing an explosion in quoting:
.. code-block:: bash

6
docs/howitworks.rst
View File

@ -634,7 +634,7 @@ Before replying to a child's request for a module with dependencies:
determines the :py:mod:`django` module code in the master has :keyword:`import`
statements for :py:mod:`django.utils`, :py:mod:`django.utils.lru_cache`, and
:py:mod:`django.utils.version`,
and that exceution of the module code on the master caused those modules to
and that execution of the module code on the master caused those modules to
appear in the master's :py:data:`sys.modules`, there is high probability
execution of the :py:mod:`django` module code in the child will cause the
same modules to be loaded. Since all those modules exist within the
@ -642,7 +642,7 @@ Before replying to a child's request for a module with dependencies:
it is safe to assume the child will make follow-up requests for those modules
too.
In the example, this replaces 4 round-trips with 1 round-trip.
In the example, 4 round-trips are replaced by 1 round-trip.
For any package module ever requested by a child, the parent keeps a note of
the name of the package for one final optimization:
@ -663,7 +663,7 @@ the name of the package for one final optimization:
:py:mod:`django.dispatch`, and 7 :py:mod:`django.utils` indirect dependencies
for :py:mod:`django.db`.
In the example, this replaces 17 round-trips with 1 round-trip.
In the example, 17 round-trips are replaced by 1 round-trip.
The method used to detect import statements is similar to the standard library
:py:mod:`modulefinder` module: rather than analyze module source code,