[comp.sys.amiga] Sources in text mode please

cmcmanis%pepper@Sun.COM (Chuck McManis) (05/11/88)

Pat, if my mail message didn't get through to you please let me 
reiterate. My feeling is that the source news groups are for sources
and zoo archives are binaries period. Some P, CP (Point, Counter Point)

P: Sources are big and often don't come to us as shar files.
CP: True, this is why they have their own group and are moderated. If you
    put them into some encoded binary format over half your "customers" will
    no longer be able to use them.

P: Using zoo increases reliability.
CP: Baloney, when unsharing source code, if I get an error I can often correct
    the line noise in the source and recompile. In an archive file the whole
    file is often irretriveably blown away.

There are more, but this is not meant to be a flame, just a _vigorous_ request
that the sources groups remain 'human readable' thank you.


--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.

dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/11/88)

>Pat, if my mail message didn't get through to you please let me 
>reiterate. My feeling is that the source news groups are for sources
>and zoo archives are binaries period. Some P, CP (Point, Counter Point)
>
>There are more, but this is not meant to be a flame, just a _vigorous_ request
>that the sources groups remain 'human readable' thank you.

	We should discuss this, actually.  This is my opinion:

	(1) The outer layer of source/binaries postings should ALWAYS BE
	    A SHAR.  Period.  What the SHAR contains can be anything...
	    uuencoded files, zoo + uuencoded files, arc + uuencoded files,
	    text files, whatever, BUT MAKE THAT OUTER LAYER A SHAR!

	Reason#1:  most unshar programs are intelligent ... so much so that
	they ignore garbage at the beginning (the header) and end 
	(the signature).  Thus, there is no need to VI the file before 
	decoding ... just run it through unshar.

	Reason#2:  if uuencoded files are shar'd, there are no blank lines
	after you unshar, and you can simply cat the segments together and
	pipe it through uudecode.  simple.

	Reason#3:  It becomes obvious if a posting is truncated.

	This is a precursor to discussing the possible changeover from
	moderated to unmoderated.  The lag time is simply too great as
	it is (sorry moderators... classes or not, 2 months is ridiculous)
	I think we can do it... if everybody agrees on a standard (maybe
	the one I suggested above?).

					-Matt

cmcmanis%pepper@Sun.COM (Chuck McManis) (05/12/88)

In article <8805110255.AA21249@cory.Berkeley.EDU> (Matt Dillon) writes:
>	We should discuss this, actually.  This is my opinion:
>
>	(1) The outer layer of source/binaries postings should ALWAYS BE
>	    A SHAR.  Period.  What the SHAR contains can be anything...
>	    uuencoded files, zoo + uuencoded files, arc + uuencoded files,
>	    text files, whatever, BUT MAKE THAT OUTER LAYER A SHAR!

I agree with this, except that I still assert that source code should be
source code and not "zooed" or "arced" when distributed. It should always
be shar'd and somethings like .info files will have to be uuencoded.

--Chuck

--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.

papa@pollux.usc.edu (Marco Papa) (05/12/88)

In article <52841@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes:
>In article <8805110255.AA21249@cory.Berkeley.EDU> (Matt Dillon) writes:
>>	We should discuss this, actually.  This is my opinion:
>>
>>	(1) The outer layer of source/binaries postings should ALWAYS BE
>>	    A SHAR.  Period.  What the SHAR contains can be anything...
>>	    uuencoded files, zoo + uuencoded files, arc + uuencoded files,
>>	    text files, whatever, BUT MAKE THAT OUTER LAYER A SHAR!
>
>I agree with this, except that I still assert that source code should be
>source code and not "zooed" or "arced" when distributed. It should always
>be shar'd and somethings like .info files will have to be uuencoded.

I second Chuck's point: sources should be SOURCES, binaries should be
BINARIES. Both should be SHARed.  Binaries should be UUENCODED and not
ARCed or ZOOed, at least in general since EVERYBODY has uuencode/uudecode
(on both UNIX and Amiga) while the same is not true fo the other two programs.

-- Marco Papa 'Doc'
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
uucp:...!pollux!papa       BIX:papa       ARPAnet:pollux!papa@oberon.usc.edu
 "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

backstro@silver.bacs.indiana.edu (05/12/88)

