[comp.sys.mac] Naming your Stuffit-packages

hv@uwasa.fi (Harri Valkama LAKE) (03/14/90)

I'm not flaming Mac OS or it's file naming policy:-

But what I want to do is PLEASE pay attention to the
naming of binhexed Stuffit files. At least if you are 
starting to spread a Stuffit file to ftp sites or BBSs.
Please use a little easier file names that is file 
names which dont't have spaces or exclamation or
commas or what ever more unusual characters because
I (and I think some others might as well) use to
unbinhex them in Unix machine and it is not very fun
to rename these (hopefully it can be done...) to more
familiar looking names. Let's assume for example that
you upload a binhexed Stuffit file called
'My Favourite Utilities v1.0.3d2.hqx'
to somewhere and I found it and decide to have a look
at it. I carefully (write it right and) download it
to our Unix machine and then use xbin to unbinhex it.
What I get is a file called
'MyxFavouritexUtilitiesxv1x0x3d2.sit.bin'
Like it, Huh?

Think about that. Thanks for reading this.

-- 

	----------------Harri Valkama (hv@uwasa.fi)-------------
			University of Vaasa, Finland
	anonymous ftp site (128.214.12.3) PC and Mac directories

ching@pepsi.amd.com (Mike Ching) (03/15/90)

In article <1990Mar14.075223.28847@uwasa.fi> hv@uwasa.fi (Harri Valkama LAKE) writes:
>I'm not flaming Mac OS or it's file naming policy:-
>
>But what I want to do is PLEASE pay attention to the
>naming of binhexed Stuffit files. At least if you are 
>starting to spread a Stuffit file to ftp sites or BBSs.

While we're asking for more thought and work by the stuffer,
I'd like to suggest that people putting together stuffit files help the
rest of us out by stuffing everything into a folder so that unstuffing
will result in a single folder holding all the files. It's hard to
automate unstuffing multiple archives when folders need to be created.

mike ching

bskendig@phoenix.Princeton.EDU (Brian Kendig) (03/16/90)

In article <29500@amdcad.AMD.COM> ching@pepsi.AMD.COM (Mike Ching) writes:
>While we're asking for more thought and work by the stuffer,
>I'd like to suggest that people putting together stuffit files help the
>rest of us out by stuffing everything into a folder so that unstuffing
>will result in a single folder holding all the files. It's hard to
>automate unstuffing multiple archives when folders need to be created.

... and I'd like to suggest that people putting together Stuffit files
please refrain form sticking everything into a folder.  If it's in a
folder, and it takes a half-hour to unStuff, then it'll report that
it's 0% complete until the very end.  When it's only dealing with
separate files, its report of how far it still has to go is more
accurate.

     << Brian >>
-- 
| Brian S. Kendig      \ Macintosh |   Engineering,   | bskendig             |
| Computer Engineering |\ Thought  |  USS Enterprise  | @phoenix.Princeton.EDU
| Princeton University |_\ Police  | -= NCC-1701-D =- | @PUCC.BITNET         |
... s l o w l y,  s l o w l y,  w i t h  t h e  v e l o c i t y  o f  l o v e.

jsimon@voodoo.ucsb.edu (03/16/90)

-Message-Text-Follows-
And I'd like also to ask people to freely use spaces when naming files that
are stuffed or binhexed.  Spaces make file names much much easier to read,
and the Mac lets you use them, so their use should be encouraged, not the
other way around.  I don't want to be restricted by unenlightened operating
systems.

Just an opinion

Jonathan Simon

escher@Apple.COM (Michael Crawford) (03/16/90)

In article <4338@hub.UUCP> jsimon@voodoo.ucsb.edu writes:
>-Message-Text-Follows-
>And I'd like also to ask people to freely use spaces when naming files that
>are stuffed or binhexed.  Spaces make file names much much easier to read,
>and the Mac lets you use them, so their use should be encouraged, not the
>other way around.  I don't want to be restricted by unenlightened operating
>systems.

Well, the whole point of Binhex is to get files through "unenlightened"
transmission media, and stuffit puts all its info in the data fork so the
Unbinhexed files may be stored on filesystem without resource forks (one loses
the creator and type, if it is not stored in Macbinary, but this may be 
fixed with resedit).

Now, operating systems may have file systems that limit filenames to 15 or
8 characters, may not be case sensitive, (as the mac isn't but Unix is), 
may not preserve case (as DOS and VMS don't).  The usual mapping of long to
short filenames is to truncate or garble the last characters, thus eliminating
the .sit, .bin, or .hqx extension.

Now, many of our shareware files are distributed via billboards which are
administrated part time, and provided at the expense of the administrator,
who has to put the files on his disk using whatever OS he has.

Many of us download files of the Internet via ftp and un-binhex them on
Unix systems, as it is more convenient to use shell scripts for this, and
minimize the amount of stuff that has to be left lying around on the Mac
disk in the process.

If our objective is the free transmission of files through foreign transmission
media, then we should be considerate and use short, all-one-case filenames,
without spaces, without '.' extensions more than three letters, and without
characters that are metacharacters in any common shell.

The names of the files withing a Stuffit archive may be anything appropriate
to a Mac; we would not expect files to be unstuffed on Unix (or would we?).
-- 
Michael D. Crawford
Oddball Enterprises
694 Nobel Drive
Santa Cruz, CA 95060
oddball!mike@ucscc.ucsc.edu

Consulting for Apple Computer Inc.
escher@apple.com

The opinions expressed here are solely my own.

ching@pepsi.amd.com (Mike Ching) (03/16/90)

In article <14573@phoenix.Princeton.EDU> bskendig@phoenix.Princeton.EDU (Brian Kendig) writes:
>
>... and I'd like to suggest that people putting together Stuffit files
>please refrain form sticking everything into a folder.  If it's in a
>folder, and it takes a half-hour to unStuff, then it'll report that
>it's 0% complete until the very end.  When it's only dealing with
>separate files, its report of how far it still has to go is more
>accurate.
>


To each his own. Since the majority of what is posted doesn't take a
half-hour to unstuff, I find the progress indicator to be of limited
value. The answer is probably an improved UnStuffit but that will be
reserved for the commercial version in all likelyhood.

mike ching

meisner@SRC.Honeywell.COM (John Meisner) (03/16/90)

In article <14573@phoenix.Princeton.EDU> bskendig@phoenix.Princeton.EDU (Brian Kendig) writes:
>... and I'd like to suggest that people putting together Stuffit files
>please refrain form sticking everything into a folder.  If it's in a
>folder, and it takes a half-hour to unStuff, then it'll report that
>it's 0% complete until the very end.  When it's only dealing with
>separate files, its report of how far it still has to go is more
>accurate.
>
>     << Brian >>

I prefer that the files be placed in a single folder.  If I download
a number of StuffIt files, I can select all of them and unstuff
them at one time while I go do something else.

If all the files are at the top level, then I have to later figure
out which files go with which application.  Not earth shattering
work, but work I'd rather not do.

john

John Meisner                                (612) 782-7268
POST:  Honeywell M/S MN65-2500; 3660 Technology Drive; Mpls, MN 55418
INTER-NET:  meisner@src.honeywell.com
UUCP:  {umn-cs,ems,bthpyd}!srcsip!meisner   or   meisner@srcsip.uucp

long@mcntsh.enet.dec.com (Rich Long) (03/17/90)

In article <4338@hub.UUCP>, jsimon@voodoo.ucsb.edu writes...
[about Stuffit Archive conventions]

Please also name the documentation files meaningfully.  Often, after a batch
de-stuff I end up with applications like Foo Bar v2.0 and Gym Shorts v4.3 and
two Read Me files!  

Either that, or put the files in a folder before stuffing.

Please, please, also format documentation for the small screen Macs, not the
Mac II size.  Formatting for a large monitor makes it very difficult to deal
with documentation that contains columns.  

Thanks!

-------------------------------------------------------------------------------
 /'')  /'~  /   | long@mcntsh.enet.dec.com            | Ramparts are parts of a
/''\  /,,  /,,  | ...!decwrl!mcntsh.enet.dec.com!long |  ram.  People used to
Richard C. Long | long%mcntsh.dec@decwrl.enet.dec.com |  watch o'er them.    

dave@PRC.Unisys.COM (David Lee Matuszek) (03/17/90)

In article <14573@phoenix.Princeton.EDU> bskendig@phoenix.Princeton.EDU (Brian Kendig) writes:

>... and I'd like to suggest that people putting together Stuffit files
>please refrain form sticking everything into a folder.  If it's in a
>folder, and it takes a half-hour to unStuff, then it'll report that
>it's 0% complete until the very end.  When it's only dealing with
>separate files, its report of how far it still has to go is more
>accurate.

... and I'd like to suggest that people putting together Stuffit files
please stick everything into a folder.

Currently, the only reasonable thing to do after downloading a number
of files is to make a folder for each one, put each in its respective
folder, and then unStuff each.  Otherwise you end up with a lot of
files to sort through and try to remember which files go together.

I hadn't noticed that Stuffit reports 0% done for folders.  If so,
this is a bug, and should be reported to StuffIt's author (Ray Lau, if
I recall correctly).  But then, I've never tried to unStuff anything
that took more than a few minutes.

If you would prefer not to put everything into a folder, then at least
think of better file names.  Instead of MacFoo, file, doc, and README,
how about MacFoo, MacFoo file, MacFoo doc, and MacFoo README.
-- Dave Matuszek (dave@prc.unisys.com)
-- Unisys Corp. / Paoli Research Center / PO Box 517 / Paoli PA  19301
-- Any resemblance between my opinions and those of my employer is improbable.
  << Those who fail to learn from Unix are doomed to repeat it. >>

hirchert@ux1.cso.uiuc.edu (Kurt Hirchert) (03/17/90)

