Dev Tool Info (man)
 

How does one find out more info about the developer tools similar to what you get in the man pages for standard commands? I know if you type in say, CpMac, you will get the syntax usage:

usage: CpMac [-r] [-p] [-mac] <source-path> <dest-path>
CpMac [-r] [-p] [-mac] <source-path>... <dest-dir>

But I would like a little more info on what the flags and/or options do. I would guess from this that the -r flag is meaning recursive and that the -p flag might mean print. I'm not certain about -mac and what that could be.

If I'm remembering correctly, when I downloaded the most recent dev tools, I elected not to dl the documentation which was something like another 185 MB worth. Maybe that was a mistake if that's where this kind of info is kept?

Someone, please enlighten me.

:confused:

google has a few hits on CpMac

if the 'cp' tool (GNU or otherwise) is considered, then

-p, --preserve
preserve file attributes if possible

-r copy recursively, non-directories as files WARNING:
use -R instead when you might copy special files
like FIFOs or /dev/zero

-mac who knows? could be to capture resource forks

consult google and

%man ditto

Merv, thanks for the reply. So then, there is no more direct way to find out this info for all the dev tools other than a google search for each one? It seems a bit odd to me that Apple would have made up 18 tools for developers without any explanation on how to use them. How did you know about what -p meant with regard to CpMac?

It would make sense to me that all this stuff would be in some documentation somewhere, probably the huge file I mentioned above that I elected not to download. Do you know about what's in that, by chance? Anyone? Or would I have to download them in order to see?

Perhaps a developer who uses these tools commonly could shed some more light onto this for me if I were to post in an area they might frequent. Any suggestions as to where that might be?

TIA!
:rolleyes:

BTW, I did spend some time looking at a Google search for CpMac and did find some interesting info but not directly related to usage and syntax other than the usual cloning and backup stuff and then relating to ditto and a few other commands.

> So then, there is no more direct way to find out this info for all the dev
> tools other than a google search for each one?

Not necessarily. Some tools are doc'd better than others:

% GetFileInfo
usage: GetFileInfo [-a[<attrib-letter>] | -t | -c | -d | -m] <path>

% SetFile
setfile [option...] file...
-a attributes # attributes (lowercase = 0, uppercase = 1)*
-c creator # file creator
-d date # creation date (mm/dd/[yy]yy [hh:mm[:ss] [AM | PM]])*
-m date # modification date (mm/dd/[yy]yy [hh:mm[:ss] [AM | PM]])*
-t type # file type

Note: Period (.) represents the current date and time.

Note: [yy]yy < 100 assumes 20th century, e.g. 19yy

Note: The following attributes may be used with the -a option:
A Alias file
V Invisible*
B Bundle
...

> It seems a bit odd to me that Apple would have made up 18 tools for developers
> without any explanation on how to use them.

Yeah, these docs may be buried in some obscure place, tho. Or not for use by the teeming masses. Who knows?

> How did you know about what -p meant with regard to CpMac?

As I said, if we consider the 'cp' command, and then you refer to the 'cp' man pages, -p = preserve attributes. I don't know if that's the case, I'm just speculating.

> It would make sense to me that all this stuff would be in some documentation
> somewhere, ... Do you know about what's in that, by chance?

It's chock full of more documentation than you'd ever want to read, but cpmac may or may not be doc'd

> Perhaps a developer who uses these tools commonly could shed some more light
> onto this for me if I were to post in an area they might frequent.
> Any suggestions as to where that might be?

Rather than take that route, ask yourself, "what problem am I trying to solve?" other than finding the docs for obscure tools that are not worthy _because_ you can't find their docs.

What I mean is if you can't easily find the docs for a tool, it's not a worthy tool. Flip it, drive on...

Sorry if that sounds gruff, but sometimes you have to fish or cut bait.

Yep, the whole arrangement is a little clumsy: there *are* man pages for some commands (check out the /Developer/Documentation/man directories), but not all. And the tickling of the remaining tools to determine out the required usage is also somewhat variable.

% cd /Developer/Tools

