| 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.
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 $(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 $(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.
This command is mainly of use to external scripts.
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
Warning: causes permanent, non-revertible loss of data.
Miscellaneous subcommands either accept no command line arguments, or accept non-standard arguments.
Examples:
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
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
Example:
task context work
Example:
task context delete work
Examples:
task context define work project:Work
task context define home project:Home or +home
task context define superurgent due:today and +urgent
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.
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 +PENDING _unique project
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>
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.
Attribute modifiers improve filters. Supported modifiers are:
They can be applied to all regular attributes (see above) and the following calculated attributes:
For example:
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
For example:
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
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
This sets the wait date to 12/30/9999.
Recurrence periods. Taskwarrior supports several ways of specifying the frequency of recurring tasks.
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:
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:
is an unambiguous abbreviation for
but
could be list, ls or long.
Note that you can restrict the minimum abbreviation size using the configuration setting:
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:
The argument -- (a double dash) tells Taskwarrior to treat all other args as description:
In other situations, the shell sees spaces and breaks up arguments. For example, this command:
is broken up into several arguments, which is corrected with quotes:
It is sometimes necessary to force the shell to pass quotes to Taskwarrior intact, so you can use:
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:
For examples please see the online documentation starting at
Note that the online documentation can be more detailed and more current than this man page.
Copyright (C) 2006 - 2021 T. Babej, P. Beckingham, F. Hernandez.
Taskwarrior is distributed under the MIT license. See https://www.opensource.org/licenses/mit-license.php for more information.
taskrc(5), task-color(5), task-sync(5)
For more information regarding Taskwarrior, see the following:
| 2016-02-24 | task 2.6.2 |