RegExp: Replacing string with array variable index

[Jon]

Hi, I've looked everywhere and tried different ways of doing this, but
came up empty.

What I want to do is replace {(\d+)} with Array[$1], but no matter how
I write it, the new string (say, {4}) either comes out as "Array[4]" OR
the script just fails.

Example:
var string = "{12}{3}";
_string = string.replace(/\{\d+)\}/g, "Array[$1]"); // newstring is now
"Array[12]Array[3]"
_string = string.replace(/\{(\d+)\}/g, Array["$1"]); // this idea just fails
_string = string.replace(/\{(\d+)\}/g, eval("Array[$1]")); // this also
fails and kills the script

I'm not advanced by any means, but I'm feeling like I should have
figured this out by now...

Any ideas?

Thanks

 

[RobG]

Hi, I've looked everywhere and tried different ways of doing this, but
came up empty.

What I want to do is replace {(\d+)} with Array[$1], but no matter how
I write it, the new string (say, {4}) either comes out as "Array[4]" OR
the script just fails.

Example:
var string = "{12}{3}";
_string = string.replace(/\{\d+)\}/g, "Array[$1]"); // newstring is now
"Array[12]Array[3]"

I don't understand what you want the output to be, can you say what
you expect?

 

[Jon]

Hi, I've looked everywhere and tried different ways of doing this, but
came up empty.

What I want to do is replace {(\d+)} with Array[$1], but no matter how
I write it, the new string (say, {4}) either comes out as "Array[4]" OR
the script just fails.

Example:
var string = "{12}{3}";
_string = string.replace(/\{\d+)\}/g, "Array[$1]"); // newstring is now
"Array[12]Array[3]"

I don't understand what you want the output to be, can you say what
you expect?

If:
Array[0] = "VAR0"
Array[1] = "VAR1"

....then I want the string of "{0}, {1}" to be produced into "VAR0, VAR1"

I hope that clarifies.

 

[RobG]

Hi, I've looked everywhere and tried different ways of doing this, but
came up empty.
What I want to do is replace {(\d+)} with Array[$1], but no matter how
I write it, the new string (say, {4}) either comes out as "Array[4]" OR
the script just fails.
Example:
var string = "{12}{3}";
_string = string.replace(/\{\d+)\}/g, "Array[$1]"); // newstring is now
"Array[12]Array[3]"

I don't understand what you want the output to be, can you say what
you expect?

If:
Array[0] = "VAR0"
Array[1] = "VAR1"

...then I want the string of "{0}, {1}" to be produced into "VAR0, VAR1"

I hope that clarifies.

Perhaps... if you had:

var a = ['VAR0','VAR1','VAR2']
var s = '{0}, {2}';

you want a string of - 'VAR0, VAR2' - correct?

There is likely some way of applying a RegExp to the string to turn it
into a new RegExp that will operate on a string representation of the
array values, however that is beyond me right now. For simplicity, a
single RegExp and for loop does the job:


function getData(a, s) {
var indexes = s.match(/\d+/g);
var result = [];

// Only proceed if got at least one match with s
if (indexes) {
for (var i=0, iLen=indexes.length; i<iLen; i++) {

// Only add to result if an element exists at the index
if (typeof a[indexes] != 'undefined') {
result.push(a[indexes]);
}
}
}
return result.join(', ');
}

alert(getData(['VAR0','VAR1','VAR2'],'{0}, {2}')); // VAR0, VAR2
alert(getData([],'{0}, {2}')); // empty string
alert(getData(['VAR0','VAR1','VAR2'],'')); // empty string

The test for undefined may not be appropriate, substitute whatever
suits. If you take the test out, you'll get an array of undefined
elements for each match in the string s, so the restult from second
test above becomes ", " which is likely not what you want.

 

[Jon Gómez]

Perhaps... if you had:

var a = ['VAR0','VAR1','VAR2']
var s = '{0}, {2}';

you want a string of - 'VAR0, VAR2' - correct?

There is likely some way of applying a RegExp to the string to turn it
into a new RegExp that will operate on a string representation of the
array values, however that is beyond me right now. For simplicity, a
single RegExp and for loop does the job:


function getData(a, s) {
var indexes = s.match(/\d+/g);
var result = [];

// Only proceed if got at least one match with s
if (indexes) {
for (var i=0, iLen=indexes.length; i<iLen; i++) {

// Only add to result if an element exists at the index
if (typeof a[indexes] != 'undefined') {
result.push(a[indexes]);
}
}
}
return result.join(', ');
}

alert(getData(['VAR0','VAR1','VAR2'],'{0}, {2}')); // VAR0, VAR2
alert(getData([],'{0}, {2}')); // empty string
alert(getData(['VAR0','VAR1','VAR2'],'')); // empty string

[...]

Neat.

One concern, though: Arbitrary numbers will be replaced:

// cold, burning, cold
alert(getData(['burning', 'cold'],'This is a 1st: {0} and {1}'));


So maybe replace the regexp with

/{\d+}/g

and to slice off the curly braces, use a modified index string:

ind = indexes.slice(1,-1);
// Only add to result if an element exists at the index
if (typeof a[ind] != 'undefined') {
result.push(a[ind]);
}


Worked for me in FF.


Yours,
a different
Jon.

 

[Jon Gómez]

Here is a more compact version of the same thing, though possibly less
efficient. I don't know how portable this is at the moment. I tested in
FF, and I verified against the EMCA 262 spec. I'll have to test it
more. I wrote it out of curiosity.


function getData(a, s) {
var r = s.replace(/{\d+}/g,
function (sub) {
i = sub.slice(1,-1);
return (a ? a : sub);
});

return r;
}

// This is a 1st: burning and cold and {3}
alert(getData(['burning', 'cold'],'This is a 1st: {0} and {1} and {3}'));



Yours,

Jon G.

 

[Thomas 'PointedEars' Lahn]

What I want to do is replace {(\d+)} with Array[$1], but no matter how
I write it, the new string (say, {4}) either comes out as "Array[4]" OR
the script just fails.

Example:
var string = "{12}{3}";
_string = string.replace(/\{\d+)\}/g, "Array[$1]"); // newstring is now
"Array[12]Array[3]"

(Don't use single-line comments for text comments; pre-comment, don't
post-comment.)

It would have been, had you used

_string = string.replace(/\{(\d+)\}/g, "Array[$1]");

_string = string.replace(/\{(\d+)\}/g, Array["$1"]); // this idea just fails

Learn to be precise on all accounts; *nothing* "just fails". Array["$1"]
accesses the property named `$1' of the object that `Array' refers to.
Since `Array' refers to the Array constructor (a Function object) which does
not have a property named `$1', the result is the `undefined' value.
However, the second argument of String.prototype.replace() must be either a
string value or a reference to a Function object. Since it is neither, it
is converted to the string represenation of `undefined' which is
"undefined". And the matches are replaced with that accordingly.

That also points out that you should not use `Array' for a variable identifier.

_string = string.replace(/\{(\d+)\}/g, eval("Array[$1]")); // this also
fails and kills the script

See above. It does nothing of the sort (in my Firefox/Iceweasel 3.0.6,
JavaScript 1.8, Firebug 1.3X.3; you have not specified your runtime
environment!). Since the eval() method of the Global Object evaluates its
argument as a Program if it is a string, the result is the same here as if
you had not used eval().

<http://www.jibbering.com/faq/faq_notes/clj_posts.html#ps1DontWork>

I'm not advanced by any means, but I'm feeling like I should have
figured this out by now...

