|
I think you're on to something, but tangled in the implementation. I see this as capture of processes -- their invocation, context, and results -- in a relatively normalized form for analysis and re-use. There are many possible applications based on analyzing these: automatically creating, porting, or refactoring code, showing that foreign code or ports are behaving as expected, providing audit trails, etc. Any environment where code is typically prototyped then hoisted into some kind of workflow container is a candidate. No one likes to have this level of intrusion or monitoring, but everyone seems to accept running code in containers, so if this were built in to the container, it might be easily deployed and widely accepted. To me the way to proceed could be to generate a bunch of pseudo-data and start prototyping use-cases based on analyzing the data (or monitoring the stream). The general themes would be in the realm of software evolution, to productize prototypes, refactor legacy bloatware to MVP, model the effect of selectively changing subsystems, etc. Sure, this might benefit the programmer, but it could also be of interest to managers or senior developers helping juniors level up their code. Once you have some valuable use-cases, you'll know more about your deployment targets and business model (OS-freemium?). As for workflow comparables, the original MPW (Macintosh programmers workshop) used the text document for input, output, and commands in a kind of early notebook (perhaps following mathematica notebooks of the time). And Eclipse as an extensible IDE has a number of terminal window and command integrations with UI, following emacs. I could even see this as a python context manager in a notebook. A more narrow goal based on the current implementation could be to build and maintain a library of bash functions or scripts, possibly shared by a team. Monitor and capture results, then let developer select a series of commands to wrap, with your tool providing help with capturing, documentation, generating precondition checks, browsable/html cross-linked docs, etc. But generally I wouldn't try to recreate notebooks or IDE's for bash. My goal is always to migrate any bash that gets big to a language with types, error-handling, logging, etc. |
That's a nice, neat, concise way of putting it. Thanks.
> There are many possible applications based on analyzing these ...
Those are some neat ideas. I'd certainly have to talk about them with some real users to understand the demand and use-case. I think the easy sharing I mentioned could go a long way to achieving that goal.
You can also already pretty easily extract just the commands run, to (as you put it) hoist it into a larger script or workflow. E.g. in my current instance, `hucksh sql "select command from command_history where id > 2863 order by id"` dumps out the most recent 10 commands you ran.
> No one likes to have this level of intrusion or monitoring, but everyone seems to accept running code in containers, so if this were built in to the container, it might be easily deployed and widely accepted.
Hmm, perhaps.
That does give me an idea for another use-case for hucksh in containers: mount the hucksh database file into a container, across invocations, to have a more seamless history of working in the container.
> A more narrow goal based on the current implementation could be to build and maintain a library of bash functions or scripts, possibly shared by a team.
Indeed. That's where I was going when I said "I hope in the future to make it easy to share history, which could help with new employee onboarding, [etc]."
> My goal is always to migrate any bash that gets big [...]
Yes, I agree.
Thanks again for your comment. Some neat stuff here.