Improved log messages that contain a directory path

[xanderio]

When logging a message about archive creation it was formatted with a
static '/' in front for the directory name. This is fine relative
directory paths, but when using a absolute path this will lead to a
double '/' being printed.

This change only add a '/' in front of the path if there is non.

Without this change:

   input            output
"/usr/local" ->  "//usr/local"
"usr/local"  ->  "/usr/local"

With this change:

   input            output
"/usr/local" ->  "/usr/local"
"usr/local"  ->  "/usr/local"

[xanderio]

I'm not sure how to make the CI happy as the tool shfmt give me some other output when run locally and i'm unable to find the configuration for the CI pipeline.

[assistcontrol]

Thanks for this PR, @xanderio!

I'm not clear on why you'd need absolute paths. Everything is always relative to /. Can you describe your use case?

[xanderio]

On Sun, 23. Jun 07:09, Adam Weinberger wrote: Thanks for this PR, @xanderio! I'm not clear on why you'd need absolute paths. Everything is always relative to `/`. Can you describe your use case?

I use absolute paths so that the shell will use globs. For example when creating backups of `/usr/local/etc` for multiple jails. But the shell glob expansion is only trigger when providing an absolute path. `/usr/jails/*/usr/local/etc`.

…

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #36 (comment)

[assistcontrol]

That's an interesting use case; I hadn't considered that approach before.

This sounds like a pretty unique usage though, and I'm not sure this message will have a big impact on other users.

To me, this sounds like something that upstream tarsnap might address. Why should -c /usr/*/etc behave differently from -C / -c usr/*/etc?

(Edit: typo)

[xanderio]

Because the * is not expanded by tarsnap. * is a shell feature.

In this case for *-expansion to work the shell need to know what to expand it to.
So when using a relative path it will check based on the current working directory. Which is probably the users $HOME, so the shell can't expand the pattern which is indent to be bases on / and will leave it as it is.

When using a absolute path the shell can expand the pattern and replace the path with a * in it with a list of all the possible options.

In case of the program path in the backuptargets variable will expanded when the shell first evaluates the variable.

For example amusing this file layout

/
   home
       user1
       user2
       user3    

backuptargets="/home/*"

will become

backuptargets="/home/user1 /home/user2 /home/user3"

[assistcontrol]

Ah, I hadn't thought about it being a simple shell expansion.

So, you're of course completely correct that, while technically valid, the output is clearly clunky-looking and suboptimal. I'm working a major refactoring that would clobber this patch anyway, so I won't merge the PR right now. I'll do my best to fix this output during the refactor, and I'll ping you here once the branch for it is pushed.

In the meantime, some alternatives might also accomplish what you're looking for:

• acts.conf is just a sourced shell script:

    backuptargets="home var/backups $(cd / && find usr/jail -type d -name etc)"
  

• Tell tarsnap itself to run from / in acts.conf:

    tarsnap="cd / && tarsnap"
  

[assistcontrol]

I added the formatter into a single function, so this should be working as you intended now. Please re-open if it doesn't do the right thing. Thanks for submitting this and for your patience, @xanderio.