Fraudulent eBay listing

I don't know why he nymshifts constantly, but considering that *all* his nyms follow the pattern Ignoramus[0-9]*, it can't be all *that* effective at evading kill-filters.

Meanwhile, you oughta look into fixing your own malformed sig.

Reply to
Doug Miller
Loading thread data ...

Mine's fixed, thanks. I very seldom use a sigfile.

If he'd insert a space between his name and the number, or not put the number in the munged email address *and* the name, one could killfile him. But I'm not going to set up 99,999 rules in my killfile, to handle just one person who's playing a game with everyone. I normally just have him on automatic ignore.

Kris

Reply to
Kris Baker

It can be done anyway.

You don't have to. In most newsreaders, one filter will get all of them: Ignoramus[0-9]*

Reply to
Doug Miller

Given Iggy's past patterns, and your filter above, Ignoramus[1-9]* would suffice. ;-)

But... if a newsreader can use wildcards/regex, why bother with the numeric aspect at all? Just filter on (depending on what regex you're using, and what exactly you want to filter) one of these, Ignoramus* Ingormaus.+ Ignoramus.*

Reply to
Steve Ackman

I think that just Ignoramus* should succeed, I do not think that I would ever post with a mis-spelling of this word, if I do so, let me know.

i
Reply to
Ignoramus5268

According to Steve Ackman :

Hmm ... more like:

Ignoramus[1-9][0-9]*

if you are using true REs (Regular Expressions), because only the first digit is never zero. (Because it is apparently the PID of his newsreader at that time -- a one to five digit number with no leading zeros.) The RE which you used would miss ones with zero appearing in following digits. But there is no harm in using the original:

Ignoramus[0-9]*

it would simply match some strings which were never used, but it would use quite a bit fewer CPU cycles over time. :-)

Yes, those would work too, except perhaps the first of that three. (Unless your RE implementation is different from the unix ones.) Oh yes -- the second one (as shown) would fail, too , because you have transposed two characters in the constant part of the string.

Enjoy, DoN.

Reply to
DoN. Nichols

It is actually the PID of the cron job that runs at night.

i
Reply to
Ignoramus5268

So you run a cron job every night to change your news client configuration.

Why?

Reply to
Doug Miller

$ grep "^From: Ignoramus[1-9]*" * | wc -l 1633

The results are identical:

$ grep "^From: Ignoramus[1-9][0-9]*" * | wc -l 1633

Why filter on extraneous characters? Filter just as many as are required. Probably Ignor* would do it just as well.

$ grep "^From: Ignor*" * | wc -l 1633

Of course the first works. Why would you think it wouldn't? (These are done on FreeBSD, but grep is fairly standard across all the unices)

$ grep "^From: Ignoramus*" * | wc -l 1633

$ grep "^From: Ignoramus.+" * | wc -l 0 duh... this is looking for Ingoramuss(s)(s)(s)...

$ grep "^From: Ignoramus.*" * | wc -l 1633

Bottom line: TMTOWTDI... but why make your filter more complex than it needs to be? EVEN filtering "Ig" would do it, but then you risk some day filtering a new participant named Ignatius or Igor...

$ grep "^From: Ig.*" * | wc -l 1633

Reply to
Steve Ackman

I would suggest to filter by ignoramus[0-9]*, just to be as narrow as possible.

i
Reply to
Ignoramus17716

According to Steve Ackman :

[ ... ]

O.K. I had not noticed that you were using plain grep, instead of egrep. Plain grep does not use true REs. In plain grep, '*' simply stands for "any number of any character", while in true REs (including in egrep), * simply stands for "zero or more of the preceding character", so you would need ".*" (. being "any character", and ".*" matches any number of any character.

I expected you to be using REs built into the newsreader in a killfile, not plain grep for filtering. After all, the purpose is to filter him out of usenet articles presented by your newsreder.

Depends. With true REs, it would be "Ignoramus" plus any number of any character.

Agreed. But the digits following "Ignoramus" are a more certain identifier than just "Ignoramus".

And if so -- and it is being done with something using true REs instead of just plain grep, there are a number of his IDs which have zero as other than the first digit. In what is saved from the newsgroup this year, I find:

258 IDs with zeros present out of 714 total IDs. So -- your expression for grep (if you are including digits) may not work in a Killfile, unless it is based on plain grep. :-)

And -- BTW -- my newsreader saves the articles with the ':' removed from the "From: " -- in "mailbox" format, so there your pattern would not work at all. :-) But, of course, that is *after* I have read and saved articles, so that is different. (I no longer have a true news feed, so I can't simply grep the news spool. :-)

Or -- someone who has a munged e-mail address of "Ignore-this@not-my-domain". :-)

Enjoy, DoN.

Reply to
DoN. Nichols

$ man egrep GREP(1)