>I agree with this, except that I still assert that source code should be
>source code and not "zooed" or "arced" when distributed. It should always
>be shar'd and somethings like .info files will have to be uuencoded.
>
>--Chuck
>
>--Chuck McManis
>uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
>These opinions are my own and no one elses, but you knew that didn't you.

I also agree that source files should be left in human readable form.
Becuase if the source IS still in human readable form most likely any
errors could be corrected.  Also it would be nice to be able to download
sources for other types of computers.  This would be much simpler than 
having to download some source and then have to send it to the computer
it was written for and then transfer the uncompressed version of the 
source back to your machine.  After all that you can now begin work...

Well that's my $0.02 worth.  If you've got any opinions, keep 'em!  ;^)

 +----------------------------------------------------------------------------+
 | James Colyer | #define LIFE (?) | AMIGA!  //// |  Running his 1 Meg Amiga  |
 |---------------------------------|        ////  |   1000 from a Lobby (!)   |
 | ARPA: backstro@silver.bacs.     |       ////   |---------------------------|
 |       indiana.edu               |      ////    | "There is no dark side on |
 | USSnail: 4755 N. Kinser Pike,   | \\\\////     |  the moon, really. Matter |
 |          Bloomington, IN, 47401 |  \\XX//      |  of fact it's all dark."  |
 |----------------------------------------------------------------------------|
 | The opinions expressed are those of a sick and deranged maniac.  Poor sod. |
 +----------------------------------------------------------------------------+

david@ms.uky.edu (David Herron -- One of the vertebrae) (05/13/88)

In article <52841@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes:
 ...
>I agree with this, except that I still assert that source code should be
>source code and not "zooed" or "arced" when distributed. It should always
>be shar'd and somethings like .info files will have to be uuencoded.

Requiring the source to be un-coded (i.e. in clear) assumes that
news articles pass through the system unmunged.  But they often
don't.  Weeell..  "often" is relative at least to this site.  We
have a news neighbor that's an IBM mainframe, and news which passes
through there undergoes a number of interesting transformatsions.  

Further ... The news article format is purposely compatible with
mail message format so that news feeds could be made via mail if
necessary.  Mail doesn't gaurantee unmunged delivery.

Source files are particularly sensitive to slight mungings.  A common
munging is tab interpretation (conversion to spacing, and sometimes
in differing styles).  Later patches fail mysteriously because the
patch has tabs and the source has spaces (or the other way around).
Or you've got a shell script which has a grep pattern which includes
a hard tab, and the tab gets translated to a bunch of spaces and doesn't
work again.

If the source is uuencoded (especially if done with the newer versions
of uuencode that do checksums) it will survive better in it's way
through the networks.

Usenet is growing beyond it's Unix starting points.  We have IBM mainframes
which are full news partners/participants, nntp based news readers for 
tops-20, vms, and symbolics lisp machines, and a number of other developments.
We can't continue to assume that the situations will continue as
they have been in the past.  As we interconnect with other types of
systems, each new "foriegn" system brings its own problems along.
-- 
<---- David Herron -- The E-Mail guy            <david@ms.uky.edu>
<---- or:                {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET                                  
<---- Windowing... The Amiga has windowing. The Mac has windowing (echoes of
<---- Jonathan Livingston Seagull: "Just flying? A mosquito can do that much!").

dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/13/88)

>I second Chuck's point: sources should be SOURCES, binaries should be
>BINARIES. Both should be SHARed.  Binaries should be UUENCODED and not
>ARCed or ZOOed, at least in general since EVERYBODY has uuencode/uudecode
>(on both UNIX and Amiga) while the same is not true fo the other two programs.

	I agree with one exception.  When the distribution requires a 
	directory structure to be maintained, or has lots of files with
	long filenames, ZOO should be used...  Look at the ARP distribution?
	It took me hours to fix up all those ARC'd segments....

	This is why DNET is being distributed on sources as a uuencoded
	ZOO archive...  There is no other way to maintain the directory
	structure and I wasn't about to hand-generate the ARCs or split
	everything into a thousand singular-directory files and provide
	a script to restore it.

	And I'm a convert, BTW.  A month ago I didn't like ZOO.  But now....

					-Matt

peter@sugar.UUCP (Peter da Silva) (05/13/88)

I like to do some unpacking on UNIX before shipping stuff down. But if
it's arced or zooed I'm out of luck. No source to zoo, and ironically the
UNIX version of arc is allergic to braindamaged intel architectures!

On another line, my big complaint with the Mac sources group was all
the hexbinned stuff in it. Some non-Mac people like to look at other
guy's stuff now and then.
-- 
-- Peter da Silva      `-_-'      ...!hoptoad!academ!uhnix1!sugar!peter
-- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter
-- Disclaimer: These aren't mere opinions, these are *values*.

scott@applix.UUCP (Scott Evernden) (05/13/88)

In article <8805130331.AA29993@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
>	... When the distribution requires a 
>	directory structure to be maintained, or has lots of files with
>	long filenames, ZOO should be used...  Look at the ARP distribution?

I have no problem with this except:

  Is there a version of ZOO for unix?  I really hate it when I dload a 400K
  .zoo file to my amiga (via 1200 baud modem) only to discover 1) that it
  contains stuff I don't want, or 2) that the "(FL4m{{i{i"R$``!>0<" on line
  5293 in the .uu file should have been a "(FL48-!@2B"R$``!>0<".

At lease I can unwrap .arc files on my sun...

-scott

grwalter@watcgl.waterloo.edu (Fred Walter) (05/14/88)

In article <698@applix.UUCP> scott@applix.UUCP (Scott Evernden) writes:
>In article <8805130331.AA29993@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
>>	... When the distribution requires a 
>>	directory structure to be maintained, or has lots of files with
>>	long filenames, ZOO should be used...  Look at the ARP distribution?
>
>I have no problem with this except:
>
>  Is there a version of ZOO for unix?

ZOO was originally written for unix. If you have the amiga distribution
of zoo then you presumably have the docs and somewhere in there it indicates
this fact.

ZOO for unix was recently (18 Aug 87) reposted to comp.sources.unix by its
author iuvax!bsu-cs!dhesi@seismo.CSS.GOV (Rahul Dhesi)

and if your site doesn't archive comp.sources.unix a site near you probably
does.

As you can probably tell, I vote for using zoo when pathnames/directory
structures need to be preserved.

	fred

lphillips@lpami.van-bc.UUCP (Larry Phillips) (05/15/88)

In <8805130331.AA29993@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
 >	I agree with one exception.  When the distribution requires a 
 >	directory structure to be maintained, or has lots of files with
 >	long filenames, ZOO should be used...  Look at the ARP distribution?
 >	It took me hours to fix up all those ARC'd segments....

  Yes, I like to be able to use long names in archives, and to preserve the
directory structure too, so I have a present for you at the end of this
posting.

 >	This is why DNET is being distributed on sources as a uuencoded
 >	ZOO archive...  There is no other way to maintain the directory
 >	structure and I wasn't about to hand-generate the ARCs or split
 >	everything into a thousand singular-directory files and provide
 >	a script to restore it.

 >	And I'm a convert, BTW.  A month ago I didn't like ZOO.  But now....
 >
 >					-Matt

  Up to a few days ago, I hated ZOO with a vengeance. There were a few
reasons for this, like the distribution policy which virtually ensured that
it would be useless to me as a sysop on Compuserve's Amigaforum. A few days
ago, we received an upload of the latest version of ZOO to the Amigaforum
from the author himself, and it did not have the restrictions it previously
had.

  There remains only one small problem. ZOO does not work on any device
that uses the new file system, meaning that I have to ZOO things in VD0:
or RAM: It would seem that extracting files is fine, but that it must go a
little too 'close to the hardware', bypassing the file handler and making
assumptions about disk block contents. A shame. I _almost_ like it now.

And now for something completely different. A small ARexx program called
arcall.rexx, that will recursively go through a directory and rename all
files, generate a script file while doing so, and ARC the entire kabooble
into a file called ARCFILE.ARC. The script file created, (a standard
Amigados script called Exec.me) is included in the ARC, and upon execution,
will make any necessary subdirectories, and rename all files to their
original name and position in the directory structure.

 It is short, so I will include it here, with apologies to the net.gods if
I have misinterpreted the guidelines.

---------- slice here ----------------

/* arcall.rexx 
   by Larry Phillips. Use this code in whatever way you like.
*/

arg root
if right(root,1) ~= ':' then
  root = root || '/'
if root = '/' then root = ''
filecount = 1
dummy = open(execfile,root || 'Exec.me','write')

call renamefiles(root)

say
call close(execfile)
'arc a arcfile *'
exit 0

renamefiles: procedure expose filecount root
  parse arg x
  contents = showdir(x);
  do i = 1 to words(contents)
    temp = x || word(contents,i)
    select
      when word(statef(temp),1) = 'FILE' then do
        rename temp root || 'File' || filecount
        call writeln(execfile,'rename File' || filecount x || word(contents,i))
        call writech(stdout,'.')
        filecount = filecount + 1
        end
      when word(statef(temp),1) = 'DIR' then do
        call writeln(execfile,'')
        call writeln(execfile,'makedir' temp)
        call renamefiles(temp || '/')
      end
      otherwise do
        if translate(temp) = 'EXEC.ME' then break
        else say 'Error: File' temp 'is neither DIR nor FILE.'
      end
    end
  end
  call writeln(execfile,'')
return 0

---------- slice here - end of program ----------------

Enjoy

-larry

--
Janus? Well, look at it this way. If you squint a little, the J could be
       Amiga checkmark, and the rest of the word describes MsDos.
+----------------------------------------------------------------+ 
|   //   Larry Phillips                                          |
| \X/    {ihnp4!alberta!ubc-vision,uunet}!van-bc!lpami!lphillips |
|        COMPUSERVE: 76703,4322                                  |
+----------------------------------------------------------------+

dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/15/88)

>USENET and UNIX people are familiar with the uuencode/uudecode.
>
>BBS users, Amiga Users' Groups, etc. are familiar with ARC and ZOO.

	Well I wouldn't put it quite that way... after all, you can't send
raw ARC or ZOO files over the USENET anyway... most people uuencode the
ARC/ZOO file and send that.  So no argument there.  You don't see uuencode
on BBS's because its sole purpose in life is to turn binaries into 
ascii-mailer-readable files, and that's just a waste of space on a BBS.

>But let's remember that MOST people have just ONE computer (and let's hope
>that it's an Amiga! :-), and said users WILL have ARC and ZOO readily
>available.

	Or can get them off just about any BBS, ARPA archive, or
sources/binaries group whenever they want!

				-Matt

kent@xanth.cs.odu.edu (Kent Paul Dolan) (05/15/88)

I want to petition for zoo's for everything.  Having the file names
and the directory structure be maintained is just too valuable a
feature to give up for the pitifully small chance that I can make a
repair that even I trust to a source file that lost a couple of
characters along the way.  I download with kermit, which does a CRC
check on each packet, and if the file got to my host OK, it gets to me
OK.  If it didn't, the host folks reacquire it and I wait a few days.
It took 15 hours over 2 days to rebuild the ARP 1.1 stuff because the
file structure and name space are destroyed as it was released, and I
rebuilt it on a Unix system, where there was lots of space, rather
than my 512K two floppy home Amiga system.  When I got it all right, I
dwnloaded it (perfectly, of course, despite some of the noisiest phone
lines imaginable - good old kermit!) and built it onto another disk
with a single command (and twenty minutes of grinding noise
competitions between the drives ;-).

If the files had all been distributed as a big zoo, I could have
skipped the intermediate step.

Marco, who can't get hold of zoo, arc, compress, sq and all the other
stuff I use every day?  They are freely distributed around the world
for Amigas, and we have all but sq on the VAX here as well.  I build
zoos to send out on the vax, rather than hauling stuff home, zooing it
here, and uploading it again.  Easy as pie.

Kent, the man from xanth.

nic@dworld.UUCP (Nic Bernstein) (05/15/88)

	I guess I agree with the general concensus that all postings should
    have SHAR as their outer layer, binaries must be uuencoded, and I can
    even live with ARC or ZOO on sources.  The one thing that drives me
    crazy, however, is filenames > 13 chars.  I understand that many of you
    AmigaGods are using BSD machines, but unless someone wants to send me a
    free port of 4.3BSD for the AT&T 3b1, I'm stuck with the Sys V filename
    maxlen.  It can be a real pain in the ars when the only difference
    between several files in a set are in the end of a too long filename,
    ie: dnet.amiga.zoo.uu.aa
	dnet.amiga.zoo.uu.ab
	dnet.amiga.zoo.uu.ac
	dnet.amiga.zoo.uu.ac
    on my Sys V machine after doing an Unshar * in the dnet directory, I
    get:
	dnet.amiga.zoo

	This sort of thing happens far too often.  I find it handy to be
    able to unshar and uudecode and then ARC stuff on my news machine, at
    work, before transferring it at 1200 baud to my Amiga at home.
    Sometimes this can result in a time savings of a half hour or so when
    downloading a few days worth of stuff.

	While I'm at it, thanks for all the great software Matt!
    

-- 
"You can't spend your history!"		Nic Bernstein
	Melinda Briggerty		Discovery World Museum
"... but you can sell it!"		818 W. Wisconsin av.
	Me				Milwaukee, WI 53233
____________________________________________________________________________
		{uunet|uwmcsd1|gryphon}!marque{!introl}!dworld!nic
____________________________________________________________________________

gaspar@almsa-1.arpa (Al Gaspar) (05/16/88)

Scott Evernden <scott@applix.uucp> writes:

> Is there a version of ZOO for unix?  I really hate it when I dload
> a 400K .zoo file to my amiga (via 1200 baud modem) only to discover 1)
> that it contains stuff I don't want, or 2) that the
> "(FL4m{{i{i"R$``!>0<" on line 5293 in the .uu file should have been
> a "(FL48-!@2B"R$``!>0<".
>
> At lease I can unwrap .arc files on my sun...
>
> -scott

Zoo is available for UNIX.  You can obtain the latest version by
anonymous ftp to uunet.uu.net or you can send a message to
netlib@uunet.uu.net.  If you send a message, use 'send info' as
your subject line and you'll get the details on how to get sources.
Zoo (source) is in 7 parts in volume 11 of the archives.  I hope this
helps.

Cheers--

Al

lphillips@lpami.van-bc.UUCP (Larry Phillips) (05/16/88)

In <9037@oberon.USC.EDU>, papa@pollux.usc.edu (Marco Papa) writes:
>I second Chuck's point: sources should be SOURCES, binaries should be
>BINARIES. Both should be SHARed.  Binaries should be UUENCODED and not
>ARCed or ZOOed, at least in general since EVERYBODY has uuencode/uudecode
>(on both UNIX and Amiga) while the same is not true fo the other two programs.

Whatcha gonna do with Amiga binaries on your Unix machine Marco?

-larry

--
Janus? Well, look at it this way. If you squint a little, the J could be
       Amiga checkmark, and the rest of the word describes MsDos.
+----------------------------------------------------------------+ 
|   //   Larry Phillips                                          |
| \X/    {ihnp4!alberta!ubc-vision,uunet}!van-bc!lpami!lphillips |
|        COMPUSERVE: 76703,4322                                  |
+----------------------------------------------------------------+

jw@sics.se (Johan Widen) (05/16/88)

>I like to do some unpacking on UNIX before shipping stuff down. But if
>it's arced or zooed I'm out of luck. No source to zoo, and ironically the
>UNIX version of arc is allergic to braindamaged intel architectures!

The UNIX sources for zoo appeared in comp.sources.unix or
comp.sources.misc (not sure which one) in August 1987. Works too.

You should be able to get a copy from a site near you.
--
Johan Widen
SICS, PO Box 1263, S-164 28 KISTA, SWEDEN
Tel: +46 8 752 15 32	Ttx: 812 61 54 SICS S	Fax: +46 8 751 72 30
Internet: jw@sics.se or {mcvax,munnari,ukc,unido}!enea!sics.se!jw

gore@eecs.nwu.edu (Jacob Gore) (05/17/88)

/ comp.sys.amiga / dillon@CORY.BERKELEY.EDU (Matt Dillon) / May 12, 1988 /
>	... When the distribution requires a 
>	directory structure to be maintained, or has lots of files with
>	long filenames, ZOO should be used...

Why?  Can't a shar contain "create directory" commands?  And what's wrong with
long filenames?

Jacob Gore				Gore@EECS.NWU.Edu
Northwestern Univ., EECS Dept.		{oddjob,gargoyle,ihnp4}!nucsrl!gore

ins_adjb@jhunix.HCF.JHU.EDU (Daniel Jay Barrett) (05/17/88)

Since lots of people have mentioned the lack of a UNIX version of ZOO,
I thought I'd tell you that there IS one.  I got it from the following
machine:

		128.174.5.54	uxe.cso.uiuc.edu

I believe the directory name is something like amiga/zoo.  Anonymous
ftp works fine.

This machine also has a large selection of PD Amiga software, arranged
by Fish Disk.

-- 
Dan Barrett	ins_adjb@jhunix.UUCP
		barrett@cs.jhu.edu

plouff@nac.dec.com (Wes Plouff) (05/18/88)

[Sorry, can only reply by mail to Usenet postings]

Matt Dillon (dillon@cory.berkeley.edu) complained
 
 >	This is why DNET is being distributed on sources as a uuencoded
 >	ZOO archive...  There is no other way to maintain the directory
 >	structure and I wasn't about to hand-generate the ARCs or split
 >	everything into a thousand singular-directory files and provide
 >	a script to restore it.

Hmm...  I get postings on a VAX running VMS.  So now I must dig out a 
VMS version of ZOO from somewhere in order to extract docs, look the 
files over, etc, without down- and up-loading to my Amiga.  It would 
also be nice to attempt a VMS port of DNET.  So let's look at the Unix 
end of the sources.  Oh, they're in TAR format?  VMS TAR?  Right, harder 
digging if I'm to make any use of this stuff at all.

As David Herron (david@ms.uky.edu) says, in a different context,
 
>Usenet is growing beyond its Unix starting points.  We have IBM mainframes
>which are full news partners/participants, nntp based news readers for 
>tops-20, vms, and symbolics lisp machines, and a number of other developments.

UUencoding versus plaintext is not a big issue to me, but please, PLEASE
don't introduce other encodings just because it is convenient, unless
the coding tools are widely available on non-Unix systems.  Rich Salz
does an excellent job on multi-directory postings to comp.sources.unix
using rather nice shell scripts (which our 'shar' can interpret).  With 
creative use of Amiga tools like 'arcre' it just can't be that hard to 
put together a reasonable package using only standard commands.

Aside to .sources. moderators: this is a small failing in your otherwise 
excellent handling of the moderated newsgroups.

-- 
Wes Plouff				plouff%nac.dec@decwrl.dec.com
Digital Equipment Corp, Littleton, Mass.	or ...!decwrl!nac!plouff

thad@cup.portal.com (05/18/88)

Mostly to Nic Berstein:

If you'd like to be a pioneer (quote,unquote), look at the UNIX-PC newsgroup
on Usenet ... there have been solutions proposed to permit longer filenames
than the SysV 14 character limitation.  We're investigating this locally
("we" == the informal SIG of the AT&T Users' Group).

page@swan.ulowell.edu (Bob Page) (05/18/88)

I don't care how the files come across, just get 'em to me.
Personally, I'm for a comp.programs.amiga, where you get the whole
distribution.  These days of doc files in 8-bit ASCII, icons and other
non-7-bit ASCII; it doesn't make a lot of sense to distiguish.

lphillips@lpami.van-bc.UUCP (Larry Phillips) wrote:
>Whatcha gonna do with Amiga binaries on your Unix machine Marco?

I'll tell you what I do:
	1. Make them available for Amiga NFS access
	2. Make them avaliable for anonymous FTP over the Internet
	3. Disassemble them (yep! for my own amusement)

..Bob
-- 
Bob Page, U of Lowell CS Dept.  page@swan.ulowell.edu  ulowell!page

darin@laic.UUCP (Darin Johnson) (05/19/88)

In article <1764@van-bc.UUCP>, lphillips@lpami.van-bc.UUCP (Larry Phillips) writes:
> 
>In <9037@oberon.USC.EDU>, papa@pollux.usc.edu (Marco Papa) writes:
>>I second Chuck's point: sources should be SOURCES, binaries should be
>>BINARIES. Both should be SHARed.  Binaries should be UUENCODED and not
>>ARCed or ZOOed, at least in general since EVERYBODY has uuencode/uudecode
>>(on both UNIX and Amiga) while the same is not true fo the other two programs.

I used zoo on both my Amiga and Unix system to 'extract' the DNET stuff (after
poking around everywhere for a zoo for unix).  Turns out that on BOTH the Amiga
and the Unix machine, ZOO failed to keep the directory structure!!  Oh, well,
zoo -list told me what to put where, and it was cheaper than running down to
the store to see if there was a later vesion of zoo on a fish disk and forking
over 3 bucks.
-- 
Darin Johnson (...lll-lcc.arpa!leadsv!laic!darin)
              (...ucbvax!sun!sunncal!leadsv!laic!darin)
	"All aboard the DOOMED express!"

kim@amdahl.uts.amdahl.com (Kim DeVaughn) (05/19/88)

In article <7142@swan.ulowell.edu>, page@swan.ulowell.edu (Bob Page) writes:
>
> I don't care how the files come across, just get 'em to me.
> Personally, I'm for a comp.programs.amiga, where you get the whole
> distribution.

Yeah ... I think this is a good idea too!  'Twould make the moderator's
job a little easier, and eliminate the duplication of the "doc" file(s)
that is being done now (in many cases).  That, to me, seems to be a
real waste of net bandwidth, and I think it should be stopped.

/kim


-- 
UUCP:  kim@amdahl.amdahl.com
  or:  {sun,decwrl,hplabs,pyramid,ihnp4,uunet,oliveb,cbosgd,ames}!amdahl!kim
DDD:   408-746-8462
USPS:  Amdahl Corp.  M/S 249,  1250 E. Arques Av,  Sunnyvale, CA 94086
CIS:   76535,25

dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/19/88)

>and the Unix machine, ZOO failed to keep the directory structure!!  Oh, well,
>zoo -list told me what to put where, and it was cheaper than running down to
>the store to see if there was a later vesion of zoo on a fish disk and forking
>over 3 bucks.

	Oh no!

	I believe the proper extraction command line is:

	zoo x// blah.zoo

	where // (I think) means 'extract into the original directory
	structure and create directories as you go'.

				-Matt

jbwaters@bsu-cs.UUCP (J. Brian Waters) (05/20/88)

In article <1758@van-bc.UUCP>, lphillips@lpami.van-bc.UUCP (Larry Phillips) writes:
> 
>   There remains only one small problem. ZOO does not work on any device
> that uses the new file system, meaning that I have to ZOO things in VD0:
> or RAM: It would seem that extracting files is fine, but that it must go a
> little too 'close to the hardware', bypassing the file handler and making
> assumptions about disk block contents. A shame. I _almost_ like it now.
>

   All the file io in the Amiga version of zoo is done through either the
dos.library,  stdio routines from the C compiler and one use of a packet
(the setdate packet that was added in 1.2).  It does nothing that bypasses
the handler and makes no assumptions about the disk block.

   As soon as I get a way to test out zoo with the fast file system I will
verify and correct any problems with it.  By the way I have only recieved
two bug reports since zoo has been distributed for the Amiga.  I am sure more
people than that have found problems.  I can only fix things that I know about
and I do not have time to read all the comp.sys.amiga messages.  If you find
something about the Amiga version of zoo and would like to make sure a feature
you want is considered or a bug fixed please mail it to me. 

 
-- 
Brian Waters              <backbone>!---\ 
                                   ihnp4!{iuvax|pur-ee}!bsu-cs!jbwaters
                                              uunet!---/

ncreed@ndsuvax.UUCP (Walter Reed) (05/20/88)

In article <247@laic.UUCP> darin@laic.UUCP (Darin Johnson) writes:
>I used zoo on both my Amiga and Unix system to 'extract' the DNET stuff (after
>poking around everywhere for a zoo for unix).  Turns out that on BOTH the Amiga
>and the Unix machine, ZOO failed to keep the directory structure!!  Oh, well,
>Darin Johnson (...lll-lcc.arpa!leadsv!laic!darin)

Are you sure you used zoo correctly?  If you don't specify that you want
directory structure to be used, it will put all the files in one directory.
What you should be using is Zoo x// zooarchive.zoo *
The x// is eXtract with full pathnames.  Hope this helps!
-- 
------  Walter Reed  ------   + uunet!ndsuvax!ncreed or ncreed@ndsuvax.BITNET
"There's no point in being    +      or ncreed%NDSUVAX.BITNET@CUNYVM.CUNY.EDU 
 grown up if you can't be     + Phone: (701) 235-0774  
 childish sometimes!" Dr. Who + USnAIL: 1430 12 Ave N.  Fargo, ND 58102

phil@titan.rice.edu (William LeFebvre) (05/21/88)

In article <1764@van-bc.UUCP> lphillips@lpami.van-bc.UUCP (Larry Phillips) writes:
>
>In <9037@oberon.USC.EDU>, papa@pollux.usc.edu (Marco Papa) writes:
>>Binaries should be UUENCODED and not
>>ARCed or ZOOed, at least in general since EVERYBODY has uuencode/uudecode
>>(on both UNIX and Amiga)...
>
>Whatcha gonna do with Amiga binaries on your Unix machine Marco?

Download them.  With kermit in binary mode, of course.  I do it all the
time.  It's faster....less bytes to move.  Makes a big difference at 1200
baud.  Also, uudecode is faster on a Sun 3 than on my Amy.

			William LeFebvre
			Department of Computer Science
			Rice University
			<phil@Rice.edu>

lphillips@lpami.van-bc.UUCP (Larry Phillips) (05/21/88)

In <3143@bsu-cs.UUCP>, jbwaters@bsu-cs.UUCP (J. Brian Waters) writes:
>In article <1758@van-bc.UUCP>, lphillips@lpami.van-bc.UUCP (Larry Phillips) writes:
>>   There remains only one small problem. ZOO does not work on any device
>> that uses the new file system ...
>
>   All the file io in the Amiga version of zoo is done through either the
>dos.library,  stdio routines from the C compiler and one use of a packet
>(the setdate packet that was added in 1.2).  It does nothing that bypasses
>the handler and makes no assumptions about the disk block.

 Fascinating. I'm glad you posted this. I couldn't see any reason for you
to bypass the handler, and it's a relief to hear you didn't. It does,
however, bring up the question of what's broken. Could it be one of the
stdio calls in the compiler?

 As far as I've been able to see (I didn't spend a lot of time on it), the
new file system differs only in the data blocks themselves, having no
pointers or checksum info, and 512 bytes of pure data. Hope you figure it
out.

  While I have you on the line, I want to thank you for removing the
restrictions concerning the posting of Zoo on commercial services.

-larry

--
Janus? Well, look at it this way. If you squint a little, the J could be
       Amiga checkmark, and the rest of the word describes MsDos.
+----------------------------------------------------------------+ 
|   //   Larry Phillips                                          |
| \X/    {ihnp4!alberta!ubc-vision,uunet}!van-bc!lpami!lphillips |
|        COMPUSERVE: 76703,4322                                  |
+----------------------------------------------------------------+

lphillips@lpami.van-bc.UUCP (Larry Phillips) (05/27/88)

In <710@thalia.rice.edu>, phil@titan.rice.edu (William LeFebvre) writes:
>In article <1764@van-bc.UUCP> lphillips@lpami.van-bc.UUCP (Larry Phillips) writes:
>>Whatcha gonna do with Amiga binaries on your Unix machine Marco?

>Download them.  With kermit in binary mode, of course.  I do it all the
>time.  It's faster....less bytes to move.  Makes a big difference at 1200
>baud.  Also, uudecode is faster on a Sun 3 than on my Amy.

Fair enough. I don't bother with that, as I have plenty of time at home on
my Amiga, and too much to do at work on my Sun (like reading SunSpots...
nice job you're doing on that William). In addition, I get my
comp.xxx.amiga at home, at 2400 baud, so I just tend to think that most
people do I guess.

>			William LeFebvre

-larry

--
If all the MSDos machines were laid end to end,
  they still wouldn't be as fun as a single Amiga.
+----------------------------------------------------------------+ 
|   //   Larry Phillips                                          |
| \X/    {ihnp4!alberta!ubc-vision,uunet}!van-bc!lpami!lphillips |
|        COMPUSERVE: 76703,4322                                  |
+----------------------------------------------------------------+