On December 1, 2014 9:11:13 PM CET, Noah Meyerhans wrote:
>On Mon, Dec 01, 2014 at 09:43:09AM +0100, JK4 wrote:
>>
>> Where should the files be on Debian Squeeze?
>>
>> # find /usr -name parser.pm
>>
>> # :(
>
>Note that the fix for this problem was recently uploaded to the
>pr
On Mon, Dec 01, 2014 at 09:43:09AM +0100, JK4 wrote:
>
> Where should the files be on Debian Squeeze?
>
> # find /usr -name parser.pm
>
> # :(
Note that the fix for this problem was recently uploaded to the
proposed-updates[1] repo for squeeze. It'll be included in the next
squee
Thanks I had not noticed the P.
Soph.
On December 1, 2014 6:15:12 PM CET, John Hardin wrote:
>On Mon, 1 Dec 2014, Ted Mittelstaedt wrote:
>
>> That would be Parser.pm I think Find is case-sensitive.
>
>*nix is case-sensitive, so find is case-sensitive unless told otherwise
>
>using -iname.
>
>>
On 12/1/2014 10:55 AM, Bob Proulx wrote:
Ted Mittelstaedt wrote:
Locate will not show files that a user has set private (or root
has set private like /usr/local/certs/machineprivatekey.key
There are at least three versions of locate all with different
behavior with regards to file permission
Ted Mittelstaedt wrote:
> Locate will not show files that a user has set private (or root
> has set private like /usr/local/certs/machineprivatekey.key
There are at least three versions of locate all with different
behavior with regards to file permissions. The GNU findutils locate
version simply
On 12/1/2014 8:57 AM, David F. Skoll wrote:
On Mon, 01 Dec 2014 08:51:26 -0800
Ted Mittelstaedt wrote:
Locate will not show files that a user has set private (or root
has set private like /usr/local/certs/machineprivatekey.key
On my system, updatedb lets you set a flag to permit that
(the
On Mon, 1 Dec 2014, Ted Mittelstaedt wrote:
That would be Parser.pm I think Find is case-sensitive.
*nix is case-sensitive, so find is case-sensitive unless told otherwise
using -iname.
I generally do this a few times a year:
cd /
find . -print > somename.txt
That puts an entire listing
Hi,
On Mon, Dec 1, 2014 at 11:57 AM, David F. Skoll wrote:
> On Mon, 01 Dec 2014 08:51:26 -0800
> Ted Mittelstaedt wrote:
>
>> Locate will not show files that a user has set private (or root
>> has set private like /usr/local/certs/machineprivatekey.key
>
> On my system, updatedb lets you set a
On Mon, 01 Dec 2014 08:51:26 -0800
Ted Mittelstaedt wrote:
> Locate will not show files that a user has set private (or root
> has set private like /usr/local/certs/machineprivatekey.key
On my system, updatedb lets you set a flag to permit that
(the "--require-visibility no" option.)
Regards,
Locate will not show files that a user has set private (or root
has set private like /usr/local/certs/machineprivatekey.key
It would have likely worked for this - but it's too difficult for
me to attempt to prove a negative (prove a file does not exist) when I'm
using a tool that is written to
On Mon, 01 Dec 2014 08:16:22 -0800
Ted Mittelstaedt wrote:
> I generally do this a few times a year:
> cd /
> find . -print > somename.txt
> That puts an entire listing of filenames in a file in
> the root dir. Then if I'm looking for something I can
> just grep in that file.
Why not just use
That would be Parser.pm I think Find is case-sensitive.
I generally do this a few times a year:
cd /
find . -print > somename.txt
That puts an entire listing of filenames in a file in
the root dir. Then if I'm looking for something I can
just grep in that file.
Ted
On 12/1/2014 12:43 AM, JK
Hi,
Where should the files be on Debian Squeeze?
# find /usr -name parser.pm
# :(
Thanks, So.
---
"When someone shows you who they are believe them; the first time."
― Maya Angelou
On 2014-12-01 4:15, ricky gutierrez wrote:
> Work for centos 6?
> On Sunday, November 30, 2014, T
Work for centos 6?
On Sunday, November 30, 2014, Ted Mittelstaedt wrote:
> If you have 3.4 then:
>
> Fetch the patches with the commands:
>
> wget "http://svn.apache.org/viewvc/spamassassin/trunk/lib/Mail/
> SpamAssassin/Conf/Parser.pm?r1=1642207&r2=1642206&pathrev=
> 1642207&view=patch" -O pars
If you have 3.4 then:
Fetch the patches with the commands:
wget
"http://svn.apache.org/viewvc/spamassassin/trunk/lib/Mail/SpamAssassin/Conf/Parser.pm?r1=1642207&r2=1642206&pathrev=1642207&view=patch";
-O parser.pm.patch
wget
"http://svn.apache.org/viewvc/spamassassin/trunk/lib/Mail/SpamAssa
Or simple make a local backport from
http://svn.apache.org/viewvc?view=revision&revision=1642207
Or use trunc sa
On 30. nov. 2014 13.04.43 "A. Schulze" wrote:
The file 72_active.cf from update_spamassasin_org contain some
lines "if perl_version >= 5.001000
I simply removed these lines/if st
Benny Pedersen:
Upgrade to sa 3.4 where this work, else wait for next rule update,
this is a work in progress thats only gives error when not using sa
3.4
At least here I *have* 3.4 but got the same warnings.
The file 72_active.cf from update_spamassasin_org contain some
lines "if perl_ve
17 matches
Mail list logo
