[prev in list] [next in list] [prev in thread] [next in thread] 

List:       john-users
Subject:    Re: [john-users] Sequence of format registration
From:       Frank Dittrich <frank_dittrich () hotmail ! com>
Date:       2013-01-03 19:01:08
Message-ID: BLU0-SMTP1735486AD9A657F4DDF7F51FD210 () phx ! gbl
[Download RAW message or body]

On 01/03/2013 07:11 PM, magnum wrote:
> LC_ALL=C $(SED) -n 's/^struct fmt_main \([^ ]*\) =.*/john_register_one(\&\1);/p' \
> *_fmt_plug.c > fmt_registers.h 
> LC_ALL affects how sed handles 8-bit characters, but it doesn't affect sort order \
> from the globbing (cause it's not done by sed). We could fix it by piping it \
> through "LC_ALL=C sort" before the redirect to file, but this adds a dependency on \
> 'sort' (not that it should be a problem). 
> Note that this makes it sorted after format *struct* name (eg. "fmt_DMD5") but I \
> consider that a good thing. This lets us do ugly tweaks for placing things first or \
> last, without changing the source file name nor the format name to something odd. \
> If we can add a dependency on sort(1), I'd vote for this.

Now this definitely gets more on-topic for john-dev again. I should have
posted an excerpt of my previous mail to john.dev.

I also thought about adding LC_ALL=C sort before redirecting output to
fmt_registers.h and to fmt_externs.h, but wasn't sure if that sort
seque3nce could break something (it shouldn't).

May be it is indeed a good thing to sort by format struct names.
This would allow some formats which were made non-plugins because of the
sort order to become plugins again, and it would allow an easy way to
register raw-sha512 before blake2-512.
(Side note: I think it would be better if formats would use format
struct names which are derived from the format name in the same manner,
except those formats which *need* to be registered before or after some
other formats.)

Frank


[prev in list] [next in list] [prev in thread] [next in thread]