Including variables in system call

Discussion in 'Mac Programming' started by Khanjan, Jul 7, 2009.

  1. macrumors newbie

    Jun 25, 2009
    Hey all,

    I am building an interface in Cocoa with Objective C which performs some function on an input file. I want to call the Terminal and run a script with that input file. For example,

    system(' input.fa');

    I am able to do run the script by hardcoding the inputfile name. However, I want to include a variable file name which depends on the input file, the user choose.

    How to include a variable in system call?

    Thanks for your help,

  2. macrumors G4


    Nov 3, 2005
    You should be able to convert a string to a system call, maybe look at the documentation for NSString.
  3. macrumors 68040


    Jan 10, 2005
    Dallas, TX
    If you wanted to do this in plain C, you'd have something like:

    int runSomeCall(char *filename) {
      char myCommand[256];
      snprintf(myCommand,256,"progname %s",filename);
      return system(myCommand);
    I didn't do this "totally" safe, i.e. checking the length of filename, making sure it's not null, etc.... but i think the idea is clear.

    If you wanted to do this a cocoa-ier way, NSTask would be the way to do it.

  4. macrumors 604


    Aug 13, 2002
    How complex is your interface? are you just running that external script?
  5. thread starter macrumors newbie

    Jun 25, 2009
    Thanks all !! Tried the NSTask way, but it din't work. However, it worked the simpler C way !!

    Interface is just that it allows the user to select an input, runs a script on the input file and displays the outputfiles.

    Thanks a lot :) !

  6. macrumors 604


    Aug 13, 2002
    If it is that simple, you can do it in Automator. The user would execute the command on a highlighted file and the script runs and opens the generated file.
  7. thread starter macrumors newbie

    Jun 25, 2009
    I just saw Automator, I dint know that it can do so many things. However, I want to create an Installer and a User Interface for the pipeline and include it in one package. Do you think, its simpler to use Automator than having an installer and an User Interface. The installer I have already made and am working on the Interface now, and plan to make an icon for it later.

    Thanks a lot for all your help and suggestions.

  8. macrumors 604


    Aug 13, 2002
    Are you building a full application installer? or just something for a small project?
  9. macrumors G5


    Nov 25, 2005
    What happens if the user enters

    somefilename; rm -rf ~/*

    ? (Don't try this, it might erase all of your home directory).
  10. thread starter macrumors newbie

    Jun 25, 2009
    I am building an full application with an installer, so guess it would be better to make an installer and an interface for the same !
  11. macrumors 68020


    Sep 8, 2003
    Uh-oh, you said the magic word: "Installer"...

    Especially on the Mac, this is practically a red flag. If you are writing an installer, you have to ask three big questions:

    - Where am I expecting my app to live? Can the user just copy it there?
    - Am I installing additional tools/fonts/etc that are system level?
    - Why can't I use Apple's install tools? (Which can be extended, mind you)

    Security on the Mac is going to be a bigger issue going forward, and the more variables you introduce to the user... you wind up having to expect the user to just trust that your installer/app is not doing weird stuff, and won't introduce vectors of attack. Users may actually skip your app if they notice all this non-standard behavior, which could be lost revenue.

    While first glance from the Windows world says that installers are the 'user friendly' option, Windows has a lot of crud you have to do in order to get an app on the system, add it to the start menu, and so on. On the Mac side, such an assumption is not true, not after Apple has trained even the unsaavy after the last few years that 99.9% of the apps on the Mac can be copied and run, or use Apple's installer.

    If this is an installer built into the app just to install a couple fonts (which is the right reason to write something like this, a la TextMate), then try to simplify it, and make it so it doesn't need to elevate to root to do its work (use ~/Library instead of /Library, for example). Make it so it isn't calling out to arbitrary scripts which could be used against your users as a vector of attack.

    So just some food for thought before you get too far along.

    If this is just a project to see if you can do it and won't go public, you can ignore most of what I said.

Share This Page