[sadie]

OK, I'm writing a command line program and naively assumed that the usual C way of getting command line arguments would work in Objective-C:

Code:
int main(int argc,char *argv[]) {...}

What i got instead was the complete path of the binary file that was being run. Which, while being fascinating in a zen way, wasn't what i was looking for.

Huh?

[parallax]

argv is a list of arguments (hence *argv[], which is also written as **argv).

argv[0] is always the path to the thing you're executing, even in C.

Try starting from 1 to get your command-line args.

[sadie]

oh. right. thanks.

Oh well, i haven't done a lot of command line stuff before - and you learn something every day. Or if you have a day where you learn nothing, do nothing and go nowhere, it's your own fault.

This does tell me something else is wrong, coz my code was supposed to spew out all the args, not just the first one. *puzzled*



[This message has been edited by sadie (edited 03-10-2001).]

[lindberg]

Just a couple of further notes --

If this is an ObjC program using the Foundation framework, then [[NSProcessInfo processInfo] arguments] will get you an NSArray of NSStrings that represent the arguments.

Arguments of the form -SomeKey value will automatically get parsed and put in the NSArgumentDomain of NSUserDefaults; i.e. it lets you do [[NSUserDefaults standardUserDefaults] stringForKey:@"SomeKey"] and get the value back.

[sadie]

OK, when i forced it to ignore the number of arguments and just keep printing until it crashed, this is what i got:

Code:
[localhost:~] shrink% mok myargument
arg : /Memotype V/Documents/Projects/Mok/build/Mok.app/Contents/MacOS/Mok
arg : (null)
arg : HOME=/Users/shrink
arg : SHELL=/bin/tcsh
arg : USER=shrink
arg : PATH=/Users/shrink/bin/powerpc-apple-macos:/Users/shrink/bin:/usr/
local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:.
arg : __CF_USER_TEXT_ENCODING=0x66:0:0
arg : TERM=vt100
arg : TERMCAP=d0|vt100|vt100-am|vt100am|dec vt100:      :do=^
J:co#80:li#36:cl=\E[;H\E[2J:sf=2*\ED:      :le=^H:bs:am:cm=5\E[%i%d;%dH:nd=
2\E[C:up=2\E[A: :ce=3\E[K:cd=50\E[J:so=2\E[7m:se=2\E[m:us=2\E[4m:ue=2\E[m:      
:md=2\E[1m:mr=2\E[7m:mb=2\E[5m:me=2\E[m:        :rf=/usr/share/tabset/vt100:    
:rs=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h\E[;r\E[0m\E(B\E)B\E[2J:   :ks=\E[?1h\
E=:ke=\E[?1l\E>:     :ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:kb=^H: :ho=\E[H:k1=\
EOP:k2=\EOQ:k3=\EOR:k4=\EOS :pt:sr=2*\EM:vt#3:xn:   :sc=\E7:rc=\E8:cs=\
E[%i%d;%dr:
arg : TERM_PROGRAM=Apple_Terminal
arg : TERM_PROGRAM_VERSION=22
arg : HOSTTYPE=macintosh
arg : VENDOR=apple
arg : OSTYPE=darwin1.0
arg : MACHTYPE=powerpc
arg : SHLVL=2
arg : PWD=/Users/shrink
arg : LOGNAME=shrink
arg : GROUP=staff
arg : HOST=localhost
arg : ENV_SET=
arg : MANPATH=~/man:/usr/local/share/man:/usr/share/man
arg : _=/Memotype V/Documents/Projects/Mok/build/Mok.app/Contents/MacOS/Mok
arg : (null)
arg : /Memotype V/Documents/Projects/Mok/build/Mok.app/Contents/MacOS/Mok
arg : (null)

No mention of my argument anywhere. What?



(edited to prevent it turning random code into smilies)

[This message has been edited by sadie (edited 03-11-2001).]

[lindberg]

Originally posted by sadie:
OK, when i forced it to ignore the number of arguments and just keep printing until it crashed, this is what i got:

Code:
[localhost:~] shrink% mok myargument
arg : /Memotype V/Documents/Projects/Mok/build/Mok.app/Contents/MacOS/Mok
arg : (null)
arg : HOME=/Users/shrink
arg : SHELL=/bin/tcsh
...

No mention of my argument anywhere. What?

Huh. That does say there are no arguments. Is Mok.app a mach-o app? Or is it CFM? In the latter case, the app is really run by a "LaunchCFMApp" process, which I suppose may not forward arguments through. Other than that I'm at a loss.

BTW, the strings you're seeing are the environment strings. In C, you can declare main() like this:

int main(int argc, char *argv[], char *env[])

That lets you have access to a second string array with all of the environment values. The NULL you're seeing in argv[1] indicates that the argument list has ended.

[sadie]

Mok.app is what's produced by Project Builder. I'm calling the binary file inside it manually, having added the location to my path. I'd expect the same result from cc, but haven't tried it.

I can't use NSArgumentWhatever, because I'm trying to write something platform-independent. If gcc under unix can't compile it properly, then i've failed.

Command line arguments aren't even essential to the final thing, just useful for testing

[sadie]

What does the TERMCAP environment variable contain?

[aleph_null]

Hmmm. You might try -- if you haven't already -- just compiling your files stright from the command line, using cc. I don't know if PB has a "command line project" template or anything. If it does, that should work. Otherwise, it undoubtedly thinks you're making a packaged app and adds all sorts of funky stuff for that purpose (including possibly futzing with the arguments passed in).

You could probably fiddle with options in PB to get it to run cc without any fanciness, but it might be just as easy to edit your files in PB and compile them from the command line. I assume it's possible to set up a makefile, though I've never done it.

I dunno. Not an expert, just a thought.

[jnichols]

Code:
[localhost:~] shrink% mok myargument
arg : /Memotype V/Documents/Projects/Mok/build/Mok.app/Contents/MacOS/Mok
arg : (null)
... more arg stuff ...
arg : (null)
arg : /Memotype V/Documents/Projects/Mok/build/Mok.app/Contents/MacOS/Mok
arg : (null)

No mention of my argument anywhere. What?



(edited to prevent it turning random code into smilies)

[This message has been edited by sadie (edited 03-11-2001).][/b]<HR></BLOCKQUOTE>

if you're looking for portability i'd recommend C instead of Objective C but the following code will work when compiled as either (see end of post):

create the following file called argv_test.c in your favorite text editor

Code:
#include <stdio.h>    /* printf */
#include <stdlib.h>   /* EXIT_SUCCESS */

int main(int argc, char *argv[]) {
   int i;

   for (i=0; i<argc; i++)
      printf("argv[%i] = %s\n", i, argv[i]);

   return EXIT_SUCCESS;
}

open up terminal.app and cd to wherever the argv_test.c file is and do the following ("% " is the command prompt):

Code:
% cc -o argv_test argv_test.c
% ./argv_test myArg1 myArg2 myArg3
argv[0] = ./argv_test
argv[1] = myArg1
argv[2] = myArg2
argv[3] = myArg3

that should do it. you were definitely getting the environment variables. i don't know how to do this in Project Builder but that wouldn't be portable anyway. You can always use Project Builder to edit the files (there's probably a way to do command line projects in Project Builder - i just don't know how).

to compile the code as Objective C change the argv_test.c file to argv_test.m and use the following cc command instead of the one above "cc -x objective-c -o argv_test argv_test.m". works both ways. if you're not convinced it's really compiling as Objective C use the -v flag...

Hope this helps.

[This message has been edited by jnichols (edited 03-13-2001).]

[lindberg]

[localhost:~] shrink% mok myargument
arg : /Memotype V/Documents/Projects/Mok/build/Mok.app/Contents/MacOS/Mok

You know, this is actually a bit of a red flag. If you just typed "mok myargument" to start the program, then argv[0] should just have been "mok", not the full path. This seems to be indicating some intermediate process is actually launching your application.

What happens when you type "./Mok myargument" when you are in the directory the binary is in? Same thing, or is argv[0] "./Mok" like it should be?

If it's the full path, try "file Mok" to see if the file tool knows what kind of file it is. If the result is "data" (i.e. it doesn't know), then it's likely a CFM binary. If it's a Mach-O binary (the native format) it should tell you. I'm having a hard time believing it's mach-o, unless you've aliased "mok" to actually run some other command in your .cshrc...

I can't use NSArgumentWhatever, because I'm trying to write something platform-independent. If gcc under unix can't compile it properly, then i've failed.

With GNUSTEP installed, code that uses Foundation should work on some other Unices (Linux and FreeBSD in particular, and I think some others). It's more effort to set up of course, but it does work and will make your (programming) life much easier. Not sure if your goal is to be as portable as possible, or just to be able to run it on some other Unix boxes -- if it's the latter, then GNUSTEP may well be an option for you.

What does the TERMCAP environment variable contain?

Oh dear, you had to ask, didn't you :-) The short answer is "ignore it", but I'll try to explain a bit...

Termcap is short for "terminal capabilities", and is a big string of key-value pairs where each key represents some aspect of the terminal's capabilities -- number of columns, number of rows, lots of other stuff. This meant an awful lot more in the 80s, when terminals really were hardware and there were many different kinds of them. They needed to be described very explicitly to a) make programs look as nice as possible on them and b) make sure to not send control codes that the hardware couldn't handle, which could damage the hardware.

These days, it's pretty much just used to describe what the virtual terminal provided by Terminal.app can do, plus maybe different settings when logged in in console mode. Generally, just ignore it -- you won't need to do one yourself, and as hideous old Unix file formats go termcap ranks near the top. If you really want to know more, you can look at the /usr/share/misc/termcap text file to see the whole historical list, or read the termcap(5) man page (type "man 5 termcap" ).

[lindberg]

[Double post]

[This message has been edited by lindberg (edited 03-16-2001).]