The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: gtaylor@tnetconsulting.net (Grant Taylor)
Subject: [TUHS] UUCP "bag" files
Date: Thu, 10 May 2018 22:09:06 -0600	[thread overview]
Message-ID: <5f6aa9eb-d56e-7a42-5d61-53d60ed9eefd@spamtrap.tnetconsulting.net> (raw)
In-Reply-To: <AF685A3D-CD03-4FB2-B5F7-16C4CF14A477@orthanc.ca>

On 05/10/2018 09:58 PM, Lyndon Nerenberg wrote:
> UUCP would transfer many batch jobs in a single session, Each job was 
> a single command.  So you would have a mix of 'uux remote!rmail' and 
> 'uux remote!rnews' all stacked up in the job queue to be transferred 
> and executed on the remote host.

Agreed.

Those were all discrete jobs and associated files in the UUCP queue.

It's my understanding that bag files were an aggregation / collection of 
what uucico (or something closely related) would typically write to the 
modem connected to the remote system.  This output was redirected to a 
single, monolithic file, called a bag.

At least that's my understanding.

This bag would then be transferred some means out of band.

The last time I did this, someone would periodically ftp the bag files 
off of the server.  (I don't remember why he wanted bag files instead of 
standard UUCP.)

I've heard of people using bag file(s) to put news (et al) onto a flash 
drive / tape and sneaker net it across to other disconnected systems 
where the process was done in reverse.

> 'uucp' and 'uux' just created remote batch jobs in a queue directory. 
> When 'uucico' eventually fired off, it would send the command files over, 
> along with any associated data files.

That's typical UUCP.  That's distinctly different than my understanding 
of bag files.

> You could 'uucp' and 'uux' anything you liked, modulo restrictions placed 
> upon you by the administrators of the local and remote hosts.

Yep.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180510/4be6580b/attachment.bin>


  reply	other threads:[~2018-05-11  4:09 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-10  3:49 Grant Taylor
2018-05-10  3:51 ` Lyndon Nerenberg
2018-05-10  4:53   ` Grant Taylor
2018-05-10  5:03     ` Bakul Shah
2018-05-10 15:46       ` Mary Ann Horton
2018-05-10 16:08         ` Chet Ramey
2018-05-10 14:25     ` Chet Ramey
2018-05-10 15:28       ` Grant Taylor
2018-05-10 16:03         ` Dan Cross
2018-05-10 16:24           ` Grant Taylor
2018-05-10 14:10   ` John P. Linderman
2018-05-10 23:38     ` Lyndon Nerenberg
2018-05-11  0:24       ` John P. Linderman
2018-05-11  3:51         ` Grant Taylor
2018-05-11  3:42       ` Grant Taylor
2018-05-11  3:58         ` Lyndon Nerenberg
2018-05-11  4:09           ` Grant Taylor [this message]
2018-05-11  4:18             ` Lyndon Nerenberg
2018-05-12  4:39               ` Grant Taylor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5f6aa9eb-d56e-7a42-5d61-53d60ed9eefd@spamtrap.tnetconsulting.net \
    --to=gtaylor@tnetconsulting.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).