How to Call external function in .C or .So (Shared Object)

Hi,

Anybody know any way to Call with Shell Script an external function wrote in .C or .So (Shared Object) on AIX enviroment and returning parameters of .C or .SO to Shell Script?

Tks!!

There is no way without invoking something based on C code. In other words you would have to write C code that calls the AIX equivalent of dlopen(): probably loadquery()/loadbind() ) in later versions. It then runs the external function - the name of which is passed as a parameter.

You can call an external function or library from certain shells (bash, ksh93, zsh) if you know exactly what you are doing. It is not a trivial exercise and it is fraught with danger. In fact you can also go the other way with ksh93 and invoke ksh93 internal shell functionality from an application.

Here are pointers to some posts I have written on the subject for ksh93 which should help you understand the issues:
KSH93 Custom Builtins 1
KSH93 Custom Builtins II
KSH93 libshell

I've been unable to positively determine that BASH suports this at runtime rather than compile-time.

[edit] ahah. It's enable, not builtin in bash.

It's apparently documented in the source code not the manual page.

bash builtins seem to be more difficult to build and write than ksh ones. They depend on bash internals for their argument lists, so it's not as simple as builtin(argc, argv)...

Bash custom built-ins are interestingly difficult but doable if you really need them. I try and avoid them if possible.

Here is a pointer to some good work by Chris F.A. Johnson (who is a member of this forum): Loadable built-in commands in bash

Bash builtins really aren't that difficult code-wise. The parameter list is a simple linked list instead of an array. But you can't build them without building bash itself.

I've been experimenting with a bash builtin which creates arbitrary anonymous pipes... The behavior's interesting. Since the shell's holding it open, it doesn't block like a named pipe when you redirect into it. If it's not full, it doesn't block even when you write to it. This is of course the definition of a buffer, but it's interesting to have it happen when you haven't created your reader yet. Some useful concurrency could happen there. There might be some communication arrangements doable with this that'd be impossible with a named pipe since the shell can't open both ends at the same time.

Hi

Maybe instead of call an external function you cut only this function code another new .c file and edit in so shall use to its exit status($?) or output the results of function (to write tmp file like ) before use compile new file (gcc ) yourfile..It can be used in this wise and more than simple :confused: