Open ayberkt opened 3 years ago
There is no terribly good reason. Technical reason is that the script header is written before rmlint
actually knows if there are some duplicates. But it would be possible to delete the file once that is clear.
I think it would be more natural to handle the situation specially in cases where no duplicates are found; for instance: print a message explaining that no duplicates have been found and hence no script has been generated.
I agree. It would be more natural when rmlint
does not produce lint in that case.
There is no terribly good reason
I wonder about users who use rmint
in another script, eg whic could be used to dedupe btrfs filesystems:
deduper.sh
-----------
#!/bin/bash
rmlint -o sh:/tmp/dedupe.sh -T df -c sh:clone /home
/tmp/dedupe.sh -d
Ok it's not the end of the world if their script can't find the shell script, but...
Perhaps an alternative solution would be to over-write the shell script with a very short summary:
#!/bin/sh
# This file was autowritten by rmlint
# rmlint was executed from: /home/user
# Your command line was: rmlint -o sh:dedupe.sh -T df -c sh:clone
# Nothing to do - no lint found
A related issue / feature request would be to "de-lint" the rmlint.sh
file to remove unused function definitions if, for example there are no calls to handle_emptyfile()
or handle_emptydir()
I found it slightly confusing that a deletion script is generated even when no duplicates are found. Is there a good reason for this behaviour?
I think it would be more natural to handle the situation specially in cases where no duplicates are found; for instance: print a message explaining that no duplicates have been found and hence no script has been generated.