can the ksh getopts be used as a library elsewhere ?

[tungstengmd]

i really like the korn shell getopts, especially the self documenting capabilities, and i was just wondering if it could be used elsewhere in other languages !

[jghub]

I agree getopts is really useful for providing decently formatted help to shell scripts. I do not know whether it could be made available easily as a separate library. personally I would find that useful (I have used very thin ksh wrappers around lua and tcl scripts for the sole purpose of making getopts available ;)). but I would guess that other languages will usually stick to their own established help facilities even where those might be considered inferior (in my limited experience, what I have seen from phython in these terms was not impressive, e.g. ;)). so...

[tungstengmd]

i've seen that perl has it Really good, with getopt::long and pod::usage, but i'm still used to the korn shell syntax [and having to do GetOptions "test" => \$testvar or die or something like that is quite annoying
still nice that we have pod and getopt together with it being cross platform too :>

[McDutchie]

Hey @tungstengmd, the ksh getopts command is implemented by the optget function in libast. And that function uses other parts of libast, such as Sfio and the error message mechanism. So it can't be used stand-alone.

However, it's certainly possible to link third-party programs against libast. Generally those would be C programs, but I suppose it might be possible to use other languages that can link against C interfaces.

Linking C programs against libast is not yet very well documented. Do you program in C? If so, I could get you started with a skeleton program; please let me know.

[JohnoKing]

Documentation for mamake:
https://github.com/ksh93/ksh/blob/dev/src/cmd/INIT/README-mamake.md

nmake is abandoned and unused, though its documentation is archived alongside the source code:
https://github.com/ksh93/ast-open-archive/blob/master/src/cmd/nmake/nmake.1.body
https://github.com/ksh93/ast-open-archive/blob/master/src/cmd/nmake/nmake.1.tail
https://github.com/ksh93/ast-open-archive/tree/master/src/cmd/nmake

[tungstengmd]

now seeing as i am properly learning c, how would you link against libast?

[JohnoKing]

For dynamic linking, if libast.so is installed in /usr/lib, you could just link against it with -last. Example (tested on CachyOS with ksh93-git AUR package):

#include <ast.h>
#include <sfio.h>

int main(void)
{
	int pid;
	char path[PATH_MAX];

	pid_t current_pid = getpid();
	sfsprintf(path, sizeof(path), "/proc/%d/stat", (int)current_pid);
	Sfio_t *sp = sfopen(NULL, path, "r");
	sfscanf(sp, "%d", &pid);
	sfprintf(sfstdout, "%d\n", pid);
	sfclose(sp);
	return 0;
}

# gcc and tcc also work fine
$ clang -O2 -I/usr/include/ast -o /tmp/example sfio-sfscanf-example.c -last
$ /tmp/example
13648

The dylib script could also be a useful reference: https://github.com/ksh93/ksh/blob/dev/src/cmd/INIT/dylink.sh#L141-L151

Bear in mind that using libast.a will result in a binary statically linked to libast, which is not GPL compatible. If your code is under the GPL you need to dynamically link against libast.so and avoid libast.a.

[avih]

now seeing as i am properly learning c, how would you link against libast?

If you're learning C, then I'd suggest writing it yourself as a good exercise.

Start by implementing POSIX getopt, which should cover the needs of standard-conforming CLI interfaces. This is relatively simple.

If that went well, you can go on to implement a ksh getopts interface.

And finally, publish it under a nice license and post a link here to the repo ;)

[tungstengmd]

well i've got it working with short+long options, how do i work the only-long-options? ik that you're supposed to put a 2 digit number for scripts i wonder how that applies here