bash completion for duplicity

[duplicity-talk mailing list]

hello list,

i found a bash completion config for duplicity at http://neuling.org/devel/junkcode/duplicity-completion so i wonder whether (if author agrees) this could be added to duplicity.

br, jose

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk

[duplicity-talk mailing list]

On 25.06.2018 09:26, Jozef Riha via Duplicity-talk wrote:
> hello list,
>
> i found a bash completion config for duplicity at http://neuling.org/devel/junkcode/duplicity-completion so i wonder whether (if author agrees) this could be added to duplicity.
>

hey Jose,

nice catch. i'd agree to add it provided some enhancements are done.

1.
it contains a regex bash comparision, which is not backward compatible with older bash and would need to be replaced
  [[ "$cur" == -* ]]
.

2.
we would need a license or written approval of the original author to license it preferably under the same license duplicity is currently under.

3.
main issue - maintaining the list of options is tiresome. there should be a way of either asking duplicity for it's options (eg. parsing help) or generating the list during distro build.
if that does not happen the list will become outdated very fast as contributors regularly forget to document their changes. we have to point out update the man page in pretty much every merge request.

if you'd be willing to tackle these points, i'd see no further obstacles so far.

@Ken: what do you think?

.. ede/duply.net

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk

[duplicity-talk mailing list]

Hi,

I looked at the website for this project and it's kinda minimal.  Who owns it?  (whois does not help).

Other than that, it sound like a good idea.  Even I forget options when I use duplicity.

...Ken

On Mon, Jun 25, 2018 at 4:28 AM, <[hidden email]> wrote:

On 25.06.2018 09:26, Jozef Riha via Duplicity-talk wrote:
> hello list,
>
> i found a bash completion config for duplicity at http://neuling.org/devel/junkcode/duplicity-completion so i wonder whether (if author agrees) this could be added to duplicity.
>

hey Jose,

nice catch. i'd agree to add it provided some enhancements are done.

1.
it contains a regex bash comparision, which is not backward compatible with older bash and would need to be replaced
  [[ "$cur" == -* ]]
.

2.
we would need a license or written approval of the original author to license it preferably under the same license duplicity is currently under.

3.
main issue - maintaining the list of options is tiresome. there should be a way of either asking duplicity for it's options (eg. parsing help) or generating the list during distro build.
if that does not happen the list will become outdated very fast as contributors regularly forget to document their changes. we have to point out update the man page in pretty much every merge request.

if you'd be willing to tackle these points, i'd see no further obstacles so far.

@Ken: what do you think?

.. ede/duply.net

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk

[duplicity-talk mailing list]

Hello Jose,

On 2018-06-25 10:28, edgar.soldin--- via Duplicity-talk wrote:

> On 25.06.2018 09:26, Jozef Riha via Duplicity-talk wrote:
>> hello list,
>>
>> i found a bash completion config for duplicity at
>> http://neuling.org/devel/junkcode/duplicity-completion so i wonder
>> whether (if author agrees) this could be added to duplicity.
>>
>
> hey Jose,
>
> nice catch. i'd agree to add it provided some enhancements are done.

[...]

> 3.
> main issue - maintaining the list of options is tiresome. there should
> be a way of either asking duplicity for it's options (eg. parsing
> help) or generating the list during distro build.
> if that does not happen the list will become outdated very fast as
> contributors regularly forget to document their changes. we have to
> point out update the man page in pretty much every merge request.
>
> if you'd be willing to tackle these points, i'd see no further
> obstacles so far.

Without digging into the detail, this:
http://argcomplete.readthedocs.io/en/latest/
apparently automatically collects options for bash completion from
argparse, which feels like a sensible approach.

Moving from Optparse to Argparse is on the roadmap already anyway:
https://bugs.launchpad.net/duplicity/+bug/1480565

Kind regards,

Aaron

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk

[duplicity-talk mailing list]

On 26.06.2018 14:49, Aaron wrote:
> Without digging into the detail, this:
> http://argcomplete.readthedocs.io/en/latest/
> apparently automatically collects options for bash completion from argparse, which feels like a sensible approach.
>
> Moving from Optparse to Argparse is on the roadmap already anyway:
> https://bugs.launchpad.net/duplicity/+bug/1480565