NAME grep, egrep, fgrep, zgrep, zegrep, zfgrep, bzgrep, bzegrep, bzfgrep - print lines matching a pattern [...] egrep is the same as grep -E. [...] -E, --extended-regexp Interpret PATTERN as an extended regular expression (see below). [...]

According to the man page, it would seem I'm the one using true (ok, "basic") regular expressions while you're using *extended* regular expressions. Nowhere can I find any reference to "true" regular expressions.

Obviously, given my .+ faux pas, they're easy enough to confuse. ;-)

It doesn't matter. If you find/filter the pattern Ignoramus or Ignoramus[0-9] or Ignoramus[1-9] all his posts are found/filtered.

Which is why I included the disclaimer about which regexp and which newsreader you use. Patterns are patterns. Syntax is syntax.

Leafnode filters use extended regular expressions while all my scripts for searching the spool use regular regular expressions.

Let's see.... $ time egrep "^From: Ignoram.*" * | wc -l 1634

real 3m12.246s user 0m0.936s sys 0m4.252s

Adapted from your earlier post: $ time egrep "^From: Ignoramus[0-9]*" * | wc -l 1634

real 4m25.169s user 0m1.115s sys 0m5.514s

You can include the extra digits if you want, but I'll take speed over excessively narrow patterns. ;-)

Right, so extending "Ig" out to "Ignoram" gets every instance of Ingoramus, and no instances of anyone else, or any other word in the dictionary. Anything beyond "Ignoram" is unnecessarily narrow and time consuming.

Reply to
Steve Ackman

According to Steve Ackman :

Hmm ... that depends on the version of unix you are using. For OpenBSD, I find the following:

====================================================================== Popocat:csu 20:27:35 # ls -li `which grep`

123705 -r-xr-xr-x 6 root bin 29776 Mar 1 2006 /usr/bin/grep Popocat:csu 20:27:50 # ls -li `which egrep` 123705 -r-xr-xr-x 6 root bin 29776 Mar 1 2006 /usr/bin/egrep Popocat:csu 20:27:54 # ls -li `which fgrep` 123705 -r-xr-xr-x 6 root bin 29776 Mar 1 2006 /usr/bin/fgrep ======================================================================

Note that all have the same inode, so they are links (three of six) to the same executable.

However, on Solaris 10 (which is what I was using):

====================================================================== Fuego:dnichols 20:24:20 > l -i `which grep` 291 -r-xr-xr-x 1 root bin 10212 Jan 22 2005 /bin/grep* Fuego:dnichols 20:24:33 > l -i `which egrep` 267 -r-xr-xr-x 1 root bin 26688 Jan 22 2005 /bin/egrep* Fuego:dnichols 20:25:56 > l -i `which fgrep` 274 -r-xr-xr-x 1 root bin 18376 Dec 16 2005 /bin/fgrep* ======================================================================

each is a separate binary -- different sizes, and all at least somewhat smaller than the smallest of the OpenBSD combined one.

And the Solaris man page for egrep shows:

====================================================================== NAME egrep - search a file for a pattern using full regular expressions ======================================================================

while the man page for grep shows:

====================================================================== NAME grep, egrep, fgrep - print lines matching a pattern

[ ... ]

There are three major variants of grep, controlled by the following options. -G Interpret pattern as a basic regular expression (see below). This is the default. -E Interpret pattern as an extended regular expression (see below). -F Interpret pattern as a list of fixed strings, separated by newlines, any of which is to be matched. In addition, two variant programs egrep and fgrep are avail- able. Egrep is similiar (but not identical) to grep -E, and is compatible with the historical Unix egrep. Fgrep is the same as grep -F. ======================================================================

So according to this, on Solaris 10, egrep is *not* the same as "grep -E".

On Solaris, I am using what Solaris calls "Full regular expressions" with egrep. With "grep -E" I would be using "extended regular expressions".

The egrep man page on Solaris continues a bit deeper down:

====================================================================== /usr/bin/egrep The /usr/bin/egrep utility accepts full regular expressions as described on the regexp(5) manual page, except for \( and \), \( and \), \{ and \}, \< and \>, and \n, and with the addition of:

  1. A full regular expression followed by + that matches one or more occurrences of the full regular expression.
  2. A full regular expression followed by ? that matches 0 or 1 occurrences of the full regular expression.
  3. Full regular expressions separated by | or by a NEWLINE that match strings that are matched by any of the expressions.

SunOS 5.10 Last change: 24 Mar 2006 1

User Commands egrep(1)

  1. A full regular expression that can be enclosed in parentheses ()for grouping.

Be careful using the characters $, *, [, ^, |, (, ), and \ in full regular expression, because they are also meaningful to the shell. It is safest to enclose the entire full regu- lar expression in single quotes ('').

The order of precedence of operators is [], then *?+, then concatenation, then | and NEWLINE. ======================================================================

And REs have changed over time. But generally, anything using the original REs would work in all of the later versions.

[ ... ]

O.K.

Again -- on Solaris (Solaris 8 on an older system, but the one on which the file being scanned resides so I avoid the overhead of NFS access):

====================================================================== stromboli:root 20:42 # time egrep "^From ignoram.*" Rec.crafts.metalworking | wc

-l 2422 egrep ^From ignoram.* Rec.crafts.metalworking 29.67s user 14.90s system 97% cpu

45.906 total wc -l 0.01s user 0.04s system 0% cpu 45.826 total ====================================================================== stromboli:root 20:43 # time egrep "^From ignoramus[0-9]*" Rec.crafts.metalworking | wc -l 2422 egrep ^From ignoramus[0-9]* Rec.crafts.metalworking 29.25s user 15.19s system 97% cpu 45.811 total wc -l 0.03s user 0.03s system 0% cpu 45.743 total ======================================================================

So this one give separate time values for each component of the pipeline, and the total time expended is not very different at all between using the more refined RE.

So there are significant tradeoffs between differing flavors of unix. For your system, there is an obvious benefit to use the shorter and less selective RE. For mine, there does not seem to be much benefit at all.

Of course, this assumes that I *want* to filter him. I don't particularly want to do so. But is is certainly proved that those who do should be able to if they take the time to figure out how their newsreader's killfile works. (At least for real newsreaders. No bets about OE. :-)

Enjoy, DoN.

Reply to
DoN. Nichols

A few posts back, I said, "(These are done on FreeBSD, but grep is fairly standard across all the unices)"

Obviously I was wrong. It doesn't happen often, but I'm happy to find out the whys and wherefores when it does. ;-)

Nor do I. Just that when stuff like this comes up, how can you stay out of the fray? ;-)

It was asked on another group whether OE can filter by number of crossposts (after I mentioned that I do so using leafnode's filters). No answer ever came, and since I've never so much as seen OE, I'm wondering if anyone here can supply the answer. If OE can do that, which sequence of clicks gets you there?

Reply to
Steve Ackman

Dunno -- but I'll point out that the number of crossposts is indicated by the number of colons in the xref: header -- so if you can filter xref: against a regular expression, it's pretty easy to filter out crossposts.

Reply to
Doug Miller

According to Steve Ackman :

We've obviously both been playing with unix for some time. My earliest system was a v7 unix on a 68000 CPU.

I just happen to have been fairly recently playing with RE work and trying to make it truly portable between flavors of unix. If you stick with one flavor, it doesn't matter -- you learn what works for your version. :-) (I'm occasionally working with someone using OS-X on the Mac, to add more flavors to the game.

Note that even *he* is offering suggestions on how to filter him. :-)

I've got no experience with that either, so I will be interested in seeing what answers come up (assuming that any OE users are still following this thread, which has turned rather unix-centric recently. :-)

Enjoy, DoN.

Reply to
DoN. Nichols

According to Doug Miller :

I don't think so. In my experience commas are used as the delimiter, as in the following:

Newsgroups: rec.crafts.metalworking,rec.puzzles,rec.woodworking

but the principle remains -- just count the commas. (Unless your newsreader is converting the commas to colons. :-)

Enjoy, DoN.

Reply to
DoN. Nichols

Notice that I referred to the xref: header, not the newsgroups: header.

The format of the xref: header is xref: : : ...

Thus, counting colons is correct when examining the xref: header.

Or counting commas when examining the newsgroups: header, where the format is newsgroups:,, ...

I've always looked at xref: instead of newsgroups: -- dunno why. Seems that either one works just as well.

Reply to
Doug Miller

According to Doug Miller :

O.K. Checking that out, I see that you are right there.

With the exception that zero commas means one newsgroup in the Newsgroups header, while *one* colon means one newsgroup in the "Xref: " header. (Excluding the ':' on the Xrefs: header itself. :-)

I guess it depends on whether you like a zero return to mean no cross-posting. :-)

And I'm not sure whether if a newsgroup in the "Newsgroups: " header is not carried by a given server, whether it would get an entry in "Xrefs: ", because there would be no article number to append. When I was running my own news server, I only took a small subset of the full list of newgroups -- and these days my T1 line would not be enough bandwidth to get even half of it all -- unless I excluded alt.* and just accepted the big eight newsgroups. :-)

Enjoy, DoN.

Reply to
DoN. Nichols

Exactly. You can put whatever groups you want in the Newsgroups: header whether they exist or not. The groups that show up in Xref: are the groups that are crossposted to, AND exist on the server where the Xref: exists.

Note the discrepancy in this post between the two headers. ;-)

Reply to
Steve Ackman

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.