[pass] Stripping .gpg not working

[Hugo Osvaldo Barrera]

On 2015-02-27 12:11, Lenz Weber wrote:
> Hi,
> 
> I've done some digging.
> 
> GNU sed allows use of the switch -E since version 4.2 with the code comment
>  /* Undocumented, for compatibility with BSD sed.  */
> (it's not even mentioned in the Changelog)
> 
> As this version has been around since April 2009, most distributions
> should have picked up on this.
> 
> So, if we get positive feedback from Jaakko, what should the course of
> action be?
> 
> * go with the -E option for both versions of sed
> * distinguish GNU sed from BSD sed and apply -r or -E accordingly
> * replace the current sed comand with two sed commands, something like
> tree -C -l --noreport "$PREFIX/$path" | tail -n +2 \
> | sed 's/\.gpg\(\x1B\[[0-9]\+m\)\{0,1\} ->/\1/' \
> | sed 's/\.gpg\(\x1B\[[0-9]\+m\)\{0,1\}$/\1/'
> 
> 
> While the first option would make the most readable regex and require
> only one call to sed, the last option should be the most hassle-free and
> compatible, but with the most ugly regex (especially having to use
> '\{0,1\}' instead of '?' sickens me).
> 
> Are there any opinions on this?
> 
> Regards,
> Lenz
> 

I'm not sure about OS, but BSD's (particularly, OpenBSD's) sed supports -r:

     -r      An alias for -E, for compatibility with GNU sed.

Maybe an OS X user can confirm if the same applies to OS X or not?

> On 26.02.2015 19:07, Lenz Weber wrote:
> > Hi again,
> > I might have found a solution.
> > 
> > I just looked at the man pages for sed on FreeBSD (which I believe is
> > closer to OSX) and it indeed seems to have a different kind of regular
> > expression, that by default does not support | (OR)
> > 
> > So it has to be called with -E for extended regex
> > The Regex needs a quick rewrite after that (see last paragraph of the
> > Description section on
> > http://www.freebsd.org/cgi/man.cgi?query=re_format&sektion=7&apropos=0&manpath=FreeBSD+10.1-RELEASE)
> > basically it's \(->(, \)->), \{->{, \}->}, {0,1} can be written as ? -
> > it handles escaping differently.
> > 
> > 
> > So finally it should look like this:
> > 
> > tree -C -l --noreport "$PREFIX/$path" | tail -n +2 | sed -E
> > 's/\.gpg(\x1B\[[0-9]+m)?( ->|$)/\1\2/g'
> > 
> > I just tested it with cygwin's sed, using the -r flag and from the
> > Cygwin (which uses the FSF sed I believe most Linuxes use, too) side,
> > this seems to work.
> > 
> > If the above command works with your Mac, too, we just need to
> > differentiate between the versions of sed and switch between the -E and
> > -r switch.
> > 
> > Regards,
> > Lenz
> > 
> > PS: another way would be to avoid the | altogether but I don't really
> > see how to do that if we don't want to create a mega-regex or execute
> > sed twice with slightly different regexes
> > 
> > 
> > Am Thu, 26 Feb 2015 18:48:58 +0100
> > schrieb Lenz Weber <mail at lenzw.de>:
> > 
> >> Hi,
> >> just for reference - we already did some testing, so stuff like
> >> looking for hidden (color) characters was already done - we could find
> >> nothing alike, at least not in the line that's not parsing.
> >>
> >> Here's what we did so far: https://github.com/jvenant/passff/issues/56
> >>
> >> I personally suspect that OSX has a slightly different version of sed
> >> that maybe doesn't honor the "/g" flag or does not like $ in a regex
> >> OR statement, but not being a mac user myself I can neither confirm
> >> nor work around that.
> >> Are there any Mac users out there that can shred some light on this?
> >>
> >> Regards,
> >> Lenz
> >>
> >> Am Thu, 26 Feb 2015 16:03:43 +0200
> >> schrieb Jaakko Rinta-Filppula <jaakko.rf at gmail.com>:
> >>
> >>> Hi!
> >>>
> >>> I’m new here. I joined because I stumbled on problem when setting up
> >>> pass with passff Firefox extension. On my system (OS X 10.9.5) the
> >>> output of pass still contains .gpg extension on the passwords
> >>> stored.
> >>>
> >>> I did a bit of digging around and found out that the tree output
> >>> parsing before this commit
> >>> http://git.zx2c4.com/password-store/commit/src/password-store.sh?id=5f3e0b36af40c1fc5991fce76e9998313d36c6ee
> >>> worked fine but the current one doesn’t.
> >>>
> >>> Here’s what I get when running that line in my terminal:
> >>> tree -C -l --noreport .password-store | tail -n +2 | sed
> >>> 's/\.gpg\(\x1B\[[0-9]\+m\)\{0,1\}\( ->\|$\)/\1\2/g' └── www
> >>>     └── facebook.com.gpg
> >>>
> >>> Any ideas what could cause this?
> >>>
> >>> – Jaakko
> >>
> >> _______________________________________________
> >> Password-Store mailing list
> >> Password-Store at lists.zx2c4.com
> >> http://lists.zx2c4.com/mailman/listinfo/password-store
> > 
> > _______________________________________________
> > Password-Store mailing list
> > Password-Store at lists.zx2c4.com
> > http://lists.zx2c4.com/mailman/listinfo/password-store
> > 
> _______________________________________________
> Password-Store mailing list
> Password-Store at lists.zx2c4.com
> http://lists.zx2c4.com/mailman/listinfo/password-store

-- 
Hugo Osvaldo Barrera
A: Because we read from top to bottom, left to right.
Q: Why should I start my reply below the quoted text?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/password-store/attachments/20150227/3a480c48/attachment.asc>