agreed, this approach looks much cleaner than a manually maintained list of options.. ede/duply.net

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk

[duplicity-talk mailing list]

Reading through the docs, it wants to execute duplicity during the autocomplete to get the options, and leave no side effects.  That could be problematic.

...Ken

On Tue, Jun 26, 2018 at 7:54 AM edgar.soldin--- via Duplicity-talk <[hidden email]> wrote:

On 26.06.2018 14:49, Aaron wrote:
> Without digging into the detail, this:
> http://argcomplete.readthedocs.io/en/latest/
> apparently automatically collects options for bash completion from argparse, which feels like a sensible approach.
>
> Moving from Optparse to Argparse is on the roadmap already anyway:
> https://bugs.launchpad.net/duplicity/+bug/1480565


agreed, this approach looks much cleaner than a manually maintained list of options.. ede/duply.net

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk

[duplicity-talk mailing list]

yeah,

would have to be implemented cleanly of course. see no disadvantage though in having command line parameters parsed earliest.

but it's all rhetorical anyway as long as nobody implements argparse first ;).. ede/duply.net

On 26.06.2018 21:10, Kenneth Loafman wrote:

> Reading through the docs, it wants to execute duplicity during the autocomplete to get the options, and leave no side effects.  That could be problematic.
>
> ...Ken
>
>
> On Tue, Jun 26, 2018 at 7:54 AM edgar.soldin--- via Duplicity-talk <[hidden email] <mailto:[hidden email]>> wrote:
>
>     On 26.06.2018 14:49, Aaron wrote:
>     > Without digging into the detail, this:
>     > http://argcomplete.readthedocs.io/en/latest/
>     > apparently automatically collects options for bash completion from argparse, which feels like a sensible approach.
>     >
>     > Moving from Optparse to Argparse is on the roadmap already anyway:
>     > https://bugs.launchpad.net/duplicity/+bug/1480565
>
>
>     agreed, this approach looks much cleaner than a manually maintained list of options.. ede/duply.net <http://duply.net>
>
>     _______________________________________________
>     Duplicity-talk mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk

[duplicity-talk mailing list]

btw. i've contacted the author of the script. reply:
https://twitter.com/mikeyneuling/status/1011917702057766912

j

On Wed, 27 Jun 2018, edgar.soldin--- via Duplicity-talk wrote:

> yeah,
>
> would have to be implemented cleanly of course. see no disadvantage though in having command line parameters parsed earliest.
>
> but it's all rhetorical anyway as long as nobody implements argparse first ;).. ede/duply.net
>
> On 26.06.2018 21:10, Kenneth Loafman wrote:
>> Reading through the docs, it wants to execute duplicity during the autocomplete to get the options, and leave no side effects.  That could be problematic.
>>
>> ...Ken
>>
>>
>> On Tue, Jun 26, 2018 at 7:54 AM edgar.soldin--- via Duplicity-talk <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>     On 26.06.2018 14:49, Aaron wrote:
>>     > Without digging into the detail, this:
>>     > http://argcomplete.readthedocs.io/en/latest/
>>     > apparently automatically collects options for bash completion from argparse, which feels like a sensible approach.
>>     >
>>     > Moving from Optparse to Argparse is on the roadmap already anyway:
>>     > https://bugs.launchpad.net/duplicity/+bug/1480565
>>
>>
>>     agreed, this approach looks much cleaner than a manually maintained list of options.. ede/duply.net <http://duply.net>
>>
>>     _______________________________________________
>>     Duplicity-talk mailing list
>>     [hidden email] <mailto:[hidden email]>
>>     https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>>
>
>
> _______________________________________________
> Duplicity-talk mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/duplicity-talk

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk

[duplicity-talk mailing list]

We're under GPL v2, so yes, please stick a header on it.

Guess I don't make a good detective.  😊  Ah well.

...Ken

  