# here are my takes on the tools...
# First the slightly unusual

% cvswrappers | less # ((!!) this describes cvs-wrap/cvs-unwrap philosophy as well)
% ./SplitForks -u

# (output suppressed)

% man SetFile
% man Rez
% man DeRez

# Lots of output suppressed

# similarly for all below...

% ./agvtool
% ./BuildStrings
% ./MvMac
% ./ResMerger
% ./cvs-wrap
% ./cvs-unwrap
% ./MergePef
% ./UnRezWack

Finally the only one that's not ticklish (for me):

pbhelpindexer

# no doubt it just does the obvious job for project builder.
# Maybe worth a look in the pb documentation?

As mT pointed out, these *are* really aimed at Developers. Not really an excuse for the significant kludge factor, but there's a lot of assumed knowledge (such as the -p above). Without meaning this in any way as a put-down, if you're not sure what the -p is for in CpMac it might be better to stick to the regular counterparts for a while to gain familiarity. To a very large extent the whole /Developer/Tools set is simply a way to get functionality familiar to unix developers working when dealing with files for which resource fork preservation is crucial. It's not very exciting, and far from glamorous, so I'm not surprised that resources aren't being poured into touting (or better documenting) this area. PB, IB, and ASS are the sexy branches of the Developer tree!

Cheers,
Paul (your /Developer/Tools documentation one-stop shop)

thanks, paul. smooth as 12 year old single barrel malt.

you be my W.Churchill, i'll be your N.Chamberlain. i'll try and cut down on the goose-stepping.

--
Society Woman: If you were my husband, i'd poison your tea.
W.Churchill: Madam, if you were my wife, i'd drink it.

> Not necessarily. Some tools are doc'd better than others:
...

Thanks for pointing those two and certainly other similar possibilities out.

> Yeah, these docs may be buried in some obscure place, tho. Or not for use by the teeming masses. Who knows?

I would think there's bound to be somebody who has read those docs though.

> As I said, if we consider the 'cp' command, and then you refer to the 'cp' man pages, -p = preserve attributes. I don't know if that's the case, I'm just speculating.

Ahh. I wasn't clear on the speculating part.

> It's chock full of more documentation than you'd ever want to read, but cpmac may or may not be doc'd

Of that I'm sure based on the file size, too much reading for most and possibly not relevant to what I'm looking for.

> Rather than take that route, ask yourself, "what problem am I trying to solve?" other than finding the docs for obscure tools that are not worthy _because_ you can't find their docs.

> What I mean is if you can't easily find the docs for a tool, it's not a worthy tool. Flip it, drive on...

> Sorry if that sounds gruff, but sometimes you have to fish or cut bait.

Merv, I hope I haven't offended you in any way. That was certainly not my intention here. I am relatively new to all this and a forum by this name would suggest an obvious place to ask such questions.

So, I don't look at this as a problem to solve so much as rather a learning experience which could open up another set of possible experiences and, well, from that maybe problems to be solved too I suppose.

I like to think outside the box and tinker about under the hood to learn. If I don't catch fish in a hole or stream and I know they are there then I may decide to try some different rigs or bait or whatever. But I catch your drift that there may be bigger fish to fry.

Paul, thank you. That was very helpful of you and more precisely what I was looking for.

> As mT pointed out, these *are* really aimed at Developers. Not really an excuse for the significant kludge factor, but there's a lot of assumed knowledge (such as the -p above). Without meaning this in any way as a put-down, if you're not sure what the -p is for in CpMac it might be better to stick to the regular counterparts for a while to gain familiarity.

Although it seems to make sense what has been assumed by the -p flag for CpMac, if someone doesn't try it out and test it then how will anyone really know for certain. And since we could only speculate as to what the -mac flag does with regard to CpMac, if I or anyone didn't try to test that one out and learn from it then all I'd be left with is the -r or -R flag which seems fairly certain to be recursive and thus the only remaining counterpart.

I may have shed my training wheels but still need to put my foot down and hold on to something every now and again. And, yup, I'm no doubt dangerous at that. But we all had to learn somehow. I know we all still are and a helping hand is always appreciated.

