Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 10 Sep 2012 00:31:41 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: bash completion on OSX

On 9 Sep, 2012, at 21:47 , Frank Dittrich <frank_dittrich@...mail.com> wrote:

> On 09/09/2012 07:55 PM, magnum wrote:
>> But this does not work:
>> 
>> $ john -fo:[TAB]
>> sed: 1: "p }
>> ": extra characters at the end of p command
>> 
>> Instead of bugging you with OSX quirks (although it would be nice if we eventually get it generic enough), I first tried installed gnu sed from macports but this did not fix it. Instead, it now is totally quiet. I press TAB after "-fo:" and absolutely nothing happens.
>> 
>> I tried manually running what is in the script (with gnu sed):
>> ../run/john | sed -n -e '/^--format/,$ {' -e 's#^--format=[ A-Za-z]*:##' -e '/^--/ b' -e 's#^ *##' -e 's#\<dynamic_n\>#dynamic#' -e 's#^\(.*\)$#\L\1#' -e 's#[/ ]#\n#g' -e 'p }'
>> 
>> ...and I do get the format list. I have no idea why it does not show up in completion.
> 
> Just a guess, because I can't even reproduce the problem:
> Please try s/-e 'p }'/ -e 'p' -e '}'/
> Under Linux, this still works. Hopefully it also works under OS X.

OK, first thing to notice is this time (after a reboot) gsed suddenly works fine with or without your fix. These things happen all the time on this weird OS, it's totally unpredictable. Anyway, I'm trying to get the native sed to work. With your fix, it stops complaining, but:

../run/john --format=[TAB]

expands to

../run/john --format=L

and then nothing more happens on further tabs. So let's try to see what happens:

$ ../run/john |/usr/bin/sed -n -e '/^--format/,$ {' -e 's#^--format=[ A-Za-z]*:##' -e '/^--/ b' -e 's#^ *##' -e 's#\<dynamic_n\>#dynamic#' -e 's#^\(.*\)$#\L\1#' -e 's#[/ ]#\n#g' -e 'p' -e '}'
Lafsnagilekeychain
Lagilekeychain-openclnbfnbf-openclnbfeggnbsdincrc32
Ldesndes-openclndjangondmd5ndmgndmg-openclndominosec
(...lots snipped...)

OK, so the \L is interpreted as a literal 'L', and \n as a literal 'n'. Looking at the man page for re_format (claiming POSIX.2) it does not mention \L at all, while it says that you can use \n for a newline, but only in extended RE. To use extended RE you need to supply -E to sed. We can't, because then it will fail on gsed, which uses -r for that.

Looking at gsed's man page (also claiming POSIX.2) it confirms "POSIX.2  BREs should be supported, but they aren't completely because of performance problems.  The \n sequence in a regular expression matches the newline character, and similarly for \a, \t, and other sequences". So the gsed support for \n in basic RE is not POSIX conformant. What a fargin' mess. Can't we use perl in there?

Note, though, that the following works like a charm with Apples's BSD grep as well as GNU grep (and is much simpler to boot):

$ ../run/john --list=formats | grep -Eo '[^ ,]+'

Could we possibly detect when this is possible to use, and prefer that? Personally I could not care less about legacy support.

magnum

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