On Fri, Jun 29, 2018 at 8:27 AM Jose Riha <[hidden email]> wrote:

btw. i've contacted the author of the script. reply:
https://twitter.com/mikeyneuling/status/1011917702057766912

j

On Wed, 27 Jun 2018, edgar.soldin--- via Duplicity-talk wrote:

> yeah,
>
> would have to be implemented cleanly of course. see no disadvantage though in having command line parameters parsed earliest.
>
> but it's all rhetorical anyway as long as nobody implements argparse first ;).. ede/duply.net
>
> On 26.06.2018 21:10, Kenneth Loafman wrote:
>> Reading through the docs, it wants to execute duplicity during the autocomplete to get the options, and leave no side effects.  That could be problematic.
>>
>> ...Ken
>>
>>
>> On Tue, Jun 26, 2018 at 7:54 AM edgar.soldin--- via Duplicity-talk <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>     On 26.06.2018 14:49, Aaron wrote:
>>     > Without digging into the detail, this:
>>     > http://argcomplete.readthedocs.io/en/latest/
>>     > apparently automatically collects options for bash completion from argparse, which feels like a sensible approach.
>>     >
>>     > Moving from Optparse to Argparse is on the roadmap already anyway:
>>     > https://bugs.launchpad.net/duplicity/+bug/1480565
>>
>>
>>     agreed, this approach looks much cleaner than a manually maintained list of options.. ede/duply.net <http://duply.net>
>>
>>     _______________________________________________
>>     Duplicity-talk mailing list
>>     [hidden email] <mailto:[hidden email]>
>>     https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>>
>
>
> _______________________________________________
> Duplicity-talk mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/duplicity-talk

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk

[duplicity-talk mailing list]

hello,

gpl header is now added to the file. regarding the first point.. i compiled bash3 3.2.48 released in 2009 and ran the following test:

cur="-foo"; [[ "$cur" == -* ]] && echo bar

ran fine and so did its legacy version:

cur="-foo"; if echo "$cur" | grep -q "^-"; then echo bar ; fi

the latest bash2 release is from 2002 and probably full of security bugs so i wonder whether we really want to be that much backward compatible.

btw zsh (as shell of my choice) completion file would be greatly appreciated as well :-)

kind regards,

jose

On Fri, Jun 29, 2018 at 4:15 PM, Kenneth Loafman <[hidden email]> wrote:

We're under GPL v2, so yes, please stick a header on it.

Guess I don't make a good detective.  😊  Ah well.

...Ken

  

On Fri, Jun 29, 2018 at 8:27 AM Jose Riha <[hidden email]> wrote:

btw. i've contacted the author of the script. reply:
https://twitter.com/mikeyneuling/status/1011917702057766912

j

On Wed, 27 Jun 2018, edgar.soldin--- via Duplicity-talk wrote:

> yeah,
>
> would have to be implemented cleanly of course. see no disadvantage though in having command line parameters parsed earliest.
>
> but it's all rhetorical anyway as long as nobody implements argparse first ;).. ede/duply.net
>
> On 26.06.2018 21:10, Kenneth Loafman wrote:
>> Reading through the docs, it wants to execute duplicity during the autocomplete to get the options, and leave no side effects.  That could be problematic.
>>
>> ...Ken
>>
>>
>> On Tue, Jun 26, 2018 at 7:54 AM edgar.soldin--- via Duplicity-talk <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>     On 26.06.2018 14:49, Aaron wrote:
>>     > Without digging into the detail, this:
>>     > http://argcomplete.readthedocs.io/en/latest/
>>     > apparently automatically collects options for bash completion from argparse, which feels like a sensible approach.
>>     >
>>     > Moving from Optparse to Argparse is on the roadmap already anyway:
>>     > https://bugs.launchpad.net/duplicity/+bug/1480565
>>
>>
>>     agreed, this approach looks much cleaner than a manually maintained list of options.. ede/duply.net <http://duply.net>
>>
>>     _______________________________________________
>>     Duplicity-talk mailing list
>>     [hidden email] <mailto:[hidden email]>
>>     https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>>
>
>
> _______________________________________________
> Duplicity-talk mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/duplicity-talk

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk

