New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fail on broken symlink to avoid potential data loss #359
Comments
Instead of potentially falling back to the built-in action that a custom action was intended to override, but (e.g. due to file system reorganizations) now results in a broken link. The extension functionality that is then skipped may result in undesired results, but this may not be immedately obvious to the user (if the extension is not particularly verbose), so some data corruption could occur if this remains undetected. To avoid duplicating (or somehow extracting) all the built-in actions, simply detect _any_ broken symlink; i.e. offer a superset of the required functionality. So this would also complain about a broken symlink to a non-executable custom (auxiliary) file (rarely used) if that is mistakenly passed as a custom action (unlikely). Fixes todotxt#359
That's indeed a potential problem, though it would only affect power users with customizations that extend the built-in commands. I'm using such symlinks myself, and I also have done such reorganizations that required the update of them. If we don't limit this check to built-in commands, a small additional logic can detect and deal with it, as in my PR. |
@inkarkat, thanks! If I understand correctly, applying the check to all commands simply results in a more explicit error (versus a general failure with usage output) in the case of a non-built-in custom add-on. Thus the way you did it seems optimal to me, in addition to reducing required logic. Also I tested your changes (e1c1c32) and it looks good to me! |
@owenh000 thanks for testing my changes! Yes, you're right, in case of a custom add-on that's not overriding a built-in command, it now also complains about the broken symlink instead of assuming such an add-on command does not exist, and just printing the generic usage help. |
When the user attempts to run an add-on action that does not exist, todo.txt-cli prints a usage message and fails. However, todo.txt-cli supports add-ons that replace built-in actions. In this case, it is important to fail if there is something wrong with the add-on. Otherwise the user thinks they are still running the add-on while in reality they are only running the built-in action.
Here is an example scenario. This is based on real cases; see the again add-on README and the dorecur add-on README (of which I am the author). Other add-ons may be affected also.
command do
to access the built-in action as required. This is necessary to prevent the user from accidentally running do and discarding a recurring task.~/.todo.actions.d/
.Do you want to request a feature or report a bug?
That's open to interpretation, but I'll call this a bug.
What is the current behavior?
todo.txt-cli silently ignores an add-on that is a broken symbolic link.
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.
What is the expected behavior?
If:
then todo.txt-cli should fail with an error.
It seems reasonable to also apply this to other cases where an add-on is apparently installed but cannot be used, for example when an add-on file or directory lacks whatever read/execute permissions may be required.
Which versions todo.sh are you using?
Which Operating System are you using?
Debian GNU/Linux Bullseye
Which version of bash are you using?
The text was updated successfully, but these errors were encountered: