[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <554B8678.6020703@mailbox.org>
Date: Thu, 07 May 2015 17:36:24 +0200
From: Frank Dittrich <frank.dittrich@...lbox.org>
To: john-dev@...ts.openwall.com
Subject: Re: Session names somename.[0-9]+ shouldn't be allowed
On 05/07/2015 05:10 PM, Solar Designer wrote:
> On Thu, May 07, 2015 at 04:58:41PM +0200, Frank Dittrich wrote:
>> On 05/07/2015 04:46 PM, Solar Designer wrote:
>>>> So, dots in the path name should be allowed.
>>
>> jtrts.pl has meanwhile been changed.
>> It uses --session=tst instead of --session=./tst now.
>> But may be john used different default paths for .rec/.log, depending on
>> JOHN_SYSTEMWIDE_EXEC. That might have been the reason to use
>> --session=./tst.
>
> Right. Does the test suite read those files back? Does it need to
> clean them up?
Currently, the test suite doesn't read back these files.
No idea whether it might be useful to parse the log file in future versions.
I think at least the log file has to be deleted, otherwise it would
consume more and more disk space, and finally exceed the max. file size
on certain systems...
If the default location moves, the test suite might need to use a
different session name, e.g. _jtrts, to make conflicts with user
sessions less likely.
>> And if the default location of .rec files can vary, depending on the
>> john version, I'd need some way to query that default location for bash
>> completion of --restore=[tab].
>
> Oh, you're right. I don't use non-default bash completions myself (to
> me, they're mostly an annoyance and a risk whenever I encounter e.g. the
> huge set of pre-specified ones on Ubuntu), but I guess some people
> appreciate them. I'm sorry, I don't seem to have a good solution for
> you. :-(
I frequently use john's bash completion.
I also use bash completion for other commands (git, make, etc.), and I
know magnum uses john's bash completion a lot.
(May be he's the only other user.)
If nothing else works, I can check the version string and implement
assumptions based on hard coded version numbers.
I already do that for incremental mode names, external mode names etc.
of core versions; for jumbo I can use --list=..
For jumbo versions, I could also parse --list=build-info output (and add
anything I might need, but may be that --list=build-info line is already
good enough:
$JOHN is ./
For core versions, I might assume JOHN_SYSTEMWIDE_EXEC if no pathname is
specified etc.
Frank
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
