Replies: 1 comment
-
I think I've read somewhere that where unambiguous the commands work nonetheless. This is especially the case for commands that take filters only. This for example places the first parameter that follows tA in the filter and all following params into the modifications space:
Or this one that sets the dependecy of given task range (e.g. 1-5,8 without spaces) to all following tasks (after a space):
Note that only the first parameter can be a task range since depends: does not work with ranges. Hope I could help and spark a little inspiration. Feel free to ask for help although I myself am just getting into all this. |
Beta Was this translation helpful? Give feedback.
-
So when I was newer to TW and had less of a clue. I wrote a bunch of aliases and functions in the shell to make input easier. I'm now rewriting my little library to capitalize on new stuff I've learned since I started with TW a couple of years back.
Looking at my old scripts, I'm noticing some commands are wrong, although they seem to have always worked. Example:
alias td=task done "$@"
alias tm=task modify "$@"
But according to the documentation, the the task ids should go before the
done
command and any modifications should go after themodify
command. It seems the developers decided to modify the parser to accommodate bad user input and turn it into valid input, AFAICT.I'm wondering if this is documented somewhere and what exactly the rules are so I might take advantage of this little quirk and make processing commands easier when I rewrite my library. Thanks!
(and yes, I'm now aware you can put aliases in the
rc
file and do stuff liket 23 m description
. Though it is still nice not to have to type the space).Beta Was this translation helpful? Give feedback.
All reactions