aboutsummaryrefslogtreecommitdiff
path: root/system/ts
diff options
context:
space:
mode:
authorB. Watson <yalhcru@gmail.com>2022-03-14 12:58:00 -0400
committerB. Watson <yalhcru@gmail.com>2022-03-17 12:38:13 -0400
commite0d3fcc39d1f631dcd6fe158d9d7a9f4f34ab1d0 (patch)
tree172f40e807b3a6c4a7d79a64e071be15529eaa22 /system/ts
parente859ab1cbbfc8c67d710e6fe8c584f57462975c8 (diff)
system/ts: Wrap README at 72 columns.
Signed-off-by: B. Watson <yalhcru@gmail.com>
Diffstat (limited to 'system/ts')
-rw-r--r--system/ts/README55
1 files changed, 27 insertions, 28 deletions
diff --git a/system/ts/README b/system/ts/README
index 6028123804c3..7aa9218d9670 100644
--- a/system/ts/README
+++ b/system/ts/README
@@ -1,37 +1,36 @@
-Task spooler is a Unix batch system where the tasks spooled run one after
-the other. The amount of jobs to run at once can be set at any time. Each
-user in each system has his own job queue. The tasks are run in the correct
-context (that of enqueue) from any shell/process, and its output/results
-can be easily watched. It is very useful when you know that your commands
-depend on a lot of RAM, a lot of disk use, give a lot of output, or for
-whatever reason it's better not to run them all at the same time, while you
-want to keep your resources busy for maximum benfit. Its interface allows
-using it easily in scripts.
+Task spooler is a Unix batch system where the tasks spooled run one
+after the other. The amount of jobs to run at once can be set at any
+time. Each user in each system has his own job queue. The tasks are
+run in the correct context (that of enqueue) from any shell/process,
+and its output/results can be easily watched. It is very useful when
+you know that your commands depend on a lot of RAM, a lot of disk use,
+give a lot of output, or for whatever reason it's better not to run
+them all at the same time, while you want to keep your resources busy
+for maximum benfit. Its interface allows using it easily in scripts.
Features
Task Spooler allows one to:
- * Queue jobs from different terminals.
- * Use it locally in the machine (not as in network queues).
- * Have a good way of seeing the output of the processes (tail,
- errorlevels, ...).
- * Easy use: almost no configuration.
- * Easy to use in scripts.
+* Queue jobs from different terminals.
+* Use it locally in the machine (not as in network queues).
+* Have a good way of seeing the output of the processes (tail,
+ errorlevels, ...).
+* Easy use: almost no configuration.
+* Easy to use in scripts.
At the end, after some time using and developing ts, it can do something
more:
- * It works in GNU systems with the GNU c compiler (Linux, Darwin,
- Cygwin, FreeBSD, etc).
- * No configuration at all for a simple queue.
- * Good integration with renice, kill, etc. (through `ts -p` and process
- groups).
- * Have any amount of queues identified by name, writting a simple
- wrapper script for each (I use ts2, tsio, tsprint, etc).
- * Control how many jobs may run at once in any queue (taking profit of
- multicores).
- * It never removes the result files, so they can be reached even after
- we've lost the ts task list.
- * Transparent if used as a subprogram with -nf.
-
+* It works on GNU systems with the GNU C compiler (Linux, Darwin,
+ Cygwin, FreeBSD, etc).
+* No configuration at all for a simple queue.
+* Good integration with renice, kill, etc. (through `ts -p` and process
+ groups).
+* Have any amount of queues identified by name, writting a simple
+ wrapper script for each (I use ts2, tsio, tsprint, etc).
+* Control how many jobs may run at once in any queue (taking profit of
+ multicores).
+* It never removes the result files, so they can be reached even after
+ we've lost the ts task list.
+* Transparent if used as a subprogram with -nf.