I'm having some major problems with PackageMaker and I have some clues
that might help figure out what's going on. I have an app I created
from an Applescript, I saved it as an application. Using "Get Info" in
Finder tells me that it's 60 KB. Using Terminal "ls -l" tells me that
the exact same app is 13780 bytes large... that's the first strange
part (apps created with applescript apparently aren't folders like
regular apps). Now I've created a package using PackageMaker which
just installs that app to the /Applications directory. I changed the
permissions to rwxrwxr-x, chown'ed the owner to root, and group to
admin per tutorials on PackageMaker. So I build the package... When I
run it and it supposedly installs, I get an app in the /Applications
folder with an icon with a circle & line through it. When I try and
run it, it says, "You can't open the application 'MyApp' because the
Classic environment is no longer supported." The file size in Finder
now says it's 16KB large compared to the 60KB file I added to the
package (but remember in Terminal it always said it was 16KB). Now if
I manually copy the app to the /Applications folder, it works fine.
FYI - I am using a PowerPC notebook with 10.5.2 installed, fully
updated. Any ideas as to why the filesize is different depending on
what I use to view it? And any ideas why it's copying an apparently
corrupt file to the /Applications folder?  I honestly don't understand
why it's so difficult for PackageMaker to do something as simple as a
copy & paste.

BTW, I have to do this with an installer because I have plug-ins that
need to be installed elsewhere.

In article
<fca95fa1-468e-449c-8b99-fd3acd46e...@y18g2000pre.googlegroups.com>,

ls doesn't show you the size of the resource fork.

"Regular" apps may or may not be packages. Script Editor gives you an
explicit choice between an app and an app-package. The latter will be
native on x86, the former is always PPC.

IIRC, PackageMaker creates documents that by default have "Discard
Resource Forks" turned on. Look at the Contents tab of your pmproj file.
Alternatively, changing your saved script to an app package instead of
just an app might also solve the issue. I suspect it would, but don't
know for sure.

G

--
"Harry?" Ron's voice was a mere whisper. "Do you smell something ... burning?"
   - Harry Potter and the Odor of the Phoenix

In article <uce-D1A7D1.14025630042...@newsclstr03.news.prodigy.net>,
 Gregory Weston <u...@splook.com> wrote:

True in this case, but note that you can append /rsrc to any filename to
view the resource fork of the file. Enter this single-line command to
see it in action:

find ~/Library/Preferences -exec ls -l '{}/rsrc' \; 2> /dev/null | awk
'{print $5, $9}' | grep -v ^0

--
Please send all responses to the relevant news group. E-mail sent to
this address may be devoured by my very hungry SPAM filter. I do not
read posts from Google Groups. Use a real news reader if you want me to
see your posts.

JR

Thanks for the help.  Saving it as an "app package" seemed to do the
trick although I had to make the destination /Applications/MyApp.app
instead of just /Applications for some reason.  Didn't have to do that
before even though the file was bad like I explained.  Anyways I'm
just happy it worked.

In article
<d886bff3-7393-45b3-b1e3-c05cd8b4f...@a9g2000prl.googlegroups.com>,

Application bundles must have an "app" extension. That's part of how the
shell knows how to treat that particular folder.

--
"Harry?" Ron's voice was a mere whisper. "Do you smell something ... burning?"
   - Harry Potter and the Odor of the Phoenix

In article <slrng1ud2b.15qa.g.kr...@cerebus.local>,

No it doesn't. Not unless told to explicitly (by an inobvious
technique), in which case it won't tell you the size of the data fork.
If you have a file with content in both forks, there is no *single*
invocation of ls that will give you the same number that the Get Info
window will.

--
"Harry?" Ron's voice was a mere whisper. "Do you smell something ... burning?"
   - Harry Potter and the Odor of the Phoenix

In article <slrng1v9gb.15qa.g.kr...@cerebus.local>,

No, I agree that it *can* if manipulated in a certain way that fewer
people are aware of than you seem to think. It'll tell you the size of
the resource fork by asking it to list the information on a different
file - one that doesn't actually have any logically separate existence,
and the physical existence of which is virtually impossible for a
mainstream user to verify even if they have heard of resource forks and
aren't under the misimpression that they've been excised from OS X.

Well-known in certain circles. Not obvious and not well-documented. Also
not historically stable and not scaleable. Did you know the OS supports
arbitrary named forks? Do you know how a typical user may find out the
names of the existing forks for any given directory entry?

For certain definitions of "incorrect" perhaps.

And it's what I said. So happy day.

Oh, excellent. After all this you illustrate the *deprecated* notation.
The supported name has been file.html/..namedfork/rsrc for years. You
want to stand by "well documented and well known" given that you
apparently missed that memo?

--
"Harry?" Ron's voice was a mere whisper. "Do you smell something ... burning?"
   - Harry Potter and the Odor of the Phoenix

In article <slrng23nhl.15qa.g.kr...@cerebus.local>,

ls shows the size of the resource fork associated with a node if and
only if told to show information for a different (synthetic) node that's
not trivially detectable to a typical user. How many other behaviors of
ls are you aware of that are invoked by asking it for information about
a node other than the one in which you're interested?

Go up to a hundred people familiar with Unix-like systems, present them
with the scenario that a file system supports multiple distinct byte
streams for each directory entry but ls by default only shows the
information for the primary stream. Then ask them how they'd expect to
be able to get the information for the additional streams. Most of them
would expect a command-line switch in the vendor's ls implementation.
The rest would expect you're talking about extended attributes and look
for a solution that leverages their prior experiences in that realm. Not
one will start off with: "Well, I'd pretend the file I was interested in
was a directory and blindly type the path of a file with an arbitrarily
chosen name that resides inside that 'directory' hoping that it exists."
It's an idiom that doesn't exist in any other consumer system and is
barely mentioned in any Apple publication, but by your reckoning it's
well-documented and obvious.

I meant stable in the sense of consistent over time. Similar to the way
it's used in the phrase "stable sort." Anyone knowledgeable enough to
take part in this discussion would have recognized that. Be a grown-up,
admit you screwed up and let it go.

What I said is *right*up*there*. A dozen lines away. See what it says?
No single invocation that will give you the same number. You haven't
actually demonstrated otherwise; you've just contradicted and provided a
non-general workaround for that reality. Bummer if there's ever a node
with more forks than data and resource, of course.

Because the method you showed is deprecated and if you were actually
trying to be helpful you'd show the *recommended* way rather than the
one that happens to work but might not for much longer and spews
warnings to the system.log every time it's used. I just found it amusing
that right after claiming that it was well documented and implying that
it was obvious you used a technique that isn't officially reliable.
Surely you can see the humor in that.

Only if you don't mind having to ask for a different node in the file
system than the one in which you're actually interested. A node the
existence of which can only be posited by an educated guess.

G

--
"Harry?" Ron's voice was a mere whisper. "Do you smell something ... burning?"
   - Harry Potter and the Odor of the Phoenix

On Apr 30, 7:40 pm, "mattdor...@gmail.com" <mattdor...@gmail.com>
wrote:

I'm currently having the exact same issue. Aside from just saving the
script as an application, I've also tried saving it as an application
bundle, but Packagemaker scrambles it as well.

My next attempt was at using Automator for the same thing. Automator
has a "run applescript" action, which I added to a new Automat project
and then pasted my script into it. It works well when I run it, but
Packagemaker doesn't even install it even though it pretends to. My
Automator action doesn't even seem to be included in the package that
PackageMaker builds.

For the time being, I have re-written it as a shell script.
Packagemaker doesn't seem to have any issues with them.