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.

In your .pinerc file, find the part that deals with 'old-style reply'
and set it to 'yes'.

I tried that and it didn't work.  Anything else I could try?  Maybe some word
there other than "yes?"

 
# Use old style forward/reply with new text and signature below included text
old-style-reply=yes
 
Works for me...

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.

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).

I figured out what I'd done wrong.  Thanks, Kent.

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

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.

Then how does one read the return address to which to send return mail
later? netmeg@mpcc.org?

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>

Chris has it right.  Netmeg knows what the address is, even if we can't
read it.

Is it proper to read mpcc.org!Majordomo as Majordomo@mpcc.org? (I'm
trying to understand the Internet addressing rules.)

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.

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.
  

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?

This response has been erased.

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).

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.

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...

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?

This response has been erased.

If the author of mailstrip is reasonably confident of its reliability,
perhaps it would be reasonable to put it in /usr/local/bin.

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.

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.)

If I remember the history correctly, Steve wrote his program to
supersede somebody else's program that *was* too dumb.

That's true. This program distinguishes body from header lines based
on standards for SMTP mail. Marc helped me get that right. Otoh,
davel is correct that if a mail agent violated SMTP standards and
left a naked From: on the beginning of a line, mailstrip would think
it was entering a header and could remove selected lines. I don't
think this is a serious consideration, though.

re #20 (kaplan's objections regarding use of umask)
This is not a bug. Mailstrip is designed as a filter, and you can do 
whatever you like with the output. If you just redirect it to a file,
unix will create that file with perms from your umask.

I suggest that you write a short script to run mailstrip, and you
can set the perms any way you like with that.

I would like to warn against automatic replacement of your unstripped
mail with the stripped copy. I say this not because mailstrip is
unreliable in any way. (It is not, as far as I know.) Rather, because
anything may go wrong in the process. What if the disk fills up?
It would probably be sufficient if you did a mv -i stripped realmailfile
just to give the human a chane to say no.

There is another script that is user-adjustable, if needed, and I'll
put it in /tmp or somewhere like that.
  
It's a sed script that, besides being in English, can be customized
by the user (if you copy to your own directory). Each of the lines
that starts  witha    /   and ends with a    /d   contains the 
specific identification which is searched for and, if found, deleted.
  
As you observe the headers of your email, you will see the formats
of line-beginnings which coorespond to the  stuff between  /   /d,
including the TAB spacing for some of them.
  
I would not recommend deleting either of the   From  lines, especially
the From that does NOT have a   :   following. remmers and others
have said that the   From  without a colon is the "signal" to 
all the mailers of the start of a new email.
 
Nuff fer now - I'll put that file somewhere and tell you where in
a minute or so.
  

Ok, so it was more than a minute, suffer. The filename is   TrimMail
and it is in /tmp. 
  
Anyone can cp it, and use it or modify it. I do notice that I
added some line-deletions for Usenet Newstuff as well, recently.
  
So it'll work on Usenet articles as well.   have fun.
  

This response has been erased.

is there a more permanent temporary directory? <did I actually
says that?> that should be used?
.

,

New pine questions:
1) Moving around the buffer (I guess this question applies to pico more
than pine) is slow, so I looked at help.  It said that ^space or ^@ skips
to the next word.  I hit ctrl-space and nothing happened.  I hit ctrl-2
(shift isn't important, right?) and I got a cshell prompt and I couldn't
type anything at that prompt.  I hung up, called back, and when I arrived,
I couldn't find any remains of the rather long message I had been writing
before I broke it.  What's the original problem?  There's a second problem
too.  It seems that pico lacks vi's  capability of recovering from a killed
process.  Perhaps I will have to switch back to vi....

2) ^Y prev page, ^V next page is fine.  But is there a key to go up or
down several screens full at a time?  A key to go to the top or bottom of
the file?

3) (back from pico to pine questions) I want to download an message and
write the reply off line.  The print command to print the message on my
local printer is cool, but I'd also like a command to print the message to
a local file.  Or at least I'd like to be able to pipe the message through
cat and capture it to a local file.  There must be a way but I can't find it.

4) I like pico's spell checker, but if it finds a misspelling and asks for
a correction, there's a problem.  It does not check the spelling of the
correction, so lousy spellers like me are stuck looking up the spelling
elsewhere, or guess and run the spell checker again from the top.  Are
other UNIX spell checkers more friendly than pico's?

5) A lot of correctly spelled words are flagged as wrong.  The ones that
come to mind are 'pico', 'grex', 'cyberspace', and 'mom'.  Who has access to
update the list of correctly spelled words?

Oh yeah, one more question.  When I type enter pine, I don't need to see
the main menu.  I'd rather have it come up on the index.  Is there a way
to do that?  Or to abbreviate the main menu so it doesn't take so long to
come up on the screen?

I don't use either pine or pico, so I can't help too much, but ... you can
save a message to a folder in pine, right?  I suspect saving it to /dev/tty
would have the effect of piping it through cat, but I could be wrong.  If
worse comes to worst, you could save it to a folder (file) and then cat
that.

I also would be interested in seeing the speller dictionary enhanced.
(But what do pine & elm use?  The spell program?)

This response has been erased.

I was just looking at all the wierd little files that must do something
since some program or other has seen fit to put them in my directory, when I 
came across the following:

.pine-interrupted-mail.lock.790361393.29816.grex

Whatta name eh?  Anyone know what this little fellow is for?  Can I delete
him?

Can't be *for* much - it has 0 bytes. What were you doing at 11:49 on
17 January?

This response has been erased.

You could keep it and put crazy stuff in it. I suggest, though, that
you change the permissions from 666 to 600, if you don't want others
to fill it up first with crazy stuff ;->. 

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss