embedding C code in a shell script

embedding C code in a shell script

[Dave Yost]

Hi.

It just occurred to me that with very little work, zsh could add this 
feature using similar techniques to the what you can read about here:
   http://yost.com/computers/compileAndGo/index.html#Future

So, for example, one could embed a C function to call realpath(3).

You could compile the code as a separate command, or you could do 
more work and dynamically link it in and call it.

Dave

compiledFunction realpath() {
compiler    = gcc
compileAndGo

#include <stdio.h>
#include <sys/param.h>
#include <stdlib.h>

int main(int argc, char *argv[]) {
   int ind;
   int trouble = 0;
   char resolvedPath[MAXPATHLEN];
   // printf("Invoked as %s\n", argv[0]);
   if (argc <= 1) {
     fprintf(stderr, "\nUsage: realpath path ...\n\nExit 1 if any 
paths fail.\n\n");
     exit(2);
   }
   for (ind = 1; ind < argc; ++ind) {
     if (realpath(argv[ind], resolvedPath) == NULL) {
       fprintf(stderr, "%s: No such path: %s\n", argv[1], argv[ind]);
       trouble = 1;
     } else {
       printf("%s\n", resolvedPath);
     }
   }
   exit(trouble ? 1 : 0);
}

compileAndGo

Re: embedding C code in a shell script

[Bart Schaefer]

On Jan 11,  2:12pm, Dave Yost wrote:
}
} It just occurred to me that with very little work, zsh could add this 
} feature using similar techniques to the what you can read about here:
}    http://yost.com/computers/compileAndGo/index.html#Future

[Aside:  To answer the question in your script at that web page, the
reason you have to use backticks instead of $(...) is because of the
unbalanced right-parens in the case ... esac syntax.  In recent shells
you can add opening left parens in case statements and then it's OK to
put $(...) around the whole thing.  Also, please forgive me for the
following commentary, but if you're going to post a link to something
you've got to expect some critique.]

Years ago, like 1990+/-, I had a friend who used a csh alias "cx"
which stood for "compile and execute" and which boiled down to:
    alias cx "cc *.c && ./a.out"
This still gives me the willies when I think about it, and it's giving
me an unpleasant first reaction to this discussion.

Suppressing that flashback for the moment, compileAndGo seems like an
application begging for here-documents.  Why make the compileAndGo
program do the work of parsing the variable declarations and so forth
(especially since it does it with sed), when one could let the shell
do the parsing, pass those values through the environment, and just
compile standard input ala:

  #!/bin/sh
  compiled=realpath compiler=gcc compileAndGo <<\EOCAG
  #include <stdio.h>
  // ... etc ...
  EOCAG

??  This allows you to do things like compute the compiled name from
the file name, e.g.

  #!/bin/zsh -f
  compiled=${0:t:r} compiler=gcc compileAndGo ...

And as long as you're at it, you might as well provide the option
to have compileAndGo create the main() routine for you so all you
have to write is the code that forms the function body.

} You could compile the code as a separate command, or you could do 
} more work and dynamically link it in and call it.

The way to do that in zsh would be to have a template zsh module
source file, insert the function name and body into it, compile it
(which probably still requires a zsh source tree although I think
Clint (?) spent some time working on being able to compile modules
on their own), drop it in a directory in $module_path, and zmodload.
The bootup function for the module could check whether it needs to
be recompiled, I *think*, though it might be tricky to get it to
re-zmodload something with which it just overwrote itself.

Your next exercise is to write compileAndGo as a zsh module that can
recompile itself as you update it. :-)

Re: embedding C code in a shell script

[Dave Yost]

Cool, thanks.

Dave

At 08:49 PM -0800 2009-01-11, Bart Schaefer wrote:
>On Jan 11,  2:12pm, Dave Yost wrote:
>}
>} It just occurred to me that with very little work, zsh could add this
>} feature using similar techniques to the what you can read about here:
>}    http://yost.com/computers/compileAndGo/index.html#Future
>
>[Aside:  To answer the question in your script at that web page, the
>reason you have to use backticks instead of $(...) is because of the
>unbalanced right-parens in the case ... esac syntax.  In recent shells
>you can add opening left parens in case statements and then it's OK to
>put $(...) around the whole thing.  Also, please forgive me for the
>following commentary, but if you're going to post a link to something
>you've got to expect some critique.]
>
>Years ago, like 1990+/-, I had a friend who used a csh alias "cx"
>which stood for "compile and execute" and which boiled down to:
>    alias cx "cc *.c && ./a.out"
>This still gives me the willies when I think about it, and it's giving
>me an unpleasant first reaction to this discussion.
>
>Suppressing that flashback for the moment, compileAndGo seems like an
>application begging for here-documents.  Why make the compileAndGo
>program do the work of parsing the variable declarations and so forth
>(especially since it does it with sed), when one could let the shell
>do the parsing, pass those values through the environment, and just
>compile standard input ala:
>
>  #!/bin/sh
>  compiled=realpath compiler=gcc compileAndGo <<\EOCAG
>  #include <stdio.h>
>  // ... etc ...
>  EOCAG
>
>??  This allows you to do things like compute the compiled name from
>the file name, e.g.
>
>  #!/bin/zsh -f
>  compiled=${0:t:r} compiler=gcc compileAndGo ...
>
>And as long as you're at it, you might as well provide the option
>to have compileAndGo create the main() routine for you so all you
>have to write is the code that forms the function body.
>
>} You could compile the code as a separate command, or you could do
>} more work and dynamically link it in and call it.
>
>The way to do that in zsh would be to have a template zsh module
>source file, insert the function name and body into it, compile it
>(which probably still requires a zsh source tree although I think
>Clint (?) spent some time working on being able to compile modules
>on their own), drop it in a directory in $module_path, and zmodload.
>The bootup function for the module could check whether it needs to
>be recompiled, I *think*, though it might be tricky to get it to
>re-zmodload something with which it just overwrote itself.
>
>Your next exercise is to write compileAndGo as a zsh module that can
>recompile itself as you update it. :-)