[9818] in Perl-Users-Digest
Perl-Users Digest, Issue: 3411 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Aug 10 23:07:23 1998
Date: Mon, 10 Aug 98 20:00:18 -0700
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 10 Aug 1998 Volume: 8 Number: 3411
Today's topics:
Re: "newgrp" in a Perl script (Joseph Bell)
cat while file open w/ Win32 Perl <REPLY_TO_lastronin@earthlink.net>
Date and Time <temery@crocker.com>
Defining Your Own Functions (monty hindman)
Re: Defining Your Own Functions (Craig Berry)
Re: having trouble with printing array to html <REPLY_TO_lastronin@earthlink.net>
Re: How to untaint a directory path? (Mark-Jason Dominus)
IMPORTANT: Proper Netiquette <tchrist@mox.perl.com>
Special: Digest Administrivia (Last modified: 12 Mar 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 11 Aug 1998 01:03:58 GMT
From: jobell@bnr.ca (Joseph Bell)
Subject: Re: "newgrp" in a Perl script
Message-Id: <6qo59u$leu@crchh14.us.nortel.com>
In article <Pine.GSO.4.02.9808101736470.10161-100000@user2.teleport.com>,
Tom Phoenix <rootbeer@teleport.com> wrote:
>On 10 Aug 1998, Joseph Bell wrote:
>
>> i know this has been answered before, but i can't find it anywhere on
>> the web.
>
>Well, the perl manpages are on the web... :-)
:-) yeah, i can read the man pages, and I have the Perl 5 book, but here
is what I get from a simple script:
print $(."\n";
print $)."\n";
276 276
276 276
i try (i dunno if this is supposed to work):
$) = 266;
print $)."\n";
276 276
nothing changes...
JB
>
>> i would like to be able to change my effective user and group ids
>> during the execution of my perl script. how can I do this?
>
>Look for $( and $) in the perlvar manpage. Hope this helps!
>
>--
>Tom Phoenix Perl Training and Hacking Esperanto
>Randal Schwartz Case: http://www.rahul.net/jeffrey/ovs/
>
--
Joseph A. Bell (NOT Cindy Wierschem) jobell@nortel.com
Northern Telecom Wireless Technologies
GSM MSC Tools Development
No funny quotes here.
------------------------------
Date: Mon, 10 Aug 1998 21:41:07 -0400
From: "Ha" <REPLY_TO_lastronin@earthlink.net>
Subject: cat while file open w/ Win32 Perl
Message-Id: <6qo6rd$hph$1@holly.prod.itd.earthlink.net>
In a script that will format Tom C's .txt perl5 docs to html, i'm having a
problem getting concatenation to work while FILEHANDLE is open. it's not a
problem with the browser or apache. it works fine on the UNIX version of
Perl 5+, but the Win32 (the guru sammy one) isn't cooperating, e.g.
open (FILE, "<$path")
|| &error_die("whoopsies: can't open doc to read: $path");
binmode(FILE);
while ($something = <FILE>)
{
$another = $something . '.html';
[do stuff here...]
}
close(FILE);
could someone please try this and tell me if you get the same problem? could
be a bug, since it happens EVERY TIME.
thanks,
ha quach
mailto:info@r-go.com
------------------------------
Date: Mon, 10 Aug 1998 22:42:00 -0100
From: Thomas Emery <temery@crocker.com>
Subject: Date and Time
Message-Id: <35CF8547.1BEEE4DF@crocker.com>
How can I show the date as month and day (no year), and the time as just
hour and minute (dropping the second)?
Tom
------------------------------
Date: Tue, 11 Aug 1998 01:11:29 GMT
From: montyh@umich.edu (monty hindman)
Subject: Defining Your Own Functions
Message-Id: <5TMz1.1310$hF4.6341265@newbabylon.rs.itd.umich.edu>
I'm quite new to Perl and to programming. I just finished a big program
and by the end, even though it all worked, I felt like I was inches away
from chaos. Hoping to make the next big project more efficient, I've
decided to learn how to make some generalized functions to perform tasks
that I find myself doing frequently.
My first attempt is fairly simple: it asks a user for a response
(sometimes offering a list of choices), checks whether the response is
valid, and returns the first valid response that it gets (or dies if too
many invalid answers are given).
I'd appreciate any comments about whether I've tackled this kind of
problem in an advisable way, or about other ways that I might want to try
it. I'd like to develop a good technique for building such functions
because there are several more that would be useful to me.
Thanks in advance for any suggestions or comments.
-- Monty Hindman
The function's argument is a reference to an anonymous hash. All
specifications are optional.
message = message asking for input.
prompt = string printed each time input is requested;
the default is `=>'.
reply = string printed if invalid input is provided.
max = number of invalid replies allowed before program dies.
validlist = reference to a list of acceptable responses.
validcode = reference to a subroutine that returns
true if its $_[0] holds a valid response.
Here's the syntax:
&UserInput( {
message => STRING ,
prompt => STRING ,
reply => STRING ,
max => INTEGER ,
validlist => REF_TO_A_LIST ,
validcode => REF_TO_A_SUB ,
} ) ;
And here's an example, followed by the function itself:
$answer = &UserInput( {
message => "How old are you?" ,
prompt => " " ,
reply => "No, really." ,
max => 5 ,
validcode => sub {
my $x = $_[0] ;
return 0 if (
$x eq "" or
$x =~ /[^\d\.]/ or
$x < 0 or
$x == 29
) ;
return 1 ;
} ,
} ) ;
sub UserInput {
my %u = %{$_[0]} if $_[0] ;
print $u{message} if $u{message} ;
if ( $u{choices} ) {
print "\n" ;
my $x = 1 ;
foreach ( @{$u{choices}} ) {
print " $x. $_\n" ;
$x ++ ;
}
}
$u{prompt} = "=> " unless $u{prompt} ;
my $x = 0 ;
my $line ;
while (1) {
$x ++ ;
die ("Too many invalid responses.\n")
if ( $u{max} and $x > $u{max} ) ;
print $u{reply} if ( $u{reply} and $x > 1 ) ;
print $u{prompt} ;
chomp ( $line = <STDIN> ) ;
if ( $u{validlist} ) {
last if grep /^$line$/, @{$u{validlist}} ;
} elsif ( $u{validcode} ) {
last if &{$u{validcode}}($line) ;
} else {
last ;
}
}
return $line ;
}
------------------------------
Date: 11 Aug 1998 01:26:14 GMT
From: cberry@cinenet.net (Craig Berry)
Subject: Re: Defining Your Own Functions
Message-Id: <6qo6jm$hfj$3@marina.cinenet.net>
monty hindman (montyh@umich.edu) wrote:
[snip statement of purpose and initial code/data format examples, sounds
like an interesting idea...]
: validcode => sub {
: my $x = $_[0] ;
: return 0 if (
: $x eq "" or
: $x =~ /[^\d\.]/ or
: $x < 0 or
: $x == 29
: ) ;
: return 1 ;
Why not write that last pair of returns more simply as the single:
return ! ($x eq '' or
$x =~ /[^\d.]/ or
$x < 0 or
$x == 29);
Or, turning the logic around for greater clarity, and eliminating the
now-unneeded null string comparison:
return ($x =~ /^[\d.]+$/ and
$x >= 0 and
$x != 29);
(There's a subtle difference if there can be a newline at the end of $x,
so be sure to chomp() it first.)
---------------------------------------------------------------------
| Craig Berry - cberry@cinenet.net
--*-- Home Page: http://www.cinenet.net/users/cberry/home.html
| Member of The HTML Writers Guild: http://www.hwg.org/
"Every man and every woman is a star."
------------------------------
Date: Mon, 10 Aug 1998 22:24:59 -0400
From: "Ha" <REPLY_TO_lastronin@earthlink.net>
Subject: Re: having trouble with printing array to html
Message-Id: <6qo9dl$m5p$1@holly.prod.itd.earthlink.net>
in addition to -w, -V, and other stuff the other gents mentioned, perhaps
these will help:
Sara Rosso wrote in message <35CF5559.5723@rsn.hp.com>...
>I am trying to convert text submitted by a form into a bulleted list.
>Since the number of bullets will vary from submission to submission, I
>decided the easiest way would be to use a textarea, and separate the
>list items by a semi-colon.
1) make sure you have something to handle your delimiter. a semicolon is
iffy. set semicolon to a variable name and use that variable instead of
literal string semicolon
$delim = ';';
>The input should go from:
>number one; number two; number 3; this is item number four
>
>to(for practical purposes, I will use a o as a bullet):
>o number one
>o number two
>o number three
>o this is item number four
>
>This is the html referencing the textarea:
><textarea name="deliverables" wrap=virtual cols=55 rows=8></textarea>
>
>This is the perl I have - no errors appear when compiled:
>
>open(pdstemp, ">/itsrc/apache/htdocs/projects/temp/$pid.html");
>print pdstemp "<ul>\n";
>@delivarray = split(/;/, $deliverables);
>foreach $line (@delivarray) {
>print pdstemp "<li>$line\n";
>}
>print pdstemp "</ul>\n";
>close pdstemp;
2) try using normal syntax for filehandle in all caps.
3) do all your array manipulation *before* you open file. that's just good
habit.
4) i'm guessing that the value part of the form's name-value pair is handled
in another subroutine that stores them in a hash. for example, if you have a
hash called %in wherein $key is the name and $in{$key} is the value and
$in{'deliverables'} will be the value for your textarea tag named
'deliverables', you'll have to a split on $in{'deliverables'} rather than
the bare $deliverables variable you have in your code example. as it is,
$deliverables is a fresh variable with an empty value.
5) but even before you do the split, i assume you have a chunck of code to
handle the textarea wrap. instead of virtual, i recommend wrap=hard. this
will keep the \r\n. you can do either a for count or an 'items' in array
foreach. here's a for. you may also want to assign the printed stuff to a
variable rather than printing it to file directly; for some reason, this is
nicer on Perl.
$in{'deliverables'} =~ s/\r\n/$delim/;
@stuff = split(/$delim/, $in{'deliverables'});
$towrite = "<ul>\n";
for $i (0 .. $#stuff)
{
$towrite .= "<li>$stuff[$i]\n";
}
$towrite .= "</ul>";
open (PDSTEMP, ">/itsrc/apache/htdocs/projects/temp/$pid.html")
|| print "no can do opening PDSTEMP";
print PDSTEMP $towrite;
close(PDSTEMP);
6) make sure your html output has the proper ending tags </body></html>,
otherwise you won't see anything from the latest output. as a long shot, if
your stuff in a table, you won't see the output if you don't close your
table tags properly.
er, post similar questions to comp.infosystems.www.authoring.cgi next time.
cheers,
ha quach
mailto:info@r-go.com
>
>When I go to view the file online, other html is there that I reference
>earlier in the perl, but there is no list. (This list is part of a
>larger on-the-fly generated html document.)
>
>Please give me any insight you have on this matter. Is there an easier
>way to do this?
>
>Thanks in advance.
>Sara Rosso
------------------------------
Date: 11 Aug 1998 01:16:16 GMT
From: mjd@plover.com (Mark-Jason Dominus)
Subject: Re: How to untaint a directory path?
Message-Id: <6qo610$9i$1@netnews.upenn.edu>
In article <6qnu63$v2j$1@nnrp1.dejanews.com>, <kevin@zippy.tnet.com> wrote:
>I'm looking for a simple way to get around a tainted problem
>with Perl.
There's a section in the `perlsec' manual page that explains how to
untaint data.
------------------------------
Date: 11 Aug 1998 02:50:13 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: IMPORTANT: Proper Netiquette
Message-Id: <6qobh5$nc7$2@csnews.cs.colorado.edu>
Those who have never read this document, should.
Date: Tue, 28 Jul 1998 08:00:09 GMT
Supersedes: <Evz288.I0w@tac.nyc.ny.us>
Expires: Fri, 28 Aug 1998 08:00:09 GMT
Message-ID: <Ewsow9.KpG@tac.nyc.ny.us>
>From: netannounce@deshaw.com (Mark Moraes)
Subject: A Primer on How to Work With the Usenet Community
Newsgroups: news.announce.newusers,news.answers
Followup-To: news.newusers.questions
Approved: netannounce@deshaw.com (Mark Moraes)
Lines: 433
Xref: csnews news.announce.newusers:3008 news.answers:137187
Archive-name: usenet/primer/part1
Original-author: chuq@apple.COM (Chuq Von Rospach)
Comment: enhanced & edited until 5/93 by spaf@cs.purdue.edu (Gene Spafford)
Last-change: 23 Sep 1996 by netannounce@deshaw.com (Mark Moraes)
Changes-posted-to: news.misc,news.answers
A Primer on How to Work With the Usenet Community
Chuq Von Rospach
*** This message describes the Usenet culture and customs that have
developed over time. Other documents in this newsgroup describe what
Usenet is and manuals or on-line help on your system should provide
detailed technical documentation. All new users should read this
message to acclimate themselves to Usenet. (Old users could read it,
too, to refresh their memories.) ***
It is the people participating in Usenet that make it worth the effort
to read and maintain; for Usenet to function properly those people must
be able to interact in productive ways. This document is intended as a
guide to using the net in ways that will be pleasant and productive for
everyone.
This document is not intended to teach you how to use Usenet.
Instead, it is a guide to using it politely, effectively and
efficiently. Communication by computer is new to almost everybody,
and there are certain aspects that can make it a frustrating
experience until you get used to them. This document should help
you avoid the worst traps.
The easiest way to learn how to use Usenet is to watch how others
use it. Start reading the news and try to figure out what people
are doing and why. After a couple of weeks you will start
understanding why certain things are done and what things shouldn't
be done. There are documents available describing the technical
details of how to use the software. These are different depending
on which programs you use to access the news. You can get copies of
these from your system administrator. If you do not know who that
person is, they can be contacted on most systems by mailing to
account "news", "usenet" or "postmaster".
Never Forget that the Person on the Other Side is Human.
Because your interaction with the network is through a computer it is easy
to forget that there are people "out there." Situations arise where
emotions erupt into a verbal free-for-all that can lead to hurt feelings.
Please remember that people all over the world are reading your words. Do
not attack people if you cannot persuade them with your presentation of
the facts. Screaming, cursing, and abusing others only serves to make
people think less of you and less willing to help you when you need it.
If you are upset at something or someone, wait until you have had a
chance to calm down and think about it. A cup of (decaf!) coffee or
a good night's sleep works wonders on your perspective. Hasty words
create more problems than they solve. Try not to say anything to
others you would not say to them in person in a room full of people.
Don't Blame System Admins for their Users' Behavior.
Sometimes, you may find it necessary to write to a system administrator
about something concerning his or her site. Maybe it is a case of the
software not working, or a control message escaped, or maybe one of the
users at that site has done something you feel requires comment. No matter
how steamed you may be, be polite to the sysadmin -- he or she may not have
any idea of what you are going to say, and may not have any part in the
incidents involved. By being civil and temperate, you are more likely to
obtain their courteous attention and assistance.
Never assume that a person is speaking for their organization.
Many people who post to Usenet do so from machines at their office or
school. Despite that, never assume that the person is speaking for the
organization that they are posting their articles from (unless the
person explicitly says so). Some people put explicit disclaimers to
this effect in their messages, but this is a good general rule. If you
find an article offensive, consider taking it up with the person
directly, or ignoring it. Learn about "kill files" in your newsreader,
and other techniques for ignoring people whose postings you find
offensive.
Be Careful What You Say About Others.
Please remember -- you read netnews; so do as many as 3,000,000 other
people. This group quite possibly includes your boss, your friend's
boss, your girl friend's brother's best friend and one of your
father's beer buddies. Information posted on the net can come back
to haunt you or the person you are talking about.
Think twice before you post personal information about yourself or
others. This applies especially strongly to groups like soc.singles
and alt.sex but even postings in groups like talk.politics.misc have
included information about the personal life of third parties that
could get them into serious trouble if it got into the wrong hands.
Be Brief.
Never say in ten words what you can say in fewer. Say it succinctly and
it will have a greater impact. Remember that the longer you make your
article, the fewer people will bother to read it.
Your Postings Reflect Upon You -- Be Proud of Them.
Most people on Usenet will know you only by what you say and how well you
say it. They may someday be your co-workers or friends. Take some time
to make sure each posting is something that will not embarrass you later.
Minimize your spelling errors and make sure that the article is easy to
read and understand. Writing is an art and to do it well requires
practice. Since much of how people judge you on the net is based on your
writing, such time is well spent.
Use Descriptive Titles.
The subject line of an article is there to enable a person with a limited
amount of time to decide whether or not to read your article. Tell people
what the article is about before they read it. A title like "Car for
Sale" to rec.autos does not help as much as "66 MG Midget for sale:
Beaverton OR." Don't expect people to read your article to find out what
it is about because many of them won't bother. Some sites truncate the
length of the subject line to 40 characters so keep your subjects short
and to the point.
Think About Your Audience.
When you post an article, think about the people you are trying to
reach. Asking UNIX(*) questions on rec.autos will not reach as many
of the people you want to reach as if you asked them on
comp.unix.questions or comp.unix.internals. Try to get the most
appropriate audience for your message, not the widest.
It is considered bad form to post both to misc.misc, soc.net-people,
or misc.wanted and to some other newsgroup. If it belongs in that
other newsgroup, it does not belong in misc.misc, soc.net-people,
or misc.wanted.
If your message is of interest to a limited geographic area (apartments,
car sales, meetings, concerts, etc...), restrict the distribution of the
message to your local area. Some areas have special newsgroups with
geographical limitations, and the recent versions of the news software
allow you to limit the distribution of material sent to world-wide
newsgroups. Check with your system administrator to see what newsgroups
are available and how to use them.
If you want to try a test of something, do not use a world-wide newsgroup!
Messages in misc.misc that say "This is a test" are likely to cause
large numbers of caustic messages to flow into your mailbox. There are
newsgroups that are local to your computer or area that should be used.
Your system administrator can tell you what they are.
Be familiar with the group you are posting to before you post! You
shouldn't post to groups you do not read, or post to groups you've
only read a few articles from -- you may not be familiar with the on-going
conventions and themes of the group. One normally does not join
a conversation by just walking up and talking. Instead, you listen
first and then join in if you have something pertinent to contribute.
Remember that the Usenet newsgroup system is designed to allow readers to
choose which messages they see, not to allow posters to choose sets of
readers to target. When choosing which newsgroup(s) to post in, ask
yourself, "Which newsgroups contain readers who would want to read my
message" rather than "Which newsgroups have readers to whom I want to
send my message?"
Be Careful with Humor and Sarcasm.
Without the voice inflections and body language of personal
communications, it is easy for a remark meant to be funny to be
misinterpreted. Subtle humor tends to get lost, so take steps to make
sure that people realize you are trying to be funny. The net has
developed a symbol called the smiley face. It looks like ":-)" and points
out sections of articles with humorous intent. No matter how broad the
humor or satire, it is safer to remind people that you are being funny.
But also be aware that quite frequently satire is posted without any
explicit indications. If an article outrages you strongly, you
should ask yourself if it just may have been unmarked satire.
Several self-proclaimed connoisseurs refuse to use smiley faces, so
take heed or you may make a temporary fool of yourself.
Only Post a Message Once.
Avoid posting messages to more than one newsgroup unless you are sure
it is appropriate. If you do post to multiple newsgroups, do not
post to each group separately. Instead, specify all the groups on a
single copy of the message. This reduces network overhead and lets
people who subscribe to more than one of those groups see the message
once instead of having to wade through each copy.
Please Rotate Messages With Questionable Content.
Certain newsgroups (such as rec.humor) have messages in them that may
be offensive to some people. To make sure that these messages are
not read unless they are explicitly requested, these messages should
be encrypted. The standard encryption method is to rotate each
letter by thirteen characters so that an "a" becomes an "n". This is
known on the network as "rot13" and when you rotate a message the
word "rot13" should be in the "Subject:" line. Most of the software
used to read Usenet articles have some way of encrypting and
decrypting messages. Your system administrator can tell you how the
software on your system works, or you can use the Unix command
tr '[a-m][n-z][A-M][N-Z]' '[n-z][a-m][N-Z][A-M]'
Don't forget the single quotes!)
Summarize What You are Following Up.
When you are following up someone's article, please summarize the parts of
the article to which you are responding. This allows readers to
appreciate your comments rather than trying to remember what the original
article said. It is also possible for your response to get to some sites
before the original article.
Summarization is best done by including appropriate quotes from the
original article. Do not include the entire article since it will
irritate the people who have already seen it. Even if you are responding
to the entire article, summarize only the major points you are discussing.
When Summarizing, Summarize!
When you request information from the network, it is common courtesy to
report your findings so that others can benefit as well. The best way of
doing this is to take all the responses that you received and edit them
into a single article that is posted to the places where you originally
posted your question. Take the time to strip headers, combine duplicate
information, and write a short summary. Try to credit the information to
the people that sent it to you, where possible.
Use Mail, Don't Post a Follow-up.
One of the biggest problems we have on the network is that when someone
asks a question, many people send out identical answers. When this
happens, dozens of identical answers pour through the net. Mail your
answer to the person and suggest that they summarize to the network. This
way the net will only see a single copy of the answers, no matter how many
people answer the question.
If you post a question, please remind people to send you the answers by
mail and at least offer to summarize them to the network.
Read All Follow-ups and Don't Repeat What Has Already Been Said.
Before you submit a follow-up to a message, read the rest of the messages
in the newsgroup to see whether someone has already said what you want to
say. If someone has, don't repeat it.
Check your return e-mail address and expect responses.
When you post an article, make sure that the return e-mail address in its
From: or Reply-To: headers is correct, since it is considered
inappropriate to post an article to which people are unable to respond by
e-mail. If you are unable to configure your software to include a valid
return address in your article header, you should include your address in
a signature at the bottom of your message.
When you post an article, you are engaging in a dialogue, and others may
choose to continue that dialogue by responding via e-mail. It is not
courteous to post if you are unwilling to receive e-mail in response.
Check the Headers When Following Up.
The news software has provisions to specify that follow-ups to an
article should go to a specific set of newsgroups -- possibly
different from the newsgroups to which the original article was
posted. Sometimes the groups chosen for follow-ups are totally
inappropriate, especially as a thread of discussion changes with
repeated postings. You should carefully check the groups and
distributions given in the header and edit them as appropriate. If
you change the groups named in the header, or if you direct
follow-ups to a particular group, say so in the body of the message
-- not everyone reads the headers of postings.
Be Careful About Copyrights and Licenses.
Before posting to Usenet or reproducing something that has been posted to
Usenet, make sure you read the accompanying posting "Copyright Myths FAQ:
10 big myths about copyright explained". At the very least, note that by
posting to Usenet, you are requesting that a copy of your document be
automatically distributed to computers all over the world and stored on
various disks for a long time (forever on some archive media).
Further, some people will quote parts of your article without permission
or forward it to other people or use it in other ways that you might not
know about. If this bothers you, put an explicit copyright notice on
your posting. On the flip side, even if you are sure of the legality of
reproducing something from or on Usenet, it would be courteous to ask for
permission before doing so.
Cite Appropriate References.
If you are using facts to support a cause, state where they came from.
Don't take someone else's ideas and use them as your own. You don't want
someone pretending that your ideas are theirs; show them the same respect.
Mark or Rotate Answers and Spoilers.
When you post something (like a movie review that discusses a detail of
the plot) which might spoil a surprise for other people, please mark your
message with a warning so that they can skip the message. Another
alternative would be to use the "rot13" protocol to encrypt the message so
it cannot be read accidentally. When you post a message with a spoiler in
it make sure the word "spoiler" is part of the "Subject:" line.
Spelling Flames Considered Harmful.
Every few months a plague descends on Usenet called the spelling flame.
It starts out when someone posts an article correcting the spelling or
grammar in some article. The immediate result seems to be for everyone on
the net to turn into a 6th grade English teacher and pick apart each other's
postings for a few weeks. This is not productive and tends to cause
people who used to be friends to get angry with each other.
It is important to remember that we all make mistakes, and that
there are many users on the net who use English as a second
language. There are also a number of people who suffer from
dyslexia and who have difficulty noticing their spelling mistakes.
If you feel that you must make a comment on the quality of a
posting, please do so by mail, not on the network.
Don't Overdo Signatures.
Signatures are nice, and many people can have a signature added to
their postings automatically by placing it in a file called
"$HOME/.signature". Don't overdo it. Signatures can tell the world
something about you, but keep them short. A signature that is longer
than the message itself is considered to be in bad taste. The main
purpose of a signature is to help people locate you, not to tell your
life story. Every signature should include at least your return
address relative to a major, known site on the network and a proper
domain-format address. Your system administrator can give this to
you. Some news posters attempt to enforce a 4 line limit on
signature files -- an amount that should be more than sufficient to
provide a return address and attribution.
Limit Line Length and Avoid Control Characters.
Try to keep your text in a generic format. Many (if not most) of
the people reading Usenet do so from 80 column terminals or from
workstations with 80 column terminal windows. Try to keep your
lines of text to less than 80 characters for optimal readability.
If people quote part of your article in a followup, short lines will
probably show up better, too.
Also realize that there are many, many different forms of terminals
in use. If you enter special control characters in your message, it
may result in your message being unreadable on some terminal types;
a character sequence that causes reverse video on your screen may
result in a keyboard lock and graphics mode on someone else's
terminal. You should also try to avoid the use of tabs, too, since
they may also be interpreted differently on terminals other than
your own.
Do not use Usenet as a resource for homework assignments.
Usenet is not a resource for homework or class assignments. A common
new user reaction to learning of all these people out there holding
discussions is to view them as a great resource for gathering
information for reports and papers. Trouble is, after seeing a few
hundred such requests, most people get tired of them, and won't reply
anyway. Certainly not in the expected or hoped-for numbers. Posting
student questionnaires automatically brands you a "newbie" and does not
usually garner much more than a tiny number of replies. Further,
some of those replies are likely to be incorrect.
Instead, read the group of interest for a while, and find out what the
main "threads" are - what are people discussing? Are there any themes
you can discover? Are there different schools of thought?
Only post something after you've followed the group for a few weeks,
after you have read the Frequently Asked Questions posting if the group
has one, and if you still have a question or opinion that others will
probably find interesting. If you have something interesting to
contribute, you'll find that you gain almost instant acceptance, and
your posting will generate a large number of follow-up postings. Use
these in your research; it is a far more efficient (and accepted) way
to learn about the group than to follow that first instinct and post a
simple questionnaire.
Do not use Usenet as an advertising medium.
Advertisements on Usenet are rarely appreciated. In general, the louder
or more inappropriate the ad is, the more antagonism it will stir up.
The accompanying postings "Rules for posting to Usenet" and "Advertising
on Usenet: How To Do It, How Not To Do It" have more information on this
subject. Try the biz.* hierarchies instead.
Avoid posting to multiple newsgroups.
Few things annoy Usenet readers as much as multiple copies of a posting
appearing in multiple newsgroups. (called 'spamming' for historical
reasons) A posting that is cross-posted (i.e lists multiple newsgroups
on the Newsgroups: header line) to a few appropriate newsgroups is
fine, but even with cross-posts, restraint is advised. For a
cross-post, you may want to set the Followup-To: header line to the
most suitable group for the rest of the discussion.
Summary of Things to Remember
Never forget that the person on the other side is human.
Don't blame system admins for their users' behavior.
Never assume that a person is speaking for their organization.
Be careful what you say about others.
Be brief.
Your postings reflect upon you; be proud of them.
Use descriptive titles
Think about your audience.
Be careful with humor and sarcasm.
Only post a message once.
Please rotate material with questionable content.
Summarize what you are following up.
Use mail, don't post a follow-up.
Read all follow-ups and don't repeat what has already been said.
Check your return e-mail address and expect responses.
Double-check follow-up newsgroups and distributions.
Be careful about copyrights and licenses.
Cite appropriate references.
When summarizing, summarize.
Mark or rotate answers or spoilers.
Spelling flames considered harmful.
Don't overdo signatures.
Limit line length and avoid control characters.
Do not use Usenet as a resource for homework assignments.
Do not use Usenet as an advertising medium.
Avoid posting to multiple newsgroups.
(*)UNIX is a registered trademark of X/Open.
--
With a PC, I always felt limited by the software available. On Unix, I am
limited by my knowledge. --Peter J. Schoenster <pschon@baste.magibox.net>
------------------------------
Date: 12 Jul 98 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Special: Digest Administrivia (Last modified: 12 Mar 98)
Message-Id: <null>
Administrivia:
Special notice: in a few days, the new group comp.lang.perl.moderated
should be formed. I would rather not support two different groups, and I
know of no other plans to create a digested moderated group. This leaves
me with two options: 1) keep on with this group 2) change to the
moderated one.
If you have opinions on this, send them to
perl-users-request@ruby.oce.orst.edu.
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.misc (and this Digest), send your
article to perl-users@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V8 Issue 3411
**************************************
