|
|
|
|
|
by wintermutestwin
305 days ago
|
|
>rsync which is well documented Here is the man page entry for the --delete flag: --delete is used. This option is mutually exclusive with --delete-during,
--delete-delay, and --delete-after. Hilarious! Reading and understanding the rsync command would take much more than 10 mins and I am not a total newb here. |
|
A search query takes a matter of seconds to type in, select a result and read. No doubt still under 10 minutes.
But still to my original point it’s insanely more expensive to have chatgpt look it up. This doesn’t bother you because you are privileged enough to waste money there. If time is money then IMO the only valuable time I have with my money is when it’s gaining interest and not being spent.
You can abstract away all the “but I had to scroll down the page and click a different result” steps as “time savings” all you want, but no one was wasting a ton of time there for already well established tools. That is a deluded myth.
I’m not sure I even grasped your point. The delete flag is pretty self explanatory and gives you options for more granularity. Why does that take greater than 10 mins? What is the issue with that entry?
Here is what I get when I type `man rsync`:
``` --delete This tells rsync to delete extraneous files from the receiving side (ones that aren't on the sending side), but only for the directories that are being synchronized. You must have asked rsync to send the whole directory (e.g. "dir" or "dir/") without using a wildcard for the directory's contents (e.g. "dir/*") since the wildcard is expanded by the shell and rsync thus gets a request to transfer individual files, not the files' parent directory. Files that are excluded from the transfer are also excluded from being deleted unless you use the --delete-excluded option or mark the rules as only matching on the sending side (see the include/exclude modifiers in the FILTER RULES section).
```