[PATCHES] improve extensions support

Tue Feb 7 23:32:06 CET 2017

When you put it like this, I have to agree. Using a different name for 
the new/changed command is not a big deal.

However, the help command showing help for the extensions is one feature 
of the patch that I would like to see added to pass.

Furthermore, what extensions are missing is completion. The current 
completion script is closed to the built-in commands. Opening this for 
the extensions like HacKan did for the help command would be an awesome 
addition.

On 07.02.2017 16:41, David Izquierdo wrote:
> Although my first thought on overriding pass commands was of
> celebration, I do think it misses the point. Once you need to overwrite
> pass itself, you might as well modify the actual script. Also, enforcing
> extensions to use their own namespace seems safer in the long run.
> Someone mentioned before the risk of a rogue facebook.com extension...
>
>
> In the end, typing `pass insert2` isn't much different from `pass
> insert`. Add in a more imaginative name, and the need for overriding the
> default insert is close to null.
>
>
> On 07/02/17 14:49, HacKan wrote:
>> Well, you can't override more than once because you can't have 2 files
>> with the same name. This allows users more freedom, they can choose to
>> use internal commands or extensions. The pass core isn't touched.
>>
>> Current extensions are not affected at all. Also, users wanting to use
>> an extension that normally overrides an internal command without doing
>> that can simply rename the extension file.
>>
>> I believe it provides more usability and alternatives without changing
>> the pass core. Those who want to use pass w/o extensions can do it;
>> those who want extensions can have them; those who want extensions that
>> override internal commands can have them too. What's wrong with giving
>> the community that?
>>
>> Cheers!
>>
>>
>> On 02/07/2017 09:57 AM, Alexandre Pujol wrote:
>>> Hi,
>>>
>>> Although the idea is interesting, I don't know if I like the concept.
>>>
>>> Pass should stay pass. This is a simple password manager that can be
>>> extended in order to provide community command. What you are proposing
>>> is to provide to the community a way to completely overwrite any command
>>> (and therefore to do what the fuck they want with pass itself). It is
>>> not an extension feature any-more, it is an offensive overwriting
>>> feature. It could have major consequences on pass itself.
>>>
>>> Moreover, from a technical point of view I see a mess coming when you
>>> will need to manage the 10th overwriting of the same core command. What
>>> about classic extension compatibility with the overwritten core command?
>>>
>>> Jason has already be kind enough to provide us the extension feature.
>>> What you are proposing seem too much for me.
>>>
>>>
>>> Anyone else in this ML has an opinion on this?
>>>
>>> Regards,
>>> Alex
>>>
>>> On 06/02/17 16:40, HacKan wrote:
>>>> Hello there! I spent the last few days playing around with pass, so I
>>>> forked it [1] and changed the way it handles extensions, because I
>>>> wanted to allow extensions to override internal commands. I.E. if
>>>> someone wants to modify the way /generate/ works, there's no need to
>>>> touch pass's core but simply create an extension named /generate.bash
>>>> /and that's all/./
>>>>
>>>> Here's the rough changes list:
>>>>
>>>>    * Modified the way commands are interpreted in the script: replaced
>>>>      the switch case selection to a more flexible eval'd one.
>>>>    * Changed how extensions are handled: now extensions are loaded
>>>> first,
>>>>      before interpreting the command as an internal command. This
>>>> allows
>>>>      extensions to override internal commands. A helper function is
>>>>      provided so that an overridden function can still be called
>>>> from the
>>>>      extension.
>>>>    * Issuing help command now shows help from the extensions if they
>>>>      implement a function named help_{extension name}(). Otherwise, it
>>>>      will list enabled extensions as commands.
>>>>
>>>> This keeps backwards compatibility at 100%, existing extensions are too
>>>> 100% compatible. So for the final user these patches doesn't have any
>>>> effect at all.
>>>>
>>>> Patches and signed hashes are attached.
>>>>
>>>> Also, I tested these and all tests passed (attached as
>>>> /tests-result.txt/). Note that tests must be fixed first (see /[PATCH]
>>>> Fixes for tests/ [2]).
>>>>
>>>> A sample /pass --help/ output with a couple of extensions I made is
>>>> attached (/help-example.txt/).
>>>>
>>>> Attachment list:
>>>> 0001-Changed-function-switch-based-on-parameters-by-a-mor.patch
>>>> 0002-Added-helper-override_function-to-enable-extensions-.patch
>>>> 0003-Modified-cmd_usage-to-show-extensions-usage-help-too.patch
>>>> 0004-Minor-bugfixes-in-cmd_usage-when-showing-extensions-.patch
>>>> 0005-Fixed-multiname-functions-parameters-were-not-being-.patch
>>>> 0006-Small-bugfix-in-usage-command.-Also-changed-spaces-f.patch
>>>> SHA512SUMS
>>>> SHA512SUMS.sig
>>>> help-example.txt
>>>> tests-result.txt
>>>>
>>>> Cheers!
>>>>
>>>> [1]: https://github.com/HacKanCuBa/passh
>>>> [2]:
>>>> https://lists.zx2c4.com/pipermail/password-store/2017-February/002727.html
>>>>
>>>>
>>>> --
>>>> HacKan || Iván
>>>> GPG: 0x35710D312FDE468B
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Password-Store mailing list
>>>> Password-Store at lists.zx2c4.com
>>>> https://lists.zx2c4.com/mailman/listinfo/password-store
>>>>
>>> _______________________________________________
>>> Password-Store mailing list
>>> Password-Store at lists.zx2c4.com
>>> https://lists.zx2c4.com/mailman/listinfo/password-store
>
> _______________________________________________
> Password-Store mailing list
> Password-Store at lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/password-store