neulab/tldr huggingface dataset:
-L max-lines Use at most max-lines nonblank input lines per command line. Trailing blanks cause an input line to be logically continued on the next input line.  Implies -x.
-l[max-lines], --max-lines[=max-lines] Synonym for the -L option.  Unlike -L, the max-lines argument is optional.  If max-lines is not specified, it defaults to one.  The -l option is deprecated since the POSIX standard specifies -L instead.
-n max-args, --max-args=max-args Use at most max-args arguments per command line.  Fewer than max- args arguments will be used if the size (see the -s option) is exceeded, unless the -x option is given, in which case xargs will exit.
-P max-procs, --max-procs=max-procs Run up to max-procs processes at a time; the default is 1.  If max-procs is 0, xargs will run as many processes as possible at a time.  Use the -n option or the -L option with -P; otherwise chances are that only one exec will be done.  While xargs is running, you can send its process a SIGUSR1 signal to increase the number of commands to run simultaneously, or a SIGUSR2 to decrease the number.  You cannot increase it above an implementation- defined limit (which is shown with --show-limits).  You cannot decrease it below 1.  xargs never terminates its commands; when asked to decrease, it merely waits for more than one existing command to terminate before starting another.
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 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 locking scheme will help ensure correct output but reduce performance.  If you don't want to tolerate the performance difference, simply arrange for each process to produce a separate output file (or otherwise use separate resources).
-o, --open-tty Reopen stdin as /dev/tty in the child process before executing the command.  This is useful if you want xargs to run an interactive application.
-p, --interactive Prompt the user about whether to run each command line and read a line from the terminal.  Only run the command line if the response starts with `y' or `Y'.  Implies -t.
--process-slot-var=name Set the environment variable name to a unique value in each running child process.  Values are reused once child processes exit.  This can be used in a rudimentary load distribution scheme, for example.
-r, --no-run-if-empty If the standard input does not contain any nonblanks, do not run the command.  Normally, the command is run once even if there is no input.  This option is a GNU extension.
-s max-chars, --max-chars=max-chars Use at most max-chars characters per command line, including the command and initial-arguments and the terminating nulls at the ends of the argument strings.  The largest allowed value is system-dependent, and is calculated as the argument length limit for exec, less the size of your environment, less 2048 bytes of headroom.  If this value is more than 128KiB, 128Kib is used as the default value; otherwise, the default value is the maximum. 1KiB is 1024 bytes.  xargs automatically adapts to tighter constraints.
--show-limits Display the limits on the command-line length which are imposed by the operating system, xargs' choice of buffer size and the -s option.  Pipe the input from /dev/null (and perhaps specify --no- run-if-empty) if you don't want xargs to do anything.
-t, --verbose Print the command line on the standard error output before executing it.
-x, --exit Exit if the size (see the -s option) is exceeded.
--help Print a summary of the options to xargs and exit.
--version Print the version number of xargs and exit.
The options --max-lines (-L, -l), --replace (-I, -i) and --max-args (-n) are mutually exclusive. If some of them are specified at the same time, then xargs will generally use the option specified last on the command line, i.e., it will reset the value of the offending option (given before) to its default value.  Additionally, xargs will issue a warning diagnostic on stderr.  The exception to this rule is that the special max-args value 1 ('-n1') is ignored after the --replace option and its aliases -I and -i, because it would not actually conflict.
find /tmp -name core -type f -print | xargs /bin/rm -f
Find files named core in or below the directory /tmp and delete them. Note that this will work incorrectly if there are any filenames containing newlines or spaces.
find /tmp -name core -type f -print0 | xargs -0 /bin/rm -f
Find files named core in or below the directory /tmp and delete them, processing filenames in such a way that file or directory names containing spaces or newlines are correctly handled.
find /tmp -depth -name core -type f -delete
Find files named core in or below the directory /tmp and delete them, but more efficiently than in the previous example (because we avoid the need to use fork(2) and exec(2) to launch rm and we don't need the extra xargs process).
cut -d: -f1 < /etc/passwd | sort | xargs echo
Generates a compact listing of all the users on the system.
xargs exits with the following status:
0      if it succeeds
123    if any invocation of the command exited with status 1-125
124    if the command exited with status 255
125    if the command is killed by a signal
126    if the command cannot be run
127    if the command is not found
1      if some other error occurred.
Exit codes greater than 128 are used by the shell to indicate that a program died due to a fatal signal.
As of GNU xargs version 4.2.9, the default behaviour of xargs is not to have a logical end-of-file marker.  POSIX (IEEE Std 1003.1, 2004 Edition) allows this.
The -l and -i options appear in the 1997 version of the POSIX standard, but do not appear in the 2004 version of the standard.  Therefore you should use -L and -I instead, respectively.
The -o option is an extension to the POSIX standard for better compatibility with BSD.
The POSIX standard allows implementations to have a limit on the size of arguments to the exec functions.  This limit could be as low as 4096 bytes including the size of the environment.  For scripts to be portable, they must not rely on a larger value.  However, I know of no implementation whose actual limit is that small.  The --show-limits option can be used to discover the actual limits in force on the current system.
It is not possible for xargs to be used securely, since there will always be a time gap between the production of the list of input files and their use in the commands that xargs issues.  If other users have access to the system, they can manipulate the filesystem during this time window to force the action of the commands xargs runs to apply to files that you didn't intend.  For a more detailed discussion of this and related problems, please refer to the ``Security Considerations'' chapter in the findutils Texinfo documentation.  The -execdir option of find can often be used as a more secure alternative.
When you use the -I option, each line read from the input is buffered internally.   This means that there is an upper limit on the length of input line that xargs will accept when used with the -I option.  To work around this limitation, you can use the -s option to increase the amount of buffer space that xargs uses, and you can also use an extra invocation of xargs to ensure that very long lines do not occur.  For example:
somecommand | xargs -s 50000 echo | xargs -I '{}' -s 100000 rm '{}'
Here, the first invocation of xargs has no input line length limit because it doesn't use the -i option.  The second invocation of xargs does have such a limit, but we have ensured that it never encounters a line which is longer than it can handle.   This is not an ideal solution. Instead, the -i option should not impose a line length limit, which is why this discussion appears in the BUGS section.  The problem doesn't occur with the output of find(1) because it emits just one filename per line.
GNU findutils online help: <https://www.gnu.org/software/findutils/#get- help> Report any translation bugs to <https://translationproject.org/team/>
Report any other issue via the form at the GNU Savannah bug tracker: <https://savannah.gnu.org/bugs/?group=findutils> General topics about the GNU findutils package are discussed at the bug-findutils mailing list: <https://lists.gnu.org/mailman/listinfo/bug-findutils>
Copyright Â© 1990-2021 Free Software Foundation, Inc.  License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>. This is free software: you are free to change and redistribute it.  There is NO WARRANTY, to the extent permitted by law.
find(1), kill(1), locate(1), updatedb(1), fork(2), execvp(3), locatedb(5), signal(7)
Full documentation <https://www.gnu.org/software/findutils/xargs> or available locally via: info xargs
CSVGREP(1)                           csvkit                           CSVGREP(1)
csvgrep - csvgrep Documentation
Filter tabular data to only those rows where certain columns contain a given value or match a regular expression:
usage: csvgrep [-h] [-d DELIMITER] [-t] [-q QUOTECHAR] [-u {0,1,2,3}] [-b] [-p ESCAPECHAR] [-z FIELD_SIZE_LIMIT] [-e ENCODING] [-S] [-H] [-K SKIP_LINES] [-v] [-l] [--zero] [-V] [-n] [-c COLUMNS] [-m PATTERN] [-r REGEX] [-f MATCHFILE] [-i] [FILE]
Search CSV files. Like the Unix "grep" command, but for tabular data.
optional arguments: -h, --help            show this help message and exit -n, --names           Display column names and indices from the input CSV and exit. -c COLUMNS, --columns COLUMNS A comma separated list of column indices, names or ranges to be searched, e.g. "1,id,3-5". -m PATTERN, --match PATTERN The string to search for. -r REGEX, --regex REGEX If specified, must be followed by a regular expression which will be tested against the specified columns. -f MATCHFILE, --file MATCHFILE If specified, must be the path to a file. For each tested row, if any line in the file (stripped of line separators) is an exact match for the cell value, the row will pass. -i, --invert-match    If specified, select non-matching instead of matching rows. -a  --any-match       If specified, select rows where any column matches instead of all columns.
NOTE: Even though ‘-m’, ‘-r’, and ‘-f’ are listed as “optional” arguments, you must specify one of them.
Search for the row relating to Illinois:
csvgrep -c 1 -m ILLINOIS examples/realdata/FY09_EDU_Recipients_by_State.csv
Search for rows relating to states with names beginning with the letter “I”:
csvgrep -c 1 -r "^I" examples/realdata/FY09_EDU_Recipients_by_State.csv
Search for rows that do not contain an empty state cell:
csvgrep -c 1 -r "^$" -i examples/realdata/FY09_EDU_Recipients_by_State.csv
Perform a case-insensitive search:
csvgrep -c 1 -r "(?i)illinois" examples/realdata/FY09_EDU_Recipients_by_State.csv
task(1)                           User Manuals                           task(1)
task - A command line todo manager.
task <filter> <command> [ <mods> | <args> ] task --version
Taskwarrior is a command line todo list manager. It maintains a list of tasks that you want to do, allowing you to add/remove, and otherwise manipulate them.  Taskwarrior has a rich set of subcommands that allow you to do various things with it.
At the core, Taskwarrior is a list processing program. You add text and additional related parameters and redisplay the information in a nice way.  It turns into a todo list program when you add due dates and recurrence. It turns into an organized todo list program when you add priorities, tags (one word descriptors), project groups, etc.
The <filter> consists of zero or more search criteria that select tasks. For example, to list all pending tasks belonging to the 'Home' project:
task project:Home list
You can specify multiple filter terms, each of which further restricts the result:
task project:Home +weekend garden list
This example applies three filters: the 'Home' project, the 'weekend' tag, and the description or annotations must contain the character sequence 'garden'.  In this example, 'garden' is translated internally to:
description.contains:garden
as a convenient shortcut.  The 'contains' here is an attribute modifier, which is used to exert more control over the filter than simply absence or presence.  See the section 'ATTRIBUTE MODIFIERS' below for a complete list of modifiers.
Note that a filter may have zero terms, which means that all tasks apply to the command.  This can be dangerous, and this special case is confirmed, and cannot be overridden.  For example, this command:
task modify +work This command has no filter, and will modify all tasks.  Are you sure? (yes/no)
will add the 'work' tag to all tasks, but only after confirmation.
More filter examples:
task                                      <command> <mods> task 28                                   <command> <mods> task +weekend                             <command> <mods> task +bills due.by:eom                    <command> <mods> task project:Home due.before:today        <command> <mods> task ebeeab00-ccf8-464b-8b58-f7f2d606edfb <command> <mods>
By default filter elements are combined with an implicit 'and' operator, but 'or' and 'xor' may also be used, provided parentheses are included:
task '( /[Cc]at|[Dd]og/ or /[0-9]+/ )'      <command> <mods>
The parentheses isolate the logical term from any default command filter or implicit report filter which would be combined with an implicit 'and'.
A filter may target specific tasks using ID or UUID numbers.  To specify multiple tasks use one of these forms (space-separated list of ID numbers, UUID numbers or ID ranges):
task 1 2 3                                    delete task 1-3                                      info task 1 2-5 19                                 modify pri:H task 4-7 ebeeab00-ccf8-464b-8b58-f7f2d606edfb info
Note that it may be necessary to properly escape special characters as well as quotes in order to avoid their special meanings in the shell. See also the section 'SPECIFYING DESCRIPTIONS' for more information.
The <mods> consist of zero or more changes to apply to the selected tasks, such as:
task <filter> <command> project:Home task <filter> <command> +weekend +garden due:tomorrow task <filter> <command> Description/annotation text task <filter> <command> /from/to/     <- replace first match task <filter> <command> /from/to/g    <- replace all matches
Taskwarrior supports different kinds of commands.  There are read commands, write commands, miscellaneous commands and script helper commands.  Read commands do not allow modification of tasks.  Write commands can alter almost any aspect of a task.  Script helper commands are provided to help you write add-on scripts, for example, shell completion (only minimal output is generated, as with verbose=nothing). Those commands which are explicitly affected by the context are denoted as such.
Reports are read subcommands. There are several reports currently predefined in Taskwarrior. The output and sort behavior of these reports can be configured in the configuration file. See also the man page taskrc(5).  There are also other read subcommands that are not reports.
task --version This is the only conventional command line argument that Taskwarrior supports, and is intended for add-on scripts to verify the version number of an installed Taskwarrior without invoking the mechanisms that create default files.
task <filter> With no command specified, the default command is run, and the filter applied.
task <filter> active Shows all tasks matching the filter that are started but not completed.
task <filter> all Shows all tasks matching the filter, including parents of recurring tasks.
task <filter> blocked Shows all tasks matching the filter, that are currently blocked by other tasks.
task <filter> blocking Shows all tasks matching the filter, that block other tasks.
task <filter> burndown.daily Shows a graphical burndown chart, by day. Is affected by the context.
task <filter> burndown.weekly Shows a graphical burndown chart, by week.  Note that 'burndown' is an alias to the 'burndown.weekly' report. Is affected by the context.
task <filter> burndown.monthly Shows a graphical burndown chart, by month. Is affected by the context.
task calendar [due|<month> <year>|<year>] [y] Shows a monthly calendar with due tasks marked.  Shows one horizontal line of months.  If the 'y' argument is provided, will show at least one complete year.  If a year is provided, such as '2015', then that full year is shown.  If both a month and a year are specified ('6 2015') then the months displayed begin at the specified month and year.  If the 'due' argument is provided, will show the starting month of the earliest due task.
task colors [<sample> | legend] Displays all possible colors, a named sample, or a legend containing all currently defined colors.
task columns [<substring>] Displays all supported columns and formatting styles.  Useful when creating custom reports.  If a substring is provided, only matching column names are shown.
task commands Shows all the supported commands, with some details of each.
task <filter> completed Shows all tasks matching the filter that are completed.
task <filter> count Displays only a count of tasks matching the filter. Is affected by the context.
task <filter> export Exports all tasks in the JSON format.  Redirect the output to a file, if you wish to save it, or pipe it to another command or script to convert it to another format. You'll find these example scripts online at <https://taskwarrior.org/tools/>:
export-csv.pl export-sql.py export-xml.py export-yaml.pl export-html.pl export-tsv.pl export-xml.rb export-ical.pl export-xml.pl export-yad.pl
task <filter> ghistory.annual Shows a graphical report of task status by year.
task <filter> ghistory.monthly Shows a graphical report of task status by month.  Note that 'ghistory' is an alias to 'ghistory.monthly'.
task <filter> ghistory.weekly Shows a graphical report of task status by week.
task <filter> ghistory.daily Shows a graphical report of task status by day.
task help Shows the long usage text.
task <filter> history.annual Shows a report of task history by year. Is affected by the context.
task <filter> history.monthly Shows a report of task history by month.  Note that 'history' is an alias to 'history.monthly'. Is affected by the context.
task <filter> history.weekly Shows a report of task history by week. Is affected by the context.
task <filter> history.daily Shows a report of task history by day. Is affected by the context.
task <filter> ids Applies the filter then extracts only the task IDs and presents them as a space-separated list.  This is useful as input to a task command, to achieve this:
task $(task project:Home ids) modify priority:H
This example first gets the IDs for the project:Home filter, then sets the priority to H for each of those tasks.  This can also be achieved directly:
task project:Home modify priority:H
This command is mainly of use to external scripts.
task <filter> uuids Applies the filter on all tasks (even deleted and completed tasks) then extracts only the task UUIDs and presents them as a space- separated list.  This is useful as input to a task command, to achieve this:
task $(task project:Home status:completed uuids) modify status:pending
This example first gets the UUIDs for the project:Home and status:completed filters, then makes each of those tasks pending again.
task udas Shows a list of UDAs that are defined, including their name, type, label and allowed values.  Also shows UDA usage and any orphan UDAs.
task <filter> information Shows all data and metadata for the specified tasks.  This is the only means of displaying all aspects of a given task, including the change history.
task <filter> list Provides a standard listing of tasks matching the filter.
task <filter> long Provides the most detailed listing of tasks matching the filter.
task <filter> ls Provides a short listing of tasks matching the filter.
task <filter> minimal Provides a minimal listing of tasks matching the filter.
task <filter> newest Shows the newest tasks matching the filter.
task <filter> next Shows a page of the most urgent tasks, sorted by urgency, which is a calculated value.
task <filter> ready Shows a page of the most urgent ready tasks, sorted by urgency with started tasks first. A ready task is one that is either unscheduled, or has a scheduled date that is past and is not waiting.
task <filter> oldest Shows the oldest tasks matching the filter.
task <filter> overdue Shows all incomplete tasks matching the filter that are beyond their due date.
task <filter> projects Lists all project names that are currently used by pending tasks, and the number of tasks for each. Is affected by the context.
task <filter> recurring Shows all recurring tasks matching the filter.
task <filter> unblocked Shows all tasks that are not currently blocked by other tasks, matching the filter.
task <filter> waiting Shows all waiting tasks matching the filter.
task add <mods> Adds a new pending task to the task list. It is affected by the currently set context.
task <filter> annotate <mods> Adds an annotation to an existing task.
task <filter> append <mods> Appends description text to an existing task.
task <filter> delete <mods> Deletes the specified task from task list. Is affected by the context.
task <filter> denotate <mods> Deletes an annotation for the specified task. If the provided description matches an annotation exactly, the corresponding annotation is deleted. If the provided description matches annotations partly, the first partly matched annotation is deleted. Is affected by the context.
task <filter> done <mods> Marks the specified task as done. Is affected by the context.
task <filter> duplicate <mods> Duplicates the specified task and allows modifications. Is affected by the context.
task <filter> edit Launches a text editor to let you modify all aspects of a task directly.  In general, this is not the recommended method of modifying tasks, but is provided for exceptional circumstances. Use carefully. Is affected by the context.
task import [<file> ...] Imports tasks in the JSON format.  Can be used to add new tasks, or update existing ones.  Tasks are identified by their UUID.
If no file or "-" is specified, import tasks from STDIN.
Setting rc.recurrence.confirmation to an appropriate level is recommended if import is to be used in automated workflows.  See taskrc(5).
For importing other file formats, the standard task release comes with a few example scripts, such as:
import-todo.sh.pl import-yaml.pl
task log <mods> Adds a new task that is already completed, to the task list. It is affected by the currently set context.
task <filter> modify <mods> Modifies the existing task with provided information.
task <filter> prepend <mods> Prepends description text to an existing task. Is affected by the context.
task <filter> purge Permanently removes the specified tasks from the data files. Only tasks that are already deleted can be purged. This command has a local-only effect and changes introduced by it are not synced.  Is affected by the context.
Warning: causes permanent, non-revertible loss of data.
task <filter> start <mods> Marks the specified tasks as started. Is affected by the context.
task <filter> stop <mods> Removes the start time from the specified task. Is affected by the context.
Miscellaneous subcommands either accept no command line arguments, or accept non-standard arguments.
task calc <expression> Evaluates an algebraic expression. Can be used to test how Taskwarrior parses and evaluates the expression given on the command line.
task calc 1 + 1 2
task calc now + 8d 2015-03-26T18:06:57
task calc eom 2015-03-31T23:59:59
task config [<name> [<value> | '']] Add, modify and remove settings directly in the Taskwarrior configuration.  This command either modifies the 'name' setting with a new value of 'value', or adds a new entry that is equivalent to 'name=value':
task config name value
This command sets a blank value.  This has the effect of suppressing any default value:
task config name ''
Finally, this command removes any 'name=...' entry from the .taskrc file:
task config name
task context <name> Sets the currently active context. See the CONTEXT section.
task context work
task context delete <name> Deletes the context with the name <name>. If the context being deleted is currently set as active, it will be unset.
task context delete work
task context define <name> <filter> Defines a new context with name <name> and definition <filter>. This command does not affect the currently set context, just adds a new context definition.
task context define work project:Work task context define home project:Home or +home task context define superurgent due:today and +urgent
task context list Outputs a list of available contexts along with their definitions.
task context none Clears the currently active context, if any was set.
task context show Shows the currently active context, along with its definition.
task diagnostics Shows diagnostic information, of the kind needed when reporting a problem.  When you report a bug, it is likely that the platform, version, and environment are important.  Running this command generates a summary of similar information that should accompany a bug report.
It includes compiler, library and software information.  It does not include any personal information, other than the location and size of your task data files.
This command also performs a diagnostic scan of your data files looking for common problems, such as duplicate UUIDs.
task execute <external command> Executes the specified command.  Not useful by itself, but when used in conjunction with aliases and extensions can provide seamless integration.
task logo Displays the Taskwarrior logo.
task news Guides the user through important release notes anytime a new version of Taskwarrior is installed. It provides personalized feedback, deprecation warnings and usage advice, where applicable.
task reports Lists all supported reports.  This includes the built-in reports, and any custom reports you have defined.
task show [all | <substring>] Shows all the current settings.  If a substring is specified just the settings containing that substring will be displayed.
task <filter> stats Shows statistics of the tasks defined by the filter. Is affected by the context.
task <filter> summary Shows a report of aggregated task status by project. Is affected by the context.
task sync [init] The sync command synchronizes data with the Taskserver, if configured.
The init subcommand should only ever be run once, and only on one client, because it sends all data to the Taskserver. This allows all the subsequent sync commands to only send small deltas.
Note: If you use multiple sync clients, make sure this setting (which is the default) is on your primary client:
recurrence=on
and on all other clients (this is not the default):
recurrence=off
This is a workaround to avoid a recurrence bug that duplicates recurring tasks.
task <filter> tags Show a list of all tags used. Any special tags used are highlighted. Note that virtual tags are not listed - they don't really exist, and are just a convenient notation for other task metadata. It is an error to attempt to add or remove a virtual tag. Is affected by the context.
task timesheet [<weeks>] Shows a weekly report of tasks completed and started.
task undo Reverts the most recent action.  Obeys the confirmation setting.
task version Shows the Taskwarrior version number.
task _aliases Generates a list of all aliases, for autocompletion purposes.
task _columns Displays only a list of supported columns.
task _commands Generates a list of all commands, for autocompletion purposes.
task _config Lists all supported configuration variables, for completion purposes.
task _context Lists all available context variables, for completion purposes.
task <filter> _ids Shows only the IDs of matching tasks, in the form of a list. Deprecated in favor of _unique.
task _show Shows the combined defaults and overrides of the configuration settings, for use by third-party applications.
task <filter> _unique <attribute> Reports a unique set of attribute values. For example, to see all the active projects:
task +PENDING _unique project
task <filter> _uuids Shows only the UUIDs of matching tasks among all tasks (even deleted and completed tasks), in the form of a list.  Deprecated in favor of _unique.
task _udas Shows only defined UDA names, in the form of a list.
task <filter> _projects Shows only a list of all project names used.  Deprecated in favor of _unique.
task <filter> _tags Shows only a list of all tags used, for autocompletion purposes. Deprecated in favor of _unique.
task <filter> _urgency Displays the urgency measure of a task.
task _version Shows only the Taskwarrior version number.
task _zshcommands Generates a list of all commands, for zsh autocompletion purposes.
task <filter> _zshids Shows the IDs and descriptions of matching tasks.
task <filter> _zshuuids Shows the UUIDs and descriptions of matching tasks.
task _get <DOM> [<DOM> ...] Accesses and displays the DOM reference(s).  Used to extract individual values from tasks, or the system.  Supported DOM references are:
rc.<name> tw.syncneeded tw.program tw.args tw.width tw.height tw.version context.program    (Deprecated in 2.6.0) context.args       (Deprecated in 2.6.0) context.width      (Deprecated in 2.6.0) context.height     (Deprecated in 2.6.0) system.version system.os <id>.<attribute> <uuid>.<attribute>
Note that the 'rc.<name>' reference may need to be escaped using '--' to prevent the reference from being interpreted as an override.
Note that if the DOM reference is not valid, or the reference evaluates to a missing value, the command exits with 1.
Additionally, some components of the attributes of particular types may be extracted by DOM references.
$ task _get 2.due.year 2015
For a full list of supported attribute-specific DOM references, consult the online documentation at: <https://taskwarrior.org/docs/dom.html>
ID     Tasks can be specified uniquely by IDs, which are simply the indexes of the tasks in the data file.  The ID of a task may therefore change, but only when a command is run that displays IDs.  When modifying tasks, it is safe to rely on the last displayed ID.  Always run a report to check you have the right ID for a task. IDs can be given to task as a sequence, for example, task 1,4-10,19 delete
+tag|-tag Tags are arbitrary words associated with a task. Use + to add a tag and - to remove a tag from a task. A task can have any quantity of tags.
Certain tags (called 'special tags'), can be used to affect the way tasks are treated.  For example, if a task has the special tag 'nocolor', then it is exempt from all color rules.  The supported special tags are:
+nocolor     Disable color rules processing for this task +nonag       Completion of this task suppresses all nag messages +nocal       This task will not appear on the calendar +next        Elevates task so it appears on 'next' report
There are also virtual tags, which represent task metadata in tag form.  These tags do not exist, but can be used to filter tasks. The supported virtual tags are:
ACTIVE       Matches if the task is started ANNOTATED    Matches if the task has annotations BLOCKED      Matches if the task is blocked BLOCKING     Matches if the task is blocking CHILD        Matches if the task has a parent (deprecated in 2.6.0) COMPLETED    Matches if the task has completed status DELETED      Matches if the task has deleted status DUE          Matches if the task is due INSTANCE     Matches if the task is a recurrent instance LATEST       Matches if the task is the newest added task MONTH        Matches if the task is due this month ORPHAN       Matches if the task has any orphaned UDA values OVERDUE      Matches if the task is overdue PARENT       Matches if the task is a parent (deprecated in 2.6.0) PENDING      Matches if the task has pending status PRIORITY     Matches if the task has a priority PROJECT      Matches if the task has a project QUARTER      Matches if the task is due this quarter READY        Matches if the task is actionable SCHEDULED    Matches if the task is scheduled TAGGED       Matches if the task has tags TEMPLATE     Matches if the task is a recurrence template TODAY        Matches if the task is due today TOMORROW     Matches if the task is due sometime tomorrow UDA          Matches if the task has any UDA values UNBLOCKED    Matches if the task is not blocked UNTIL        Matches if the task expires WAITING      Matches if the task is waiting WEEK         Matches if the task is due this week YEAR         Matches if the task is due this year YESTERDAY    Matches if the task was due sometime yesterday
You can use +BLOCKED to filter blocked tasks, or -BLOCKED for unblocked tasks.  Similarly, -BLOCKED is equivalent to +UNBLOCKED. It is an error to attempt to add or remove a virtual tag.
project:<project-name> Specifies the project to which a task is related to.
priority:H|M|L or priority: Specifies High, Medium, Low and no priority for a task.
due:<due-date> Specifies the due-date of a task.
recur:<frequency> Specifies the frequency of a recurrence of a task.
scheduled:<ready-date> Specifies the date after which a task can be accomplished.
until:<expiration date of task> Specifies the expiration date of a task, after which it will be deleted.
limit:<number-of-rows> Specifies the desired number of tasks a report should show, if a positive integer is given.  The value 'page' may also be used, and will limit the report output to as many lines of text as will fit on screen.  This defaults to 25 lines.
wait:<wait-date> When a task is given a wait date, it is hidden from most built-in reports, which exclude +WAITING.  When the date is in the past, the task is not considered +WAITING, and again becomes visible. Note that, for compatibilty, such tasks are shown as having status "waiting", but this will change in a future release.
depends:<id1,id2 ...> Declares this task to be dependent on id1 and id2.  This means that the tasks id1 and id2 should be completed before this task. Consequently, this task will then show up on the 'blocked' report. It accepts a comma-separated list of ID numbers, UUID numbers and ID ranges.  When prefixing any element of this list by '-', the specified tasks are removed from the dependency list.
entry:<entry-date> For report purposes, specifies the date that a task was created.
Attribute modifiers improve filters.  Supported modifiers are:
before (synonyms under, below) after (synonyms over, above) by none any is (synonym equals) isnt (synonym not) has (synonym contains) hasnt startswith (synonym left) endswith (synonym right) word noword
They can be applied to all regular attributes (see above) and the following calculated attributes:
urgency (or short urg)
task due.before:eom priority.not:L list
The before modifier is used to compare values, preserving semantics, so project.before:B list all projects that begin with 'A'.  Priority 'L' is before 'M', and due:2011-01-01 is before due:2011-01-02.  The synonyms 'under' and 'below' are included to allow filters that read more naturally.
The after modifier is the inverse of the before modifier.
The by modifier is the same as 'before', except it also includes the moment in question.  For example:
task add test due:eoy
will be found when using the inclusive filter 'by':
task due.by:eoy
but not when the non-inclusive filter 'before' is used:
task due.before:eoy
this applies equally to other named dates such as 'eom', 'eod', etc; the modifier compares using '<=' rather than '<' like 'before' does.
The none modifier requires that the attribute does not have a value.  For example:
task priority:      list task priority.none: list
are equivalent, and list tasks that do not have a priority.
The any modifier requires that the attribute has a value, but any value will suffice.
The is modifier requires an exact match with the value.
The isnt modifier is the inverse of the is modifier.
The has modifier is used to search for a substring, such as:
task description.has:foo list task foo                 list
These are equivalent and will return any task that has 'foo' in the description or annotations.
The hasnt modifier is the inverse of the has modifier.
The startswith modifier matches against the left, or beginning of an attribute, such that:
task project.startswith:H list task project:H            list
are equivalent and will match any project starting with 'H'.  Matching all projects not starting with 'H' is done with:
task project.not:H         list
The endswith modifier matches against the right, or end of an attribute.
The word modifier requires that the attribute contain the whole word specified, such that this:
task description.word:bar list
Will match the description 'foo bar baz' but does not match 'dog food'.
The noword modifier is the inverse of the word modifier.
You can use the following operators in filter expressions:
and  or  xor  !               Logical operators <  <=  =  ==  !=  !==  >=  >  Relational operators (  )                          Precedence
task due.before:eom priority.not:L list task '( due < eom or priority != L )' list task '! ( project:Home or project:Garden )' list
The = operator tests for approximate equality.  Dates compare equal if they are on the same day (hour and minutes are ignored).  Strings compare equal if the left operand starts with the right operand.  The == operator tests for exact equality.  The != and !== operators are the negation of = and == respectively.  The negation operator is !.
Note that the parentheses are required when using a logical operator other than the 'and' operator.  The reason is that some reports contain filters that must be combined with the command line.  Consider this example:
task project:Home or project:Garden list
While this looks correct, it is not.  The 'list' report contains a filter of:
task show report.list.filter
Config Variable    Value -----------------  -------------- report.list.filter status:pending
Which means the example is really:
task status:pending project:Home or project:Garden list
The implied 'and' operator makes it:
task status:pending and project:Home or project:Garden list
This is a precedence error - the 'and' and 'or' need to be grouped using parentheses, like this:
task status:pending and ( project:Home or project:Garden ) list
The original example therefore must be entered as:
task '( project:Home or project:Garden )' list
This includes quotes to escape the parentheses, so that the shell doesn't interpret them and hide them from Taskwarrior.
There is redundancy between operators, attribute modifiers and other syntactic sugar.  For example, the following are all equivalent:
task foo                      list task /foo/                    list task description.contains:foo list task description.has:foo      list task 'description ~ foo'      list
DATES Taskwarrior reads dates from the command line and displays dates in the reports.  The expected and desired date format is determined by the configuration variable dateformat
Exact specification task ... due:7/14/2008
ISO-8601 task ... due:2013-03-14T22:30:00Z
Relative wording task ... due:now task ... due:today task ... due:yesterday task ... due:tomorrow
Day number with ordinal task ... due:23rd task ... due:3wks task ... due:1day task ... due:9hrs
Start of next (work) week (Monday), calendar week (Sunday or Monday), month, quarter and year task ... due:sow task ... due:soww task ... due:socw task ... due:som task ... due:soq task ... due:soy
End of current (work) week (Friday), calendar week (Saturday or Sunday), month, quarter and year task ... due:eow task ... due:eoww task ... due:eocw task ... due:eom task ... due:eoq task ... due:eoy
At some point or later task ... wait:later task ... wait:someday
This sets the wait date to 12/30/9999.
Next occurring weekday task ... due:fri
Predictable holidays task ... due:goodfriday task ... due:easter task ... due:eastermonday task ... due:ascension task ... due:pentecost task ... due:midsommar task ... due:midsommarafton task ... due:juhannus
FREQUENCIES Recurrence periods. Taskwarrior supports several ways of specifying the frequency of recurring tasks.
daily, day, 1da, 2da, ... Every day or a number of days.
weekdays Mondays, Tuesdays, Wednesdays, Thursdays, Fridays and skipping weekend days.
weekly, 1wk, 2wks, ... Every week or a number of weeks.
biweekly, fortnight Every two weeks.
monthly, month, 1mo, 2mo, ... Every month.
quarterly, 1qtr, 2qtrs, ... Every three months, a quarter, or a number of quarters.
semiannual Every six months.
annual, yearly, 1yr, 2yrs, ... Every year or a number of years.
biannual, biyearly, 2yr Every two years.
Context is a user-defined query, which is automatically applied to all commands that filter the task list and to commands that create new tasks (add, log). For example, any report command will have its result affected by the current active context.  Here is a list of the commands that are affected:
add burndown count delete denotate done duplicate edit history log prepend projects purge start stats stop summary tags
All other commands are NOT affected by the context.
$ task list ID Age Project  Description        Urg 1  2d  Sport    Run 5 miles        1.42 2  1d  Home     Clean the dishes   1.14
$ task context home Context 'home' set. Use 'task context none' to remove.
$ task list ID Age Project  Description        Urg 2  1d  Home     Clean the dishes   1.14 Context 'home' set. Use 'task context none' to remove.
Task list got automatically filtered for project:Home.
$ task add Vaccuum the carpet Created task 3. Context 'home' set. Use 'task context none' to remove.
$ task list ID Age Project  Description         Urg 2  1d  Home     Clean the dishes    1.14 3  5s  Home     Vaccuum the carpet  1.14 Context 'home' set. Use 'task context none' to remove.
Note that the newly added task "Vaccuum the carpet" has "project:Home" set automatically.
As seen in the example above, context is applied by specifying its name to the "context" command. To change the currently applied context, just pass the new context's name to the 'context' command.
To unset any context, use the 'none' subcommand.
$ task context none Context unset.
$ task list ID Age Project  Description         Urg 1  2d  Sport    Run 5 miles         1.42 2  1d  Home     Clean the dishes    1.14 3  7s  Home     Vaccuum the carpet  1.14
Context can be defined using the 'define' subcommand, specifying both the name of the new context, and it's assigned filter.
$ task context define home project:Home Are you sure you want to add 'context.home.read' with a value of 'project:Home'? (yes/no) yes Are you sure you want to add 'context.home.write' with a value of 'project:Home'? (yes/no) yes Context 'home' successfully defined.
Note that you were separately prompted to set the 'read' and 'write' context.  This allows you to specify contexts that only work for reporting commands or only for commands that create tasks.
To remove the definition, use the 'delete' subcommand.
$ task context delete home Are you sure you want to remove 'context.home.read'? (yes/no) yes Are you sure you want to remove 'context.home.write'? (yes/no) yes Context 'home' deleted.
To check what is the currently active context, use the 'show' subcommand.
$ task context show Context 'home' with
* read filter: '+home' * write filter: '+home'
is currently applied.
Contexts can store arbitrarily complex filters.
$ task context define family project:Family or +paul or +nancy Are you sure you want to add 'context.family.read' with a value of 'project:Family or +paul or +nancy'? (yes/no) yes Are you sure you want to add 'context.family.write' with a value of 'project:Family or +paul or +nancy'? (yes/no) no Context 'family' successfully defined.
Contexts are permanent, and the currently set context name is stored in the "context" configuration variable. The context definition is stored in the "context.<name>.read" configuration variable (for reporting commands) and "context.<name>.write" configuration variable (for task additions, i.e. task add/log).
Note that in the example above, the user decided not to define the complex filter as writeable context. The reason for this decision is that the complex filter in the example does not directly translate to a modification. In fact, if such a context is used as a writeable context, the following happens:
$ task add Call Paul Created task 4. Context 'family' set. Use 'task context none' to remove.
$ task 4 list ID Age  Project Tags       Description      Urg 4 9min Family  nancy paul or or Call Paul    0
There is no clear mapping between the complex filter used and the modifications (should only the project be set? only the tags? both?). Additionally note the 'or' operators being present in the description. Taskwarrior does not try to guess the user intention here, and instead, the user is expected to set the "context.<name>.write" variable to make their intention explicit, for example:
$ task config context.family.write project:Family Are you sure you want to change the value of 'context.family.write' from 'project:Family or +paul or +nancy' to 'project:Family'? (yes/no) yes Config file /home/tbabej/.config/task/taskrc modified.
$ task context Name   Type  Definition                        Active family read  project:Family or +paul or +nancy yes write project:Family                    yes home   read  +home                             no write +home                             no
Note how read and write contexts differ for context "family", while for context "home" they stay the same.
In addition, every configuration parameter can be overridden for the current context, by specifying context.<name>.rc.<parameter>. For example, if the default command for the family context should be displaying the family_report:
$ task config context.family.rc.default.command family_report
All Taskwarrior commands may be abbreviated as long as a unique prefix is used, for example:
$ task li
is an unambiguous abbreviation for
$ task list
$ task l
could be list, ls or long.
Note that you can restrict the minimum abbreviation size using the configuration setting:
abbreviation.minimum=3
Some task descriptions need to be escaped because of the shell and the special meaning of some characters to the shell. This can be done either by adding quotes to the description or escaping the special character:
$ task add "quoted ' quote" $ task add escaped \' quote
The argument -- (a double dash) tells Taskwarrior to treat all other args as description:
$ task add -- project:Home needs scheduling
In other situations, the shell sees spaces and breaks up arguments.  For example, this command:
$ task 123 modify /from this/to that/
is broken up into several arguments, which is corrected with quotes:
$ task 123 modify "/from this/to that/"
It is sometimes necessary to force the shell to pass quotes to Taskwarrior intact, so you can use:
$ task add project:\'Three Word Project\' description
Taskwarrior supports Unicode using only the UTF8 encoding, with no Byte Order Marks in the data files.
Taskwarrior stores its configuration in a file in the user's home directory: ~/.taskrc. The default configuration file can be overridden with:
task rc:<path-to-alternate-file> ... Specifies an alternate configuration file with highest priority.
TASKRC=<path-to-alternate-file> task .. The environment variable specifies an alternate configuration file to use.
XDG_CONFIG_HOME=<path-to-alternate-config-home> task .. The environment variable specifies an alternate configuration file to use.
task rc.<name>:<value> ... task rc.<name>=<value> ...  Specifies individual configuration file overrides.
TASKDATA=/tmp/.task task ... The environment variable overrides the default, and the 'data.location' configuration setting of the task data directory.
For examples please see the online documentation starting at
<https://taskwarrior.org/docs>
Note that the online documentation can be more detailed and more current than this man page.
~/.taskrc User configuration file - see also taskrc(5).  Note that this can be overridden on the command line or by the TASKRC environment variable. Also, if ~/.taskrc doesn't exist and XDG_CONFIG_HOME environment variable is defined, taskwarrior will check if $XDG_CONFIG_HOME/task/taskrc exists and attempt to read it
~/.task The default directory where task stores its data files. The location can be configured in the configuration variable 'data.location', or overridden with the TASKDATA environment variable..