feat: subcommands example

[redbeardymcgee]

This commit demonstrates an example project structure to introduce subcommands and simple argument parsing. The goal is to increase support for end-user environments by using a wrapper script which will always execute in a POSIX-compatible shell environment.

It is worth noting, however, that this technique may be better applied by calling bash instead of sh. Bash has, in practical terms, nearly equal coverage as POSIX shell. The only caveat is really MacOS, which only ships the final 3.x release. No problem though, because bash3 has plenty of support for nicer features like arrays. The project already has a hard dependency on tmux anyway, right? And the target audience is also expected to be running a modern Linux (arch btw?) or MacOS, if I have the correct read on the community here. What is the worst case? Perhaps WSL? Git Bash on Windows? Surely not, I suspect, an environment like cygwin or mingw, but I pass no judgment. For your consideration.

If anything more complex was necessary, this would cease to be worth doing in pure shell script anymore, except as academic exercise (an admirable goal, nevertheless). In such case, I would recommend bumping up to bash4 instead, since the purpose of the script would most likely no longer have end-users in mind and may make more guarantees that bash4+ will be available in your environment (e.g. part of your custom build system).

getopts is also another POSIX alternative to parse $@. Unfortunately, it only supports a very narrow use-case; namely only short single letter options following a single dash e.g. -h for help. Worth noting anyway, as it may be additionally employed alongside the provided implementation in this changeset. Subcommands may desire additional option switches, for example.

Test this script:

./shmux check foo
./shmux new foo

Further reading:

These were written by wizards, for mortals like me.

• Wooledge Bash Wiki
• getopts Tutorial
• Handling positional parameters

EDIT: I forgot to mention that I also turned off the unnecessary executable bit on all the *.sh files.

[redbeardymcgee]

I should have been clear that this merge request is intended only for the purpose of demonstration. It includes no business logic to wire up the state management currently provided through global environment variables. Such state management logic is not possible with global variables when we introduce a wrapper script as in this MR.

Neither does this script prescribe some different technique for configuring, describing, defining or otherwise declaring sessions. It wouldn't be so tough to implement, but I am not sure that the scope of the project intends to justify any additional complexity, even if that complexity is relatively minor. The existing technique of sourcing *.sh files should suffice, but maybe use a different extension to signify that it's not intended to be run as a standalone script.

This only serves as a proof of concept for subcommands, and education. It is not intended to be merged by the project maintainer.

[cpow]

Love this. Thank you!

…

On Thu, Jul 11, 2024 at 7:24 PM rbm ***@***.***> wrote: I should have been clear that this merge request is intended only for the purpose of demonstration. It includes no business logic to wire up the state management currently provided through global environment variables. Such state management logic is not possible with global variables when we introduce a wrapper script as in this MR. This only serves as a proof of concept for subcommands, and education. It is not intended to be merged by the project maintainer. — Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAZZYXPIPKNLWHYKH2FBWLZL4H2PAVCNFSM6AAAAABKX3GDVCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRUGEYDSOJZGU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>