pfeifer@vax1.acs.udel.EDU (Mark C Pfeifer) (02/17/89)
Could someone mail me a copy of the COMBINE script? Also, is there a similar script for putting together postings in comp.binaries.mac (I know I'm asking in the wrong area, but maybe I'll kill two requests with one message)? Thanks, Mark No signature required here, Sir.
twb@hoqax.UUCP (T.W. Beattie) (02/17/89)
In article <2858@udccvax1.acs.udel.EDU> (Mark C Pfeifer) writes: >Could someone mail me ... >Thanks, >Mark >No signature required here, Sir You requested that someone E-mail you a file yet you don't feel it is important to supply an address? Since many of these messages get sent thru one-way connections I think it would be reasonable to supply a suggested return path or a domain address. Give people a chance to help you. Maybe I should GUESS your address from the headers on the message :-). --- Tom Beattie att!hoqaa!twb t.w.beattie@att.com
sloane@kuhub.cc.ukans.edu (Bob Sloane) (02/21/89)
In article <2168@hoqax.UUCP>, twb@hoqax.UUCP (T.W. Beattie) writes: > Give people a chance to help you. > Maybe I should GUESS your address from the headers on the message :-). Is there some reason why the Reply-to: header in the original message should not be trusted to contain the senders actual address? Do you really need to "GUESS"??? +-------------------+-------------------------------------+------------------+ | Bob Sloane \Internet: SLOANE@KUHUB.CC.UKANS.EDU/Anything I said is | | Computer Center \ BITNET: SLOANE@UKANVAX.BITNET / my opinion, not my | | University of Kansas\ AT&T: (913) 864-0444 / employer's. | +-----------------------+-----------------------------+----------------------+
doug@sis.UUCP (doug berry) (02/22/89)
In article <2168@hoqax.UUCP> twb@hoqax.UUCP (T.W. Beattie) writes: [...flames about no return path deleted...] > >Give people a chance to help you. >Maybe I should GUESS your address from the headers on the message :-). Well Mr Beattie, maybe you could have posted the one line combine script along with the flame? #! /bin/sh cat $* | sed '/^END/,/^BEGIN/d' | uudecode -- ...utzoo\ phone: +1 416 845 9430 x446 uucp: ...uunet!mnetor!yunexus!sis!doug ...utai/ attcan/
chip@ateng.ateng.com (Chip Salzenberg) (02/25/89)
According to sloane@kuhub.cc.ukans.edu (Bob Sloane): >Is there some reason why the Reply-to: header in the original message should >not be trusted to contain the senders actual address? The default configuration of the "rn" newsreader generates incorrect Reply-To headers on domainish sites. For example, when posting from unicorn.ateng.com, the Reply-To field is "user@unicorn.UUCP", which is not at all correct. >Do you really need to "GUESS"??? On occasion. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! "It's no good. They're tapping the lines."
bobmon@iuvax.cs.indiana.edu (RAMontante) (08/02/89)
<8472@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) : -< archive. E.g., for a three-part posting, save it in files -< called "part01", "part02", and "part03", and then give the -< command: -< -< combine part01 part02 part03 brown@astroatc.UUCP (Vidiot) <2487@astroatc.UUCP> : -Since when has the combine script become "lazy"? A long time ago a better -combine script was posted. It works much nicer, especially on programs with -MANY parts. Who wants to type in the names of all 11 pieces :-) So, attached Actually, I find that I can save the various parts into the SAME file (as long as I keep them in order, that is important) (rn lets me append very easily). Then the original combine script happily pulls all the correct parts out of the one file and uudecodes that. Another possibility is using wildcard expansion, which on the system I use generates the names in "correct" order. Viz., "combine thing.part*" where I have thing.part01 through thing.part99. Here's the original again, for people who missed it: #! /bin/sh cat $* | sed '/^END/,/^BEGIN/d'| uudecode
rogers@falcon.SRC.Honeywell.COM (Brynn Rogers) (08/03/89)
In article <2487@astroatc.UUCP> brown@astroatc.UUCP (Vidiot) writes: >Since when has the combine script become "lazy"? A long time ago a better >combine script was posted. It works much nicer, especially on programs with >MANY parts. Who wants to type in the names of all 11 pieces :-) So, attached >below is the original, longer, better script: [script omitted] >The syntax is simple. One saves the files as program_name.sequence_number, >ie, part.1 part.2 part.3 ... When one is ready to combine the pieces, >one says: > combine part 3 >The script will then put all the pieces into a .temp file and then sed it >into a .uue file. After I recently learned how to use rn properly, I find this to be the easiest and fastest way: Let Comp.binaries.ibm.pc fill up with good stuff in rn: g comp.binaries.ibm.pc (or just let it come up by itself) = (displays all subject lines and article numbers) 1802: Biff part01/5 ( this is an example of what it said ) 1803: Biff part02/5 1804: Biff part03/5 1805: Biff part04/5 1806: Biff part05/5 Read this article [ynq]: ( approximation of what it really asks here) to which I reply: 180[2-6]s~/biff (saves all the parts to one file, useing standerd ) and it says: (C regexp notation to identify which articles) article 1802 saved to file /n/orion/mnt1/users/rogers/biff article 1803 appended to file /n/orion/mnt1/users/rogers/biff article 1804 appended to file /n/orion/mnt1/users/rogers/biff article 1805 appended to file /n/orion/mnt1/users/rogers/biff article 1806 appended to file /n/orion/mnt1/users/rogers/biff then I just quit rn and type combine biff and it makes me the whatever.zoo file this is my combine script, practically identical to the new and improved combine script. #! /bin/csh -f cat $* | sed '/^END/,/^BEGIN/d'| uudec Note that with this combine script (which I think is actually identical to the official one, except it uses csh and uudec instead of sh and uudecode) there is no need to save to many different file names and count files. I used to combine all the files manually in emacs, but this is much better. Brynn Rogers Honeywell S&RC rogers@src.honeywell.com 612-782-7737 use this address if your reply bounces
David Schuetz, Technical Services Consultant (08/03/89)
As long as we're talking about combine, could somebody please tell me what the "sed '/^END/,/^BEGIN/d'" (or whatever) does? I figured that it deleted everything not within the BEGIN/END block of the file, but in some tests (just sending the result to output rather then piping it to uudecode), I found that it didn't make any changes at all, and that uudecode didn't give a damn whether or not there was article header garbage in the file. I was doing this mostly to try and make a "combine" script for extracting shar files. It didn't work. If it matters, I'm using ultrix 3.0. david.
bobmon@iuvax.cs.indiana.edu (RAMontante) (08/03/89)
dschuetz@umd5.umd.edu (David Schuetz) <5154@umd5.umd.edu> :
-
-As long as we're talking about combine, could somebody please tell me what
-the "sed '/^END/,/^BEGIN/d'" (or whatever) does? I figured that it
-deleted everything not within the BEGIN/END block of the file, but in
Almost. Precisely, it finds sets of lines starting with a line that
begins with `END' ("^" means "beginning of line"), and ending with a
line that begins with `BEGIN', and deletes those sets of lines. When a
set of c.b.i.p. postings are concatenated, each one ends with an END
line, then there's some junk including headers in the next file, then
the next file's body starts with a BEGIN line. This "internal" junk
is deleted.
However, it won't touch the stuff before the first BEGIN line (in the
first file), because there is no initial END line --- but uudecode
ignores header lines up to its own `begin 666 filename' line anyway.
Similarly, it won't scrape off garbage following the (last) END line,
but uudecode ignores trailing garbage after its own `end' line as well.
So the `sed ...' command only has an effect when multiple files are
concatenated together.campbell@hpdml93.HP.COM (Gary Campbell) (08/03/89)
>True, using wild cards will get you the whole list. But who says that it >will be in order. Sure, you do a ls and they 'look' in order, but how did >you actually store them. Do a tar or cpio and you will see that your disk >isn't necessarily in order. On my system wildcards generate file names in ASCII order just like ls. Is this not true on some UN*X systems? BTW: Why the cat in cat $* | sed '/^END/,/^BEGIN/d'| uudecode My man page shows that sed will take a series of files like cat, so it could be: sed '/^END/,/^BEGIN/d' %* | uudecode -- Gary Campbell Internet: campbell%hpbsla@hplabs.HP.COM UUCP: ...!hplabs!hpbsla!campbell
brown@astroatc.UUCP (Vidiot) (08/04/89)
In article <5154@umd5.umd.edu> dschuetz@umd5.umd.edu (David Schuetz) writes:
<
<As long as we're talking about combine, could somebody please tell me what
<the "sed '/^END/,/^BEGIN/d'" (or whatever) does? I figured that it
<deleted everything not within the BEGIN/END block of the file, but in
<some tests (just sending the result to output rather then piping it to
<uudecode), I found that it didn't make any changes at all, and that
<uudecode didn't give a damn whether or not there was article header
<garbage in the file.
Look very carefully at the script again. It is telling sed that the first
line number of the range starts with END in the left column. The last
line number of the range starts with BEGIN in the left column. The header
information is NOT thrown away because sed will find the first instance
of END and the end of the first file. The BEGIN is right before the text
starts of the second file, and so on. What sed ends up doing is throwing
away the end garbage of one file through the header information of the next
file. Remember all of the posted pieces are placed into one file first.
Try reversing the END and BEGIN and see what happens to the output. It will
be like keeping the bath water and throwing out the baby.
I hope this helps explain what is happening. Just remember that the first
BEGIN is ignored.
--
harvard\ att!nicmad\
Vidiot ucbvax!uwvax..........!astroatc!brown
rutgers/ decvax!nicmad/
ARPA/INTERNET: brown%astroatc.UUCP@spool.cs.wisc.edutarvaine@tukki.jyu.fi (Tapani Tarvainen) (08/04/89)
In article <5154@umd5.umd.edu> dschuetz@umd5.umd.edu (David Schuetz) writes: >As long as we're talking about combine, could somebody please tell me what >the "sed '/^END/,/^BEGIN/d'" (or whatever) does? It deletes everything from END-line to BEGIN-line, repeatedly if there are several such pairs, and in that order only: it does not delete leading garbage (beginning through 1st BEGIN) nor trailing (from last END on) - uudecode ignores them, it's only the junk in the middle that confuses it. Hope this helps. -- Tapani Tarvainen (tarvaine@jyu.fi, tarvainen@finjyu.bitnet)
dhesi@bsu-cs.bsu.edu (Rahul Dhesi) (08/10/89)
In article <1540001@hpdml93.HP.COM> campbell@hpdml93.HP.COM (Gary Campbell) writes: >BTW: Why the cat in > > cat $* | sed '/^END/,/^BEGIN/d'| uudecode > >My man page shows that sed will take a series of files like cat... Since cat is a small, simple, and universal utility, its behavior is fairly predictable on all **IX family operating systems including those not derived from UNIX itself. But who knows what sed does on all systems? And what does sed do with a file called "-e"? (Although some cats will choke on some filenames beginning with a dash, this is a little less likely than with sed.) Portability was the main reason for letting cat combine multiple files, and asking sed to do only the simplest thing possible, i.e., read from stdin and write to stdout. -- Rahul Dhesi <dhesi@bsu-cs.bsu.edu> UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi (Will change to cirrusl!dhesi effective approximately August 28)