You need to have the second argument of String.prototype.replace() to be a
reference to a Function object, and you should declare `_string':

var _string = string.replace(/\{(\d+)\}/g,
function(m, p1) {
return Array[p1];
});

RTFM:
<https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Objects/String/replace>

However, I strongly suggest a better choice of identifiers. Try to write
your code, especially choose your identifiers, concise, but so that it they
are self-explanatory, and use multi-line comments /* ... */ (in one line if
it meets 72 to 80 columns) where that is not possible. (It has been my
observation, too, that single-line comments should only be used for
disabling code while in development).


PointedEars

 

[RobG]

Perhaps... if you had:

  var a = ['VAR0','VAR1','VAR2']
  var s = '{0}, {2}';

you want a string of - 'VAR0, VAR2' - correct?

There is likely some way of applying a RegExp to the string to turn it
into a new RegExp that will operate on a string representation of the
array values, however that is beyond me right now.  For simplicity, a
single RegExp and for loop does the job:

function getData(a, s) {
  var indexes = s.match(/\d+/g);
  var result = [];

  // Only proceed if got at least one match with s
  if (indexes) {
    for (var i=0, iLen=indexes.length; i<iLen; i++) {

      // Only add to result if an element exists at the index
      if (typeof a[indexes] != 'undefined') {
        result.push(a[indexes]);
      }
    }
  }
  return result.join(', ');
}

alert(getData(['VAR0','VAR1','VAR2'],'{0}, {2}')); // VAR0, VAR2
alert(getData([],'{0}, {2}')); // empty string
alert(getData(['VAR0','VAR1','VAR2'],'')); // empty string

[...]

Neat.

One concern, though:  Arbitrary numbers will be replaced:

// cold, burning, cold
alert(getData(['burning', 'cold'],'This is a 1st: {0} and {1}'));

That's a change to requirements, file a change request...

So maybe replace the regexp with

  /{\d+}/g

and to slice off the curly braces, use a modified index string:

  ind = indexes.slice(1,-1);
  // Only add to result if an element exists at the index
  if (typeof a[ind] != 'undefined') {
      result.push(a[ind]);
  }

Worked for me in FF.

You could use replace to remove the curly braces, but why not:

function getData(a, s) {
var re = /\{(\d+)\}/g;
var result = [];
var n;

while (n = re.exec(s)) {
n = n[1];
if (typeof a[n] != 'undefined') {
result.push(a[n]);
}
}
return result.join(', ');
}

 

[Jon Gómez]

That's a change to requirements, file a change request...

The OP included the curly braces in his regexp, if that makes any
difference. Either way, you showed him a working piece of code to get
him going, so it's a minor point.

You could use replace to remove the curly braces, but why not:

function getData(a, s) {
var re = /\{(\d+)\}/g;
var result = [];
var n;

while (n = re.exec(s)) {
n = n[1];
if (typeof a[n] != 'undefined') {
result.push(a[n]);
}
}
return result.join(', ');
}

Yes, probably better, and I even tried something like that, but similar
to the OP, I was running into interesting (sadly unreproducible) crashes
retrofitting your code that way.

I think Thomas' second-arg as string is a pretty nifty solution, too.

Jon G.

 

[Dr J R Stockton]

In comp.lang.javascript message <2009041417275516807-noem@ilgov>, Tue,
14 Apr 2009 17:27:55, Jon <[email protected]> posted:

Firstly, tell your News system that it is generating malformed Message-
IDs. The Government has no right to "ilgov", only to "il.gov" etc.

Secondly, ignore Thomas Lahn; it's more comfortable.

What I want to do is replace {(\d+)} with Array[$1], but no matter how
I write it, the new string (say, {4}) either comes out as "Array[4]" OR
the script just fails.

Thirdly, untested, I think Jon G's method will fail if the array element
of the required index is an empty string. You may not care; but you
should know. Consider the value of X, Y after
var U, X, Y, A = [0, 1, 2] ; X = A[2]==U ; Y = A[3]==U
Using as he does a function will be appropriate unless you must support
a browser which cannot hahdle that.

Fourthly, better not to use "Array" as an identifier. The JavaScript
engine will not get confused, but your readers may be uncertain as to
what you think you are doing. Use for example "Arry" instead, or "Jim",
or "Fred" or local equivalent. Never use for an identifier anything
that looks too much like a JavaScript identifier or reserved word, or
like an unrelated word common in the rest of your file.

Fifthly, unless you are sure that it cannot matter, state the browser(s)
tested with.

It's a good idea to read the newsgroup c.l.j and its FAQ. See below.

 

[Jon Gómez]

Don't forget that Safari 2.x does not support function as a replacement
value in `String.prototype.replace` (as well as IE 5.5, IIRC, but Safari
2.x should be more relevant, as far as market share goes). If those
browsers are to be supported, `RegExp.prototype.exec` seems like the
best alternative.

Thanks for the warning! I still have so little knowledge of browser
incompatibilities and variations.

Jon G.
(still != OP Jon).

 

[Thomas 'PointedEars' Lahn]

In comp.lang.javascript message <2009041417275516807-noem@ilgov>, Tue,
14 Apr 2009 17:27:55, Jon <[email protected]> posted:

Firstly, tell your News system that it is generating malformed Message-
IDs. The Government has no right to "ilgov", only to "il.gov" etc.

That is true; however, pot, kettle, black. You have no right to abuse the
..invalid TLD which exists solely for documentation examples and testing, for
Message-IDs; it must be a FQDN. You have been told before.

Secondly, ignore Thomas Lahn; it's more comfortable.

Hear, hear.

Fourthly, better not to use "Array" as an identifier. [...]

Hear, hear. I didn't say exactly that?

The JavaScript engine will not get confused,

Yes, it will.

Fifthly, unless you are sure that it cannot matter, state the browser(s)
tested with.

Hear, hear. I didn't say that?


PointedEars

 

[Jon Gómez]

Thirdly, untested, I think Jon G's method will fail if the array element
of the required index is an empty string. You may not care; but you
should know. Consider the value of X, Y after
var U, X, Y, A = [0, 1, 2] ; X = A[2]==U ; Y = A[3]==U
Using as he does a function will be appropriate unless you must support
a browser which cannot [handle] that.

You're right. Thanks for pointing that out.
Jon G.

 

[Jon Gómez]

That is true; however, pot, kettle, black. You have no right to abuse the
.invalid TLD which exists solely for documentation examples and testing, for
Message-IDs; it must be a FQDN. You have been told before.

You know, this made me finally just use a real email address instead of
(e-mail address removed). However, I'm not sure it's wrong to use
".invalid". The following RFC says that ".example" is for examples,
".test" is for tests, and ".invalid" is for obviously invalid domains.

http://www.rfc-editor.org/rfc/rfc2606.txt

Hear, hear.

Too bad for the OP if he ignores PointedEars. It's better to feel
uncomfortable and make an improvement.

In the short time I've been in this group, I've watched PointedEars and
I value his presence. He can be curt and seem abrasive, but he has
always left me with the sense that he was, after all, well-intentioned.
He can also be quite patient, such as when he helped Osmo in "Re:
Default Scripting Language in Browsers".

One thing though: I totally can't find what's he hinting at half the
time he suggests a reader look at the FAQ.

Fourthly, better not to use "Array" as an identifier. [...]

Hear, hear. I didn't say exactly that?

Yep.

The JavaScript engine will not get confused,

Yes, it will.

Fifthly, unless you are sure that it cannot matter, state the browser(s)
tested with.

Hear, hear. I didn't say that?

You did say, not as firmly and in parentheses:

"It does nothing of the sort (in my Firefox/Iceweasel 3.0.6,
JavaScript 1.8, Firebug 1.3X.3; you have not specified your runtime
environment!)."

Jon G.

 

[Thomas 'PointedEars' Lahn]

You know, this made me finally just use a real email address instead of
(e-mail address removed).

Good for you that you did. (Reason includes, but is not limited to, my
killfile rule not applying then, see below.)

However, I'm not sure it's wrong to use
".invalid". The following RFC says that ".example" is for examples,
".test" is for tests, and ".invalid" is for obviously invalid domains.

http://www.rfc-editor.org/rfc/rfc2606.txt

That definition follows this:

| 2. TLDs for Testing, & Documentation Examples
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| There is a need for top level domain (TLD) names that can be used for
| creating names which, without fear of conflicts with current or
| future actual TLD names in the global DNS, can be used for private
| testing of existing DNS related code, examples in documentation, DNS
| related experimentation, invalid DNS names, or other similar uses.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
| For example, without guidance, a site might set up some local
| additional unused top level domains for testing of its local DNS code
| and configuration. Later, these TLDs might come into actual use on
| the global Internet. As a result, local attempts to reference the
| real data in these zones could be thwarted by the local test
| versions. Or test or example code might be written that accesses a
| TLD that is in use with the thought that the test code would only be
| run in a restricted testbed net or the example never actually run.
| Later, the test code could escape from the testbed or the example be
| actually coded and run on the Internet. Depending on the nature of
| the test or example, it might be best for it to be referencing a TLD
| permanently reserved for such purposes.
|
| To safely satisfy these needs, four domain names are reserved as
^^^^^^^^^^^
| listed and described below.
|
| .test
| .example
| .invalid
| .localhost

And frankly, if you actually subsume activities that prevent someone from
communicating with you in private under "Testing, & Documentation Examples"
and "similar uses", you should not be using Usenet -- the thing with the
*people*. The From and Reply-To headers exist not only for identifying the
author of the message (which is why pseudonyms and nick names only are a
rather bad idea, YMMV), but also so that topics which are not of general
interest to the subscribers of the newsgroup be discussed off-group (that
includes, but is not limited to, singular advice on how to post to get the
best answers out of the group, clarifying on-group misunderstandings before
they evolve into flame wars, notification about solutions to long time
unsolved problems, and the like.) BTDT, both as sender and receiver.

More, "obviously invalid domains" MUST NOT be used within address headers,
see RFC 1036, sections 2.1.1, 2.2.1, and 2.2.2, and RFC 2822 (that which
describes named "Internet syntax"), section 3.4.1. "A mailbox receives
mail." "(e-mail address removed)" is clearly not a mailbox.

<http://tools.ietf.org/html/rfc1036>
<http://tools.ietf.org/html/rfc2822>

(I have come to like the IETF tools better than the plain versions provided
by rfc-editor.org, because they make links out of references. Needless to
say that they are both authoritative as rfc-editor.org is but the archive of
the IETF/IESG process.)

As for the spam problem that comes with following protocol and Netiquette,
I have said it a hundred times before, too, and I am willing to repeat it
every time someone asks because the situation really has *not* changed:

"Munging" "addresses" is harmful; it is actually *helping* spammers!
Because, if no one competent listens and acts accordingly, spammers can
*keep on spamming undisturbed* because they are *not caught*, IP address
ranges are *not blacklisted*, open relays are *not closed*, and such highly
abusive users are *not banned* from the Net by their admins (there are
working abuse desks, really).

If we stick our heads in the sand like this, if we only continue this arms
race crawler vs. filter, it stands to reason that e-mail will one day cease
to be a useful communications medium -- and the spammers would have won!

I will not let that happen, and I will not do anything to support it.
Therefore, I do what I can do: Mungers are killfiled where they stand (after
an on-group hint as to their wrongdoing if the rest of their posting seems
worthwhile to reply to). While I will keep on complaining to abuse desks
and contributing to blacklists that actually *prevent* spamming in the first
place. As for myself, I have working filters to *recognize* new spammers,
to separate the jewels from the junk; such means are neither expensive to
get nor are they hard to set up these days.

One thing though: I totally can't find what's he hinting at half the
time he suggests a reader look at the FAQ.

I try to refer to the relevant section(s) of the FAQ (most of the time it
needs to be, unfortunately, <http://jibbering.com/faq/#posting>). If that
does not suffice, you should name those instances so that my FAQ references
might be improved or that the FAQ might be better structured for reference.


PointedEars

 

[Jon Gómez]

Good for you that you did. (Reason includes, but is not limited to, my
killfile rule not applying then, see below.)

If I may make fun of myself:

But I was thinking of a plan
To dye one's whiskers green,
And always use so large a fan
That it could not be seen.
-- Lewis Carroll

Yes, it's rather disabling not to provide a real email. It is even
problematic for those who would wish to respond privately, for the valid
reasons you cited below. Therefore, the omission may be potentially
seen as disabling to the newsgroup as a whole. This time around,
omission was a kind of experiment--I've always used valid emails formerly.

I'll use a valid email for now. I will continue to think about it, of
course. Considering the matter introspectively, I think I acted out of
a sense of privacy, perhaps somewhat as a logical effort of regulating
disclosure, but maybe more out of my emotional sense of comfort in
sharing something I identified with myself. That is, it seemed to me
that my email was personal.

In using an invalid email address, my intention at the time was to
express that I could not or chose not to provide an email for personal
communication. Thereafter, you could do what you wanted with the
information, including killfile me. As a means of communicating, it was
apparently a good choice. I respect other's right to chose how to
respond to the situation: Otherwise, why else would I use an obviously
invalid email?

That definition follows this:

| 2. TLDs for Testing, & Documentation Examples
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| There is a need for top level domain (TLD) names that can be used for
| creating names which, without fear of conflicts with current or
| future actual TLD names in the global DNS, can be used for private
| testing of existing DNS related code, examples in documentation, DNS
| related experimentation, invalid DNS names, or other similar uses.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[...]


Well, I guess you're right, looking over it again. The section title
does limit the scope. Nonetheless, the effect is to reserve a
collection of addresses that on sight are invalid or for specialized
use. I therefore see an opportunity to expand on the standard by a
broader use of those domains in other contexts. A potential
conflict--yes--but a means of communicating. I guess the point really
is that it was supposed to be WRONG to use them in the way I intended.

And frankly, if you actually subsume activities that prevent someone from
communicating with you in private under "Testing, & Documentation Examples"
and "similar uses", you should not be using Usenet -- the thing with the
*people*. The From and Reply-To headers exist not only for identifying the
author of the message (which is why pseudonyms and nick names only are a
rather bad idea, YMMV), but also so that topics which are not of general
interest to the subscribers of the newsgroup be discussed off-group (that
includes, but is not limited to, singular advice on how to post to get the
best answers out of the group, clarifying on-group misunderstandings before
they evolve into flame wars, notification about solutions to long time
unsolved problems, and the like.) BTDT, both as sender and receiver.

Good points.

More, "obviously invalid domains" MUST NOT be used within address headers,
see RFC 1036, sections 2.1.1, 2.2.1, and 2.2.2, and RFC 2822 (that which
describes named "Internet syntax"), section 3.4.1. "A mailbox receives
mail." "(e-mail address removed)" is clearly not a mailbox.

<http://tools.ietf.org/html/rfc1036>
<http://tools.ietf.org/html/rfc2822>

I looked at the sections, I admit I should read the documents
thoroughly. I probably need to very thoroughly read the RFCs one day.
It's a wall I've hit up against: The information may be abstract, but
it's concrete enough to be arbitrary.

[...]

As for the spam problem that comes with following protocol and Netiquette,
I have said it a hundred times before, too, and I am willing to repeat it
every time someone asks because the situation really has *not* changed:

Spam is a curious kind of creature living out in the waters of the Internet.

Actually, when I was first studying Internet protocols, I really enjoyed
trying to trace and work out the headers in spam.

"Munging" "addresses" is harmful; it is actually *helping* spammers!
Because, if no one competent listens and acts accordingly, spammers can
*keep on spamming undisturbed* because they are *not caught*, IP address
ranges are *not blacklisted*, open relays are *not closed*, and such highly
abusive users are *not banned* from the Net by their admins (there are
working abuse desks, really).

I doubt people typically see it as just two alternatives of munging or
reporting. So insofar as munging introduces inconvenience (like my
using invalid addresses), that is harmful, but that harm doesn't
necessarily stack with the loss of benefit from not reporting.

I myself have notified people when I can tell that their machine has
been hacked into and used to distribute spam. I don't usually notify
when it comes from an ISP that provides an email service, though.

If we stick our heads in the sand like this, if we only continue this arms
race crawler vs. filter, it stands to reason that e-mail will one day cease
to be a useful communications medium -- and the spammers would have won!

Then a new way of communicating will be invented, right? Maybe
something better. Here's my chance at optimism.

I will not let that happen, and I will not do anything to support it.
Therefore, I do what I can do: Mungers are killfiled where they stand (after
an on-group hint as to their wrongdoing if the rest of their posting seems
worthwhile to reply to). While I will keep on complaining to abuse desks
and contributing to blacklists that actually *prevent* spamming in the first
place. As for myself, I have working filters to *recognize* new spammers,
to separate the jewels from the junk; such means are neither expensive to
get nor are they hard to set up these days.

Would you like to further explain why you use a killfile? I can
understand it as a form of protest, as an attempt to filter out those
you feel hurt newsgroups, and perhaps even as a way of artificially
modifying your interaction with newsgroups to conform to your desire to
have no munging. I can see, therefore, how it cognitively and
personally can help you, but I'm missing how it helps anyone else or
modifies others' behavior.

<http://www.interhack.net/pubs/munging-harmful/>

I read it. I didn't get much out of it, but I forced myself to read it.
The spam/terrorism analogy doesn't appeal to me.

I try to refer to the relevant section(s) of the FAQ (most of the time it
needs to be, unfortunately, <http://jibbering.com/faq/#posting>). If that
does not suffice, you should name those instances so that my FAQ references
might be improved or that the FAQ might be better structured for reference.

Okay.

Jon.

 

[Thomas 'PointedEars' Lahn]

Good for you that you did. (Reason includes, but is not limited to, my
killfile rule not applying then, see below.)

If I may make fun of myself:

But I was thinking of a plan To dye one's whiskers green, And always use
so large a fan That it could not be seen. -- Lewis Carroll


[...]
In using an invalid email address, my intention at the time was to
express that I could not or chose not to provide an email for personal
communication. Thereafter, you could do what you wanted with the
information, including killfile me.

I can still do that

As a means of communicating, it was apparently a good choice.

Without being presumptuous, I'd say that depends on whether you place
quantity over quality.

I respect other's right to chose how to respond to the situation:
Otherwise, why else would I use an obviously invalid email?

There is actually no "invalid e-mail (address)". Either it is an address
(to specify a mailbox) or it is not.

Spam is a curious kind of creature living out in the waters of the
Internet.
*g*

Actually, when I was first studying Internet protocols, I really enjoyed
trying to trace and work out the headers in spam.

Add me.

I doubt people typically see it as just two alternatives of munging or
reporting. So insofar as munging introduces inconvenience (like my using
invalid addresses),

See above.

that is harmful, but that harm doesn't necessarily
stack with the loss of benefit from not reporting.

I don't think you quite got my meaning right.

I myself have notified people when I can tell that their machine has been
hacked into and used to distribute spam.

Good man. But that is not merely some spam, of course, but something much
more harmful.

Then a new way of communicating will be invented, right? Maybe something
better. Here's my chance at optimism.

It would certainly be something very *different*, something not compatible
with Usenet as it is for sure. So your optimism hinges on the hope for a
Usenet3 to replace Usenet. Look what became of Usenet2, and you might want
to reconsider. In any case, ISTM the "better" with regard to unsolicited
messages hinges on the proof that P = NP.

Would you like to further explain why you use a killfile?

Not really here, no, because it is off-topic. My reasons for using a
killfile (which is really a kind of scorefile) are not different from
the reasons of the many other people who are using such means.

I can understand it as a form of protest, as an attempt to filter out
those you feel hurt newsgroups,

Oh no, it is much more simple. Does "sand and nuggets" ring a bell?

and perhaps even as a way of artificially modifying your interaction with
newsgroups to conform to your desire to have no munging.

I don't follow.

I can see, therefore, how it cognitively and personally can help you, but
I'm missing how it helps anyone else or modifies others' behavior.

Those who don't follow protocol and Netiquette are ignored eventually; if
they have a problem and ask for help about it, I will not see it and so they
don't get my direct advice. Since I'm reading almost every posting that
does not get filtered out or is automatically marked as read, it is possible
to determine which postings (and posters) I consider worthwhile (if I not
state the opposite explicitly). And I am not the only one.

I read it. I didn't get much out of it, but I forced myself to read it.
The spam/terrorism analogy doesn't appeal to me.

People willing to trade their freedom for temporary security deserve
neither and will lose both. -- Benjamin Franklin (paraphrased)


F'up2 poster (I'd rather continue this off-group if necessary, but if you
know a Usenet newsgroup where it is on-topic, feel free to crosspost and set
F'up2 there instead.)

PointedEars

 

[Dr J R Stockton]

If I may make fun of myself:

But I was thinking of a plan
To dye one's whiskers green,
And always use so large a fan
That it could not be seen.
-- Lewis Carroll

Yes, it's rather disabling not to provide a real email.

Those who debate such matters at length with TL are liable to be
considered troll-equivalents, and kill-filed.

Those who choose to post from gmail may be collectively treated
likewise; kill-riling all gmail substantially reduces perceived spam,
trolling, and idiocy.

Do not post as from a cherished address unless you have considered the
possible consequences and how you can deal with them.