|
|
| Author |
Message |
scg
|
|
Pine question
| 
Oct 24 22:55 UTC 1993 |
When using Pine, if I tell it to quote the message I'm replying to, it puts
the quote after the .sig. Is there any way to quote a message and still keep
the .sig at the end of the message?
|
| 97 responses total. |
kentn
|
|
response 1 of 97:
|
Oct 25 03:31 UTC 1993 |
In your .pinerc file, find the part that deals with 'old-style reply'
and set it to 'yes'.
|
scg
|
|
response 2 of 97:
|
Oct 25 21:22 UTC 1993 |
I tried that and it didn't work. Anything else I could try? Maybe some word
there other than "yes?"
|
kentn
|
|
response 3 of 97:
|
Oct 26 03:33 UTC 1993 |
# Use old style forward/reply with new text and signature below included text
old-style-reply=yes
Works for me...
|
scg
|
|
response 4 of 97:
|
Oct 26 19:39 UTC 1993 |
That's what I've got. It didn't work yesterday, but I'll try it again. It
seems strange that it would work for one person and not for an other.
|
kentn
|
|
response 5 of 97:
|
Oct 27 05:59 UTC 1993 |
Maybe I'd better re-verify it, just in case. My .sig has been appearing
at the bottom of all my messages going out, as far as I know (becausei t
appears that way in the editor when you first start to enter a message).
|
scg
|
|
response 6 of 97:
|
Oct 29 02:57 UTC 1993 |
I figured out what I'd done wrong. Thanks, Kent.
|
bartlett
|
|
response 7 of 97:
|
Dec 23 20:52 UTC 1993 |
From netmeg!mpcc.org!Majordomo@grex.cyberspace.org Thu Dec 23 02:58:11 1993
Date: Thu, 23 Dec 93 01:56:39 -0500
From: netmeg!mpcc.org!Majordomo@grex.cyberspace.org
Reply to: mpcc.org!Majordomo@grex.cyberspace.org
To: bartlett@cyberspace.org
Subject: Majordomo results
The above is the header of the reply to a majordomo request I sent out
yesterday. There is a puzzling thing, note the return address has an
@grex.cyberspace.org appended to it. This is true for the return addresses
on all Email I receive while using pine. What is this? How can I get rid
of it?
Chris
|
scg
|
|
response 8 of 97:
|
Dec 24 02:10 UTC 1993 |
Just ignore it. Since Grex transforms the return address into a UUCP path,
it leaves it without @ anything on the end. Pine always wants everything,
even local mail, to have the @something on the end, so it adds that.
|
rcurl
|
|
response 9 of 97:
|
Dec 24 04:39 UTC 1993 |
Then how does one read the return address to which to send return mail
later? netmeg@mpcc.org?
|
bartlett
|
|
response 10 of 97:
|
Dec 24 06:51 UTC 1993 |
In this case, majordomo@mpcc.org is the operative address. The netmeg! is,
I think, a routing instruction for the routing of mail through Meg's machine
which handles all our ail. Of course you knew that. <smile>
|
robh
|
|
response 11 of 97:
|
Dec 24 12:16 UTC 1993 |
Chris has it right. Netmeg knows what the address is, even if we can't
read it.
|
rcurl
|
|
response 12 of 97:
|
Dec 24 16:59 UTC 1993 |
Is it proper to read mpcc.org!Majordomo as Majordomo@mpcc.org? (I'm
trying to understand the Internet addressing rules.)
|
mju
|
|
response 13 of 97:
|
Dec 24 20:14 UTC 1993 |
Yes.
The reason the "@somewhere" needs to be added is that a UUCP "bang
path" (something of the form a!b!c) is a relative address. It
says, "from where you are right now, go to a, then to b, then
to c". The problem is then defining "where you are right now" --
if the mail is sent to another system, the address won't be
valid anymore, unless the mailers manually update the addresses
by adding another host to the bang path. By adding "@cyberspace.org"
to the end of the bang path, Pine "roots" the address and defines
where to start on the bang path. Thus, if the mail is transferred
to another system, the address will still work (although it will
be somewhat inefficient).
In most cases, host.dom.ain!user can be converted to user@host.dom.ain
without any loss in information content.
|
tsty
|
|
response 14 of 97:
|
Dec 28 21:08 UTC 1993 |
Also, there should have been a line labled Return path: which
would be used by netmeg to handle a straight reply. But also
notice in this header, the Reply to: line which +seems+ to
contain a specific character-string for "cold" email messages.
|
kaplan
|
|
response 15 of 97:
|
Feb 3 17:06 UTC 1994 |
I've been saving too much of my old mail and I know the best way to
conserve disk space would be to delete it all. But until I get around to
taking care of that, is there an easy way to strip everything except To:
From: Subject: and Date: from the headers in such a way that the old
messages and folders will still be readable by pine? Seems it should be
an easy program to write in C. Has someone already done it? Is there
anything special about the format pine uses to save messages?
Hey, why doesn't pine compress closed folders and uncompress them before
trying to open them? Perhaps we should get into the habit of
% uncompress *; pine; compress *
or am I just taking the message that I got at login time about disk space
too seriously? Would all that compressing put a strain on the CPU?
|
popcorn
|
|
response 16 of 97:
|
Feb 3 23:49 UTC 1994 |
This response has been erased.
|
kentn
|
|
response 17 of 97:
|
Feb 4 02:11 UTC 1994 |
I've got a copy I can post if you want it. (I think it's buried below
the public area of my home directory).
|
srw
|
|
response 18 of 97:
|
Feb 4 02:48 UTC 1994 |
I have a program that I wrote to strip headers off of mail files.
/u/srw/mailstrip <file1 >file2
Where file1 is your mail file to be stripped, and file2 is the
stripped output. It does not strip in place or delete the old one.
It will remove a standard collection of headers, but I have it
remove additional headers by keeping a strip-profile file.
It looks for a file .stripp in your working directory.
If it finds one, it strips all the headers that match the ones in
that file. It never changes the body.
You can copy /u/srw/.stripp to your dir if you want use it like I do.
|
srw
|
|
response 19 of 97:
|
Feb 4 02:55 UTC 1994 |
If you're concerned about whether you can safely run the program
(read item 84 response 20) the source code is /u/srw/mailstrip.c,
so you can see it if you know c. You can also rebuild it for yourself if
you want. It is true that you never know what's in an executable
program unless you built it yourself, and even then...
|
kaplan
|
|
response 20 of 97:
|
Feb 8 18:36 UTC 1994 |
re 18: I tried mailstrip and I've found a bug. Or at least I consider it
a bug. I like my default umask because it's ok for people to read files
that I save unless I chmod them or put them in an unreadable directory.
But when pine saves messages, it does so in files that the public can not
read. Good, as I don't want people looking at my private mail. But
mailstrip creates files using my umask (I assume). I'd like it to copy the
chmod information from the original mail folder. Is that easy to fix?
re 19: Why not have a staff person put mailstrip in /usr/local/bin or
someplace. What's the point of having copies of a disk-space-saving
program taking up disk space in a bunch of people's private directories?
|
popcorn
|
|
response 21 of 97:
|
Feb 9 14:41 UTC 1994 |
This response has been erased.
|
remmers
|
|
response 22 of 97:
|
Feb 9 18:38 UTC 1994 |
If the author of mailstrip is reasonably confident of its reliability,
perhaps it would be reasonable to put it in /usr/local/bin.
|
srw
|
|
response 23 of 97:
|
Feb 10 13:10 UTC 1994 |
I am the author and I am confident of its reliability, as I have been
using it for 6 months. In the process of designing it I incorporated
several good suggestions from mju. I think kaplan's suggestion in #20
sounds like a good one (not a bug, though, a limitation perhaps).
I'd be willing to fix that some weekend. I'd have no objection to it
being in /usr/local/bin. I could support it.
It does not strip in place, but rather to a new file, so any mailbox
eating will have to be done by the user.
|
davel
|
|
response 24 of 97:
|
Feb 10 14:55 UTC 1994 |
The mailbox-eating issue would, I think, be whether it got confused so that
messages or parts thereof disappeared on occasion without warning. (This
really can be a serious problem if a mail agent fails to fix up lines
beginning with "From" in the body of a message, on any scheme. But it's
also easy to write a mailstrip program that's just a little too dumb.)
(This is not a comment at all on Steve's program, which I haven't looked
at but which is likely to be pretty good, since the problem isn't *that*
hard and Steve is certainly not incompetent.)
|