[danielbln]

Telling the agent to execute "man rsync" and synthesize the answer from there is probably the cheapest and most efficient option.

Letting some detached LLM fumble around for an hour is never the right way to go, and inversely sifting through the man page of rsync or fmmpeg or (God forbid) jq to figure out some arcane syntax isn't exactly a great use of anyone's time either, all things considered.

[righthand]

Sifting through just means you don’t know how to use the man interface to search/grep (which from a discoverability perspective is fair). However I think reeling through an Llm (using an agent or not) for a task that probably could take <10mins at $0, demonstrates enthusiasts disregard for a good set of research and reading habits.

All of this is an attempt at circumventing RTFM because you’re privileged enough to afford it.

Just lay yourself down on the WALL-E floating bed and give up already.

[wintermutestwin]

The “fucking” manual is obtuse, overly verbose, and almost always lacking in super clear real world examples. That you claim it is a <10 min problem demonstrates experts disregard for the degree of arcane crap, a beginner needs to synthesize.

I am backing up and verifying critical data here. This is not a task that should be taken lightly. And as I learned, it is not a task that one can rely on an LLM for.

[righthand]

I disagree. The topic is rsync which is well documented. The path forward might not work in every situation but the manual has good examples too. This is probably true for what Llm users use it for 90% of the time. To hack together things that are well known and well documented into a result. Llms arguably only work because these tools ffmpeg, rsync, etc were already solving problems and widely used and documented. So burning energy to have a computer look up commands because you couldn’t spend 10 minutes reading yourself could be a waste of time and money. Where as having to spend time researching is likely only a waste of time only.

[wintermutestwin]

>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.

[righthand]

What command? Just to clarify there is no example command we’re discussing here. You’re just cherry picking results exclusively from the man page and then arguing that chatgpt is better because it gets to use example documentation from the internet. Well I get to use examples from the internet too.

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).

              Prior to rsync 2.6.7, this option would have no effect unless
              --recursive was enabled.  Beginning with 2.6.7, deletions will
              also occur when --dirs (-d) is enabled, but only for directories
              whose contents are being copied.

              This option can be dangerous if used incorrectly! It is a very
              good idea to first try a run using the --dry-run (-n) option to
              see what files are going to be deleted.

              If the sending side detects any I/O errors, then the deletion of
              any files at the destination will be automatically disabled.
              This is to prevent temporary filesystem failures (such as NFS
              errors) on the sending side from causing a massive deletion of
              files on the destination.  You can override this with the
              --ignore-errors option.

              The --delete option may be combined with one of the --delete-
              WHEN options without conflict, as well as --delete-excluded.
              However, if none of the --delete-WHEN options are specified,
              rsync will choose the --delete-during algorithm when talking to
              rsync 3.0.0 or newer, or the --delete-before algorithm when
              talking to an older rsync.  See also --delete-delay and
              --delete-after.

```

[wintermutestwin]

I pasted the results of typing man rsync into my macbook’s terminal. I looked up the —delete parameter and pasted the entry. Not sure why your entry was more useful - perhaps a version issue (which is at the root of the painful time I have spent trying to learn how to do something trivial).

Later in the man page, it gives examples and totally fails to explain those examples. And yes, for someone who is going to be doing this frequently and professionally. They should understand this deeply and spending the hours required to be fluent in a command with a kitchen sink full of parameters. I, on the other hand, will be executing these commands maybe a few times in a year.

The more I think about it, the more I think the solution here is to use LLM‘s to write better documentation with lenses for different types of users with different needs.