training wheels lost, let the skinned knees begin...

it's not too difficult to do some investigation...

how about setting up a sandbox directory in your home dir, copy in some files, a few have to have their resource forks intact ( an exersize for the student [ % man ditto ] ), and run CpMac on them ten ways til sunday, observing the results?

that's how academians might approach it, and what i was going to do, until i started reading "the art of the third reich."

--
sometimes, you gotta roll yer own.

Even though I already had read the rise and fall of the third reich years ago and have not forgotten that, I was thinking of doing something very similar to what you suggest. And I think I get that you keep referring to ditto as a way to understand what might be the true meaning for those flags and options in CpMac. Fortunately, I have some experience with ditto so that should help. But I will have to come back to this when I have finished frying the bigger fish which you will soon be reading about in another thread I am about to create.

My knees may already be bloodied a bit as you will see... :eek:

Up late and wide awake.... so I thought I'd post on what I did with my testing of CpMac with regard to the flags and options in case anyone is interested.

# Got this on every try of the [-mac] flag using CpMac for file or directory with files inside

failed to resolve one of the sources (-37)

# Got this on every try without the [-r] flag for file and directories with files inside.
# At least this confirms the meaning of recursive for [-r]

at least one source of a non-recursive copy is a directory (! is_directory(&source_refs[i]))

# Using the [-p] did preserve type and creator and file permissions but not group permission which became 'Unknown'.

# I'm not sure how to check for resource forks while booted into OS X so all I could go by was a file's size before and after which was consistently the same with all the tests and thereby appeared to be working fine.

# I think sym links, hard links, named pipes and anything else more complicated are not handled by CpMac.

# Overall synopsis: There may be some uses for CpMac but other tools are probably better for complete Mac copies, like hfspax, rsync, psync...

...and % ditto -rsrc

CpMac sounds like a tool to avoid, to me.

as for resource forks, a /rsrc will show you the resource fork size, if there is one...

Yes, yes, CpMac looks more and more like the devil you don't know. I must admit to being surprised that it still mangles permissions; that was a known limitation of carbon back in the middle of last year. Could be that CpMac is something of a revanant, and should have been left to rest in peace. Certainly the lack of information about it is pretty suggestive, and (as thatch predicted) it does some rather vicious things to special files. I think that pointing at a symlink to a dir just copies the dir itself. Yep, just checked. Named pipes it used to treat as aliases: I haven't checked whether that's been fixed.

My punt would be that this app hasn't been updated in a while, and maybe hasn't benefited from updates to carbon functionality. But that's nothing more than a guess based on the fact that behaviour is still a bit shonky. Lots of -43 (ie file not found) errors that send OS9ish shivers up my spine. Maybe it's time the little one was tucked away in a nice dark grave somewhere.

Other tools: yep, ditto -rsrc, psync, hfspax are the big three that I know of. rsync doesn't handle resource forks or finder info so I wouldn't head in that direction unless you're either running on ufs or are confident that you're in a multiple-fork free zone.

I should definitely point out that psync is just one of the executables that Dan Kogai provides in his "MacOSX::Files" distribution. Pertinent to this discussion is another such thing, "pcpmac", (can you tell that I only just discovered this thing? Thought so...). He's reimplemented CpMac completely, but it actually works now! Assuming that you've got psync available you've also got a drop in replacement for CpMac. And MvMac (in pmvmac).

% man pcpmac

explains the lot. And my limited testing suggests that CpMac can now *definitely* be trashed. So here we go:

% rm /Developer/Tools/CpMac

And good bloody riddance! You really sucked.

Enter the following line to see the list of what Dan's made available:

% perldoc MacOSX::File

All this reminds me that a well deserved thank you to the man concerned (ie Dan Kogai) is overdue.... so off I go.

Cheers,
Paul

Thanks to all for the very educating and sometimes entertaining comentary.

To Merv,

Yes, ditto too. Didn't mean to leave that one out.

