$Id: readme.txt,v 1.2 2002/04/22 23:07:41 jjlupa Exp $
ypost - Yet Another Poster
Ypost is a program to post binary files to usenet newsgroups. I wrote ypost because I wanted a command-line posting program that runs under Linux command line, and the one that was available (newspost) didn't support yEnc or throttling. I did a few updates to newspost and resubmitted the changes, but I felt that beyond a cartain point, it made more sense for me to write a new system. I decided this partially because after having used C++ for the last few years, C leaves me very nervous - there are too many ways in which C++ is far safer than C (automatic destruction, etc) and I just felt a rewrite was in order.
- Installation
- The installation is pretty primative. Since ypost is such a simple program, I hope it will compile up on most machines. Just type "make" at the command line, and when it's done, copy the "ypost" executable to wherever you like, I suggest /usr/local/bin
Usage: ypost [options] file1[:parts] ...
First, a note on specifying segment posts. Normally you would just post a
file in its entirety: ypost (options) filename.tgz. However, if you found
that the server had eaten part 10 through 15 and 19 of your post, you could
just repost those segments like this:
ypost (options) filename.tgz:10-15,19
You can keep going like that, comma and dash separated, no spaces. You can specify different parts for different files, or leave out the part specifications to post the whole file.
All options can be abbreviated to the shortest form that uniquely identifies the command (-f for from, -po for port, -pa for password)
Valid options:
-from email-addr
-newsgroups groupnames - comma separated
-Subject SUBJ - subject for all your posts.
-hostname (name) - ip or name of posting host
-port (portnum) - port on server to post to
-userid (userid) - user id if authentication is required
-passwd (password) - passwd if auth required
-lines (numlines) - max lines per post
This number is followed strictly for uuencoded articles.
For yEncoding, things get a little more complex. The line length is very
long (128 characters). Ypost makes the assumption that when you say, for
instance, you want 5000 line posts, what you really want is 5000 * 60
characters per line = 30000 byte posts. What you actually get is a 30000
byte post. The actual number of lines may vary, since yEncoding may expand
a string of bytes by a different amount, depending on the contents.
Ypost works in this way in order to allow reposting of individual segments of a post without having to read through the entire file up to that point.
-throttle (Bps) - max bytes per sec to post
-text filename - post as text file
Just the next file named will be posted raw. The filename will not be added to the subject line. Note that "lines per article" is ignored for these, but that isn't usually a problem.
-uuencode - use uu encoding
-yenc - use yenc encoding
Note that if you have some crazy reason to do so, you can intersperse these, i.e. -uuencode file1 file2 -yenc file3 file4
-v xxx - set verbosity level to xxx
0 = quiet (errors only)
1 = normal, 2 = progress bars
3 = basic debugging, 4 = more debugging, 5 = very noisy
-defaults - write settings from this command line to defaults file
(usually ~/.ypostrc) - files being posted will not be written,
but most everything else does.
The file is written after the arguments are parsed, but before any
validation. The parsing will catch invalid arguments before saving.
Validation just checks to see if you have all the necessities such as
a newsgroup, files to post, etc, and you don't necessarily want to put
those into your defaults file.
NOTE that if you want to erase a value, give an empty value and record it.
For instance, if you have a subject line in your defaults file now and
you'd like to get rid of it and not have a default subject line anymore:
ypost -s "" -d
will remove the subject line from the defaults file.
-? print help
A note on throttling...
One conceivable goal of throttling is to allow bytes out at a rate such that the entire process is finished with the average bitrate coming out to the target throttle.
We didn't do that.
Frankly, we wanted a simple cap on the amount of data that can go out PER SECOND. The reason for this is to avoid QOS limitations placed on us by our upstream providers.
What this means is that when the data is going through it is capped at the throttle rate, and in fact the entire process can average out to over HALF of the throttle rate (since it includes such things as waiting for 240 replies and such).
For detailed transmission rate information, set verbosity to 3.