two gruel

[greg-minshall]

hi. this is great. so great, i have two requests. (i'll file two issues, if that would be better.)

1. split split presets, for restic commands. something like [global@.backup]. for example, my --exclude-file is common to all my locations, sources. or, i could put verbose there.

2. this is harder. but, i'd love an environmental variable (i guess that's the state of the art) that would get crestic to list all possible combinations of commands that can be generated by crestic.cfg, each line being prefixed with the preset that would generate the rest of that line. this would presumably require a fair amount of restructuring. my use is to do shell auto-complete -- i would grep the output, looking for UUIDs (which i embed in repo names) of devices that are actually mounted, or at least physically attached to the system (which i guess i can get from lsblk(1)). but, others could autocomplete on other bits, i suspect.

i could try my hand at one or two of the above, if you might be interested in a 'pull request'.

cheers.

[nils-werner]

split split presets, for restic commands. something like [global@.backup]. for example, my --exclude-file is common to all my locations, sources. or, i could put verbose there.

I am not sure I inderstand, can you explain further?

I'd love [...] crestic to list all possible combinations of commands that can be generated by crestic.cfg. [...] my use is to do shell auto-complete.

That's actually an interesting scenario, but I agree, it might need some restructuring first. Also, I am not sure how to make my shell aware of the autocomplete functionality. How would such a thing work?

[greg-minshall]

1. sorry. i realize (note to self: rtfm) that [global.backup] satisfies my desire. thanks -- sorry.

[greg-minshall]

2. autocomplete (i guess "bash completions" is the more-normal name) seemed to me like magic for many years, but a few years back i wrote bits of one for pass. but, i am still mystified when i look at my code, and always need to come back up to speed as to how it all fits together.

• i think for "small" packages, like crestic, the completion scripts are distributed with the package (or provided by other end users), but there are also packages, like, e.g., bash-completion, on my arch linux system, that package a host of completions for generally used commands. often, one installs a completion script somewhere like /etc/bash_completion.d/, for the shell to find.

i don't know if that answers your question?

[nils-werner]

You are asking for bash autocompletion of presets and commands, right? In that case we need an API to tell bash the next available parameter choices. My question was about to implement such a thing.

[greg-minshall]

Nils, sorry, i fumbled the answer. apologies, though, but i'm still not sure i understand the question. the general process (iiuc) is that the shell passes the completion function (which is specific to the particular command, e.g., crestic in this case) the command line as typed by the user up to the point the user hits <TAB> (or whatever), and the completion function uses that to decide what might come next, and then queries the user to select one of those choices, and returns that to the shell, which then continues to read user input up to a newline. to do this, the completion function needs to know what is possible.

for typical parameters (commands like "backup", arguments like "--ignore-inode"), knowledge is (typically) hard-coded into the completion function itself. for the presets, somebody needs to parse the config file and provide the choices. this is why i was asking for a list of all possible commands generated from the config file -- then i could write a completion function that would provide the possible choices to the user.

(in my particular case, i would match the path names with what volumes are currently mounted with the list of possible commands, and present exactly those choices to the user; the user could then type a character or two, and hit <TAB> again, and maybe end up with the one command that would work. details "tbd". :)

i hope that seems responsive. (and apologize in advance if not.)

[nils-werner]

I had a look at how autocompletion works and I think it would only unneccessarily complicate things. If someone feels like submitting a (simple!) PR, feel free to do so, but until then I will be closing this ussue :-)

[greg-minshall]

fair enough! i'll emphasize that the main request was re-"factoring" your code to make it easier to use with an auto-completion strategy. if i circle back around to it (the circumference is large!), i'll possibly give it a try, and run it by you. cheers!