Thread-topic: How to pass cmd line arguments to my carbon app?
User-agent: Microsoft-Entourage/11.2.0.050811
on 9/22/05 2:27 PM, Jay Vaughan at <email@hidden> wrote:
>> If you're users are "argc/argv-savvy" then they can run terminal and feel
>> 100% right at home. I don't see the problem. And I don't see how you adding
>> anything to your Info.plist file is going to be doing anything for those
>> users anyway.
>
> if i say to user a), a unix user, "add these args to the cmd: -blah
> -blah -blah", its nice to also be able to say to an OSX user, "put
> these args in your Info.plist/CFAppExecutableArgs key: '-blah -blah
> -blah'". exactly same args, weird and intrinsic to the application
> [not public necessarily, or at least limited-use].
I'd say edit this script...
> compatible, like. i know it breaks all the apple rules, i know
Actually I don't know of any rules that say you can't do this or even that
you shouldn't do this. Honestly, it's never come up.
> it looks like it was -not- done on purpose, this Args key in the
> .plist, because Apple wanted to do away with all that.
Nope. Just Apple's and Oranges. ;-)
> right. i get it. but what i'm saying is, in the case where unix argv
> args are
> presented by the API choice, why break it with a broken shell,
> especially in light of the evidence that there is a -lot- of
> argc/argv in the OSX underpinnings .. are you saying i should only be
> writing /one/ kind of app, and supporting only that, if i'm an OSX
> port assistant?
What broken shell?!? Finder? The Finder way to do this would be to add
"arguments" to the "Get Info" box so users could change these kinds of
launch arguments. But like I said, you're the first to request this AFAIK
ever.
> what about all my other argc/argv apps? does the finder just plain
> not know how to talk to them, normally?
The Finder can launch them but since it doesn't have a command line where
would it get these parameter from?
>> Actually, I'm pretty confident that your "argc/argv-savvy" users are just as
>> comfortable (if not more so) with having a preferences window where they can
>> interact with standard controls (menus, check boxes, buttons, etc.) as they
>> are with command lines. That being said, why try to force all the
>> non-"argc/argv-savvy" users into the "old school" way of doing things?
>>
>
> take the case, for example, of the gargantuan swaths of code
> represented in the GNU sphere, the *bsd sphere, the scientific
> computing sphere, which now have to have 'wrapper apps' written for
> them just to stuff args into the .app bundle scheme which is wrapping
> our Darwin bins.
Not true at all. At least half the tools I use daily don't have any GUI and
are perfectly usable from the terminal. None of these require any "wrapper
app"; they "just work".
> pathetic, actually.. and i'm only making a fuss about it because it
> actually doesn't make sense, for anyone but Apple, to not just keep
> the argc/argv thing around, supported in all the new finder/launcher
> plastic, for the cases its needed..
Uh, it's not needed. If you need command line arguments then use terminal
(or scripts) and you'll have command-line arguments. Why add old school
command line support to a GUI interface when there's already a command line
utility (that command-line users are perfectly comfortable with already I
might add).
> i feel i'm missing something: that it -can- be done, easily. thats
> the only reason i'm asking.
>
>> Plus if the option is in a preference pane your users are much more likely
>> to figure it out for themselves rather than having to get it "over the
>> phone".
> look, anyone with argc/argv savvy is not gonna give two hoots if its
> 'smooth' to have an 'Apple prefpane' built for them.
Hoots or not that's not my point. What I'm saying is that if it's in a pref
pane then it's a lot more intuitive than some obscure command line argument.
> i can, however,
> see them having a nice time with two different .app bundles on their
> desktop, each one basically the same app, only with different args.
One of the more active developers on this list just happens to have an app
that creates dropplets. Code-wise these dropplets are all identical; their
only difference being what they do when you drop things on them. The way
they (unuquely) do what they do is on creation he writes the custom behavior
prefs into an application bundle resource. This is the only unique part of
all of his dropplets.
> i can do that, it is probably 'a way' to do it, if but not a secure
> one (since it involves use of 'the apple-maintained shell', woop) ..
?!?!? Sorry sh, tcsh, etc. are NOT "apple-maintained shell"'s. They all
originated from *NIX land.
--
Enjoy,
George Warner,
Schizophrenic Optimization Scientist
Apple Developer Technical Support (DTS)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
This email sent to email@hidden