And thanks for the tip on resource fork identity. But I can't seem to get that to happen by your example. The only sure place I have to have some resource forks at would be my almost bare bones partition for OS 9.2.2 where I have say, Norton SystemWorks. So, I do a ll to one of those that I would think for certain must have a resource fork but don't see any asterisks in the data or any rsrc* at the end of the line either. I tried a bunch of different apps, control panels and various preference files but came up with nada.

To Paul,

Thanks for the heads up on rsync. And I'm intrigued by MacOSX::File and will be looking into more of that real soon. Good bye to CpMac, MvMac.... hello pcpmac, pmvmac.

:cool:

thatch,

% ls -l */rsrc

ought to find some non-zero resource forks in a directory that is likely to have such files.

try this to find some resource files:

the size being non-zero indicates the length of the resource fork.

Hey Merv,

When I used the 'ls -l */rsrc', I got some good data. Thanks! I can use that. And it makes perfect sense too. I don't know why I hadn't thought of trying it before. Sometimes I guess I need more than a little nudge in the right direction.

But the 'find . -type f | sed 's/^/"/;s/$/\/rsrc"/' | xargs -i ls -l {}' gave me a xargs: illegal option -- i, usage: xargs [-0t] [-n number [-x]] [-s size] [utility [argument ...]]

Admittedly, that line is way over my head at this time so I'll have to try and study that in the man pages although some of it may still not be too readily clear from that alone. I have so much to learn. Thanks for all you efforts to guide me.

And BTW, I respond to thatch 'cause it's my nickname and also part of my last name, plus I've been known to respond to a lot worse names when I've been bad. But my pals call me Tom and I hope we are becoming that, Merv.

hey tom,

sorry about that xargs biz. i've installed a lot of the fink tools, and they supercede the vanilla OSX install. fink's xargs has the danged -i switch. /usr/bin/xargs don't? well, poop, then. fink's is superior in that respect.

try that find command without the -i switch and braces {}

... | xargs ls -l

here's a breakdown of the commands

part one: find regular files from cwd on down any paths, pipe that to...

part two: sed stuffs a double quote at the beginning of the line, and then stuffs a /rsrc and a double quote at the end of the line, and pipe that to...

part three: xargs runs a command on it's input, in this case. the quoted full path to the file from find, and a /rsrc appended, then runs ls -l on that arg.

i had the -i switch in there to tell GNU's (fink's) xargs the args need to be in position marked by the braces {}

i had the braces in there because i was trying to do something else with the args to xargs. *sigh* it worked with GNU's xargs so i left it in. mea culpa.

I should have put this in my prior post...

I tried editing out the -i flag (or option) and got:

ls: {}: No such file or directory

... and a huge amount of data which looks like what it should be. I am amazed at how many resource forks there are on the X side. I had figured that most of them would be in 9. So, is it aqua that really needs them on X?

The part of that more complicated line that is greek to me is:

's/^/"/;s/$/\/rsrc"/' which is part of sed. And I don't know sed yet, or xargs for that matter. But I'm learning.

reads like this...

substitute /this/that/ ;then substitute /this/that/

where this = ^ = beginning of the line
where that = " = stuff a double-quote in there

; then

where this = $ = end of the line
where that = \/rsrc" = stuff a /rsrc" in there

the forward slashes delimit the this and that to sed, so to stuff a / into the that, you have to 'escape' the / with a \

--
if it was easy, we wouldn't call it code

Merv,

I got the break down. Thanks. That helps a lot. I need to spend some time in those man pages though.

No problem about the fink thing. I don't have that yet so no wonder it didn't work exactly but I did get the picture. Fink will, no doubt, be coming for me once I've got through the MacOSX::Files stuff. All in good time.

Speaking of which... you must have quite a few years or even decades into all this, huh?

...consolidating your next message here...

Wow. You explain that so well and make it seem much easier than it probably is. I do know what the escape character is and does, at least in some cases. But ^, ", $, on their own, well, beats the heck out of me.

I haven't the foggiest what ^ is, does or means. I know what enclosing two double quotes does. That's pretty obvious. And I know how to do a 'echo $PATH' for example. But I don't know what the purpose of the $ character is.