summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSteve Dougherty <sdougherty@barracuda.com>2016-05-17 00:26:02 +0200
committerBernhard Voelker <mail@bernhard-voelker.de>2016-05-18 08:05:58 +0200
commit85e8c810a29cca8faea6cbd93169cf7051cd65b5 (patch)
tree3b71512950764e084ec5cbd72cca132da60506a0
parentae424b959c5e9bd23f9f686cb34653bc4cd1270e (diff)
downloadfindutils-85e8c810a29cca8faea6cbd93169cf7051cd65b5.tar.gz
doc: fix spelling of "output"
* doc/find.texi (node Controlling Parallelism): s/ouptut/output/ * xargs/xargs.1: Likewise. * find/util.c (cleanup): While at it, fix the same typo here in a comment, too. Copyright-paperwork-exempt: Yes
-rw-r--r--doc/find.texi2
-rw-r--r--find/util.c2
-rw-r--r--xargs/xargs.12
3 files changed, 3 insertions, 3 deletions
diff --git a/doc/find.texi b/doc/find.texi
index 93c67c3..b3c5d10 100644
--- a/doc/find.texi
+++ b/doc/find.texi
@@ -2589,7 +2589,7 @@ overall latency by overlapping their waiting time.
If you are running commands in parallel, you need to think about how
they should arbitrate access to any resources that they share. For
-example, if more than one of them tries to print to stdout, the ouptut
+example, if more than one of them tries to print to stdout, the output
will be produced in an indeterminate order (and very likely mixed up)
unless the processes collaborate in some way to prevent this. Using
some kind of locking scheme is one way to prevent such problems. In
diff --git a/find/util.c b/find/util.c
index f35924c..0e79571 100644
--- a/find/util.c
+++ b/find/util.c
@@ -575,7 +575,7 @@ cleanup (void)
complete_pending_execdirs ();
}
- /* Close ouptut files and NULL out references to them. */
+ /* Close output files and NULL out references to them. */
sharefile_destroy (state.shared_files);
if (eval_tree)
traverse_tree (eval_tree, undangle_file_pointers);
diff --git a/xargs/xargs.1 b/xargs/xargs.1
index b055529..6837786 100644
--- a/xargs/xargs.1
+++ b/xargs/xargs.1
@@ -242,7 +242,7 @@ another.
.B Please note
that it is up to the called processes to properly manage parallel
access to shared resources. For example, if more than one of them
-tries to print to stdout, the ouptut will be produced in an
+tries to print to stdout, the output will be produced in an
indeterminate order (and very likely mixed up) unless the processes
collaborate in some way to prevent this. Using some kind of locking
scheme is one way to prevent such problems. In general, using a