return code for all vs _uuid (_unique uuid)

[s7hoang]

Was just wondering if this is a bug or intended:

task pro:something-with-no-items all
echo $?  # returns 1

vs

task pro:something-with-no-items _uuid
echo $?  # returns 0

apparently _uuid is deprecated but is consistent with the recommended command:

task pro:something-with-no-items _unique uuid
echo $?  # returns 0

thanks.

[ashprice]

I too have encoutered this issue and it's quite pernacious as it prevents you from fex. grabbing the uuids of deleted tasks.

At first I thought it was because of the implementation of the _uuid/_unique uuid calls, given in the docs it says these relate to pending tasks (even though non-pending tasks have uuids...) - but this doesn't seem the case, as for example, trying to run certain actions on things filtered with task all also fail:

task all status:deleted +PARENT purge

returns no matches (while task all status:deleted +PARENT does. I wanted to write some scripts to clear out old junk that is slowing performance, and I am having to resort to using task _uuid and grep on the data files, because try as I might, I cannot figure out easy ways to call these via tw.

Probably I could take a play with tw code and issue a pull request, as I have modified my own tw install before by changing aspects of stuff that I dislike, but I find it to be a hassle and that grep etc. are likely to be more convenient. Potentially there's something obvious and the commands I mentioned above are incorrect though.

Also in my case I mentioned performance issues - supposedly this excess data shouldn't cause performance issues because of how taskwarrior calls files (according to previous git issues), but I can confirm it does, rather trivially, by eg. moving backlog.data, or temporarily removing lines from undo.data, or deleting a few deleted objects from completed.data, and then running regular task filter commands like task ready proj:Foo.

(Also the sheer speed of grep has me wondering if I need all the safety that comes with a tool like TW - but I figure it'll probably take me longer to reimplement tw with shell, ripgrep, and yaml, than it will just to live with it.)

[ashprice]

I realised two things - first this was quite an old post...

Second, I was tripping up on the syntax with reports vs write commands:

task status:deleted +PARENT end.before:today-7d _unique uuid

works. As does:

task status:deleted +PARENT end.before:today-7d purge

TW can be quite tolerant (surprisingly so) of one fudging syntax in other areas, so I suppose I had ingrained bad habits.

These realisations have made my life exponentially easier. TW is still slower at it than ripgrep, though, funnily enough. I wish there was a native TW way to do the following:

• clear out info in undo.data that is not related to any current (pending, completed, deleted) task, period.
• clear out info in undo.data that is related to tasks but where the modification was made X time period ago or where the modification was n modifications of task Y ago.
• a 'smart' way of addressing all this with configurable/sane defaults.

My script for this kind of thing is coming along, but it's honestly a headache to reason through/to keep the modifications safe + sane. I am not sure why I have the performance issues that I do - it is not like they are severe, it is just that the lag of simple commands is enough to bother me, I am used to relatively instant feedback from CLI tools.