[duplicity-talk mailing list]

On 7/1/2018 21:43, Jozef Riha wrote:
> hello,
>
> gpl header is now added to the file. regarding the first point.. i compiled bash3 3.2.48 released in 2009 and ran the following test:
>
> cur="-foo"; [[ "$cur" == -* ]] && echo bar
>
> ran fine and so did its legacy version:
>
> cur="-foo"; if echo "$cur" | grep -q "^-"; then echo bar ; fi

yeah regex extended test [[ came w/ bash3

> the latest bash2 release is from 2002 and probably full of security bugs so i wonder whether we really want to be that much backward compatible.

let's try if possible. i'd say that case worked with globbing at that time already. so why not do it like

cur="-foo"; case "$cur" in -*) echo bar ;; esac

?

> btw zsh (as shell of my choice) completion file would be greatly appreciated as well :-)

better than noting i suppose, so no objections here.. ede/duply.net
 

> kind regards,
>
> jose
>
> On Fri, Jun 29, 2018 at 4:15 PM, Kenneth Loafman <[hidden email] <mailto:[hidden email]>> wrote:
>
>     We're under GPL v2, so yes, please stick a header on it.
>
>     Guess I don't make a good detective.  😊  Ah well.
>
>     ...Ken
>       
>
>     On Fri, Jun 29, 2018 at 8:27 AM Jose Riha <[hidden email] <mailto:[hidden email]>> wrote:
>
>         btw. i've contacted the author of the script. reply:
>         https://twitter.com/mikeyneuling/status/1011917702057766912 <https://twitter.com/mikeyneuling/status/1011917702057766912>
>
>         j
>
>         On Wed, 27 Jun 2018, edgar.soldin--- via Duplicity-talk wrote:
>
>         > yeah,
>         >
>         > would have to be implemented cleanly of course. see no disadvantage though in having command line parameters parsed earliest.
>         >
>         > but it's all rhetorical anyway as long as nobody implements argparse first ;).. ede/duply.net <http://duply.net>
>         >
>         > On 26.06.2018 21:10, Kenneth Loafman wrote:
>         >> Reading through the docs, it wants to execute duplicity during the autocomplete to get the options, and leave no side effects.  That could be problematic.
>         >>
>         >> ...Ken
>         >>
>         >>
>         >> On Tue, Jun 26, 2018 at 7:54 AM edgar.soldin--- via Duplicity-talk <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>         >>
>         >>     On 26.06.2018 14:49, Aaron wrote:
>         >>     > Without digging into the detail, this:
>         >>     > http://argcomplete.readthedocs.io/en/latest/ <http://argcomplete.readthedocs.io/en/latest/>
>         >>     > apparently automatically collects options for bash completion from argparse, which feels like a sensible approach.
>         >>     >
>         >>     > Moving from Optparse to Argparse is on the roadmap already anyway:
>         >>     > https://bugs.launchpad.net/duplicity/+bug/1480565 <https://bugs.launchpad.net/duplicity/+bug/1480565>
>         >>
>         >>
>         >>     agreed, this approach looks much cleaner than a manually maintained list of options.. ede/duply.net <http://duply.net> <http://duply.net>
>         >>
>         >>     _______________________________________________
>         >>     Duplicity-talk mailing list
>         >>     [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>         >>     https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk>
>         >>
>         >
>         >
>         > _______________________________________________
>         > Duplicity-talk mailing list
>         > [hidden email] <mailto:[hidden email]>
>         > https://lists.nongnu.org/mailman/listinfo/duplicity-talk <https://lists.nongnu.org/mailman/listinfo/duplicity-talk>
>
>
>

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk

[duplicity-talk mailing list]

On Sun, 1 Jul 2018, [hidden email] wrote:

> On 7/1/2018 21:43, Jozef Riha wrote:
>
> let's try if possible. i'd say that case worked with globbing at that time already. so why not do it like
>
> cur="-foo"; case "$cur" in -*) echo bar ;; esac
>
> ?

agree, it looks even better. j

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk