Enabling Meta-commands

[Adam Sobieski]

Hello. I would like to share some exciting ideas about "meta-commands" with the group.

Here is a list of considered meta-commands:

1. do - performs an action.
2. undo - undoes an action when possible.
3. can do - returns whether a system can presently do an action with the provided arguments, without doing it.
4. can undo - returns whether a system can presently undo an action with the provided arguments, having done it, without undoing it.
5. could undo - returns whether a system would be able to undo an action if it were to do it, without doing it.

The following examples illustrate intended usage:

> undo cmd arg1 arg2

> can cmd arg1 arg2

"Undo" would be a powerful and convenient tool to have for use with many other executables.

"Can" would be a useful tool for easily validating command-line arguments or, for some executables, performing more complex pre-flight checklists.

As considered, programs would be self-contained with respect to their functionalities for doing and undoing actions, for indicating whether they could do or could undo actions, and for indicating whether actions could be undone. That is, in addition to main() functions, programs could, optionally, provide functions like undo_main(), can_main(), can_undo_main(), and could_undo_main().

With respect to implementing meta-commands, ideas include there being multiple entry points in ELF executables or there, otherwise, being multiple ways to load and execute them.

Are multiple entry points in ELF executables a way to go? This would, I think, require updating the ELF standard. Do any other techniques come to mind?

Thank you for any feedback on these ideas.


Best regards,
Adam Sobieski
http://www.phoster.com

[Kirk Hays]

An interesting idea, but it doesn’t require multiple entry points, as you posit.

Busybox, for example, implements analogous behavior, and takes on the functionality of the programs it mimics, depending on the command line arguments.

I would implement this as an extension to an existing command line parsing library, and not burden ELF.

Kindest,

Kirk Hays

On Sep 18, 2024, at 2:42 AM, Adam Sobieski <email.ada...@gmail.com> wrote:

Hello. I would like to share some exciting ideas about "meta-commands" with the group.

--
You received this message because you are subscribed to the Google Groups "Generic System V Application Binary Interface" group.
To unsubscribe from this group and stop receiving emails from it, send an email to generic-abi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/generic-abi/c9ae5cd7-d1cb-4d35-b6ed-cb4fd82ba96dn%40googlegroups.com.

[Adam Sobieski]

Thank you for indicating BusyBox. I hadn't considered that technique.

For discussion, arguments for the multiple-entry-points approach over the BusyBox approach include decentralization, the division and specialization of labor, and that design decisions pertaining to the implementation of programs' functionalities for meta-commands would be best handled by the programs' developer teams.

Brainstorming, with respect to options for adding multiple entry points for meta-commands to ELF executables, one preliminary, simple, backwards-compatible, and extensible solution is that a new section could be added to ELF executables which would provide a lookup table mapping meta-commands' identifiers (e.g., URIs, GUIDs, or other keys) to the offsets of corresponding secondary entry points.


Best regards,
Adam Sobieski