1. I prefer readable names.  If you're running a binhex equivalent on a
   machine other than a Mac, then that program should put the correct
   Mac name in the MacBinary output and name the file containing that
   MacBinary as needed to conform to the requirements of that other machine.

2. I would like StuffIt to have the option to create a folder, but I would
   prefer you not to force that on me.  Sometimes I want to look at the
   documentation or README file on a program without extracting the whole
   mess.  Forcing the folder prevents me from doing that.

Since both of the above opinions are at odds with previous postings, it should
be obvious that no one form meets the needs of all recipients.
-- 
Kurt W. Hirchert     hirchert@ncsa.uiuc.edu
National Center for Supercomputing Applications

ramsey@rbdc (Ramsey Dow) (03/17/90)

A third "while we're at it."  If the application is machine-specific then
_say_so_!!  It's really irritating to FTP a 200k application and then down-
load it to my SE and then unbinhex/unstuffit only to discover that the
blasted thing requires a Mac II.  Grrr.  Please, if an application is for
Mac II's _only_ then say so!  If it will work on Pluses and SEs then say so!

An irate downloader...
-- 
    My damnable, reddening vision    |Ramsey Dow, starving undergraduate
That build a new world for my seeing;|UUCP: {...}gatech!kd4nc!rbdc!ramsey
A new world of reddness and darkness,|-or-  gatech!kd4nc!rbdc!macpunk!ramsey
A horrible coma called living.  --HPL|ARPA: woodward@orc.bgsm.wfu.edu

allbery@NCoast.ORG (Brandon S. Allbery) (03/19/90)

As quoted from <1990Mar16.212328.10063@ux1.cso.uiuc.edu> by hirchert@ux1.cso.uiuc.edu (Kurt Hirchert):
+---------------
| 2. I would like StuffIt to have the option to create a folder, but I would
|    prefer you not to force that on me.  Sometimes I want to look at the
|    documentation or README file on a program without extracting the whole
|    mess.  Forcing the folder prevents me from doing that.
+---------------

This one could be solved by having something (option-click on folder?) expand
the folder's contents in the archive listing; then select items as usual.
This gives the user the option of extracting the entire folder with a
double-click or extracting single items from the folder in the usual way.

++Brandon
-- 
Brandon S. Allbery (human), allbery@NCoast.ORG (Inet), BALLBERY (MCI Mail)
ALLBERY (Delphi), uunet!cwjcc.cwru.edu!ncoast!allbery (UUCP), B.ALLBERY (GEnie)
BrandonA (A-Online) ("...and a partridge in a pear tree!" ;-)

george@swbatl.sbc.com (George D. Nincehelser) (03/19/90)

In article <1990Mar19.011421.1471@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery) writes:
>As quoted from <1990Mar16.212328.10063@ux1.cso.uiuc.edu> by hirchert@ux1.cso.uiuc.edu (Kurt Hirchert):
>+---------------
>| 2. I would like StuffIt to have the option to create a folder, but I would
>|    prefer you not to force that on me.  Sometimes I want to look at the
>|    documentation or README file on a program without extracting the whole
>|    mess.  Forcing the folder prevents me from doing that.
>+---------------
>
>This one could be solved by having something (option-click on folder?) expand
>the folder's contents in the archive listing; then select items as usual.
>This gives the user the option of extracting the entire folder with a
>double-click or extracting single items from the folder in the usual way.
>
>++Brandon

Another option is to use Boomerang to create a new folder.  A 
command-n enter-foldername sequence works great, but it doesn't do
you much good for the "batch" unstuffing option.

-- 
   /   George D. Nincehelser           \  uunet!swbatl!george       \
  / /   Southwestern Bell Telephone     \  Phone: (314) 235-6544     \
 / / /   Advanced Technology Laboratory  \  Fax:  (314) 235-5797      \
/ / / /\  1010 Pine, St. Louis, MO 63101  \  de asini umbra disceptare \

ldg@yoda.byu.edu (03/20/90)

In <1990Mar19.011421.1471@NCoast.ORG>, Brandon S. Allbery writes:

>+---------------
>| 2. I would like StuffIt to have the option to create a folder, but I would
>|    prefer you not to force that on me.  Sometimes I want to look at the
>|    documentation or README file on a program without extracting the whole
>|    mess.  Forcing the folder prevents me from doing that.
>+---------------
>
>This one could be solved by having something (option-click on folder?) expand
>the folder's contents in the archive listing; then select items as usual.
>This gives the user the option of extracting the entire folder with a
>double-click or extracting single items from the folder in the usual way.

How about sticking everything in a folder, then duplicating the descriptive
text file and Stuffing it along with the folder? That way, you could read
the text file to decide if you want to UnStuff the whole works, but could
also do the batch method if you prefer. If you used the batch method, the
extra text files would all be outside the folders and could easily be deleted
all at once.

Lyle D. Gunderson  N6KSZ          CIS: 73760,2354     GEnie: L.GUNDERSON
ldg@yoda.byu.edu                "Any technology without some attendant risk
350 CB / BYU / Provo, UT 84602   of misuse is probably trivial"  --Louise Kohl