A rather unfortunate name, given how Posh is also occasionally used as a shortening of PowerShell. Especially when PowerShell has a very similar shtick going for it.
I spent some time looking at an Octodeploy build/deployment system today, & found that the use of tags on environment variables was really interesting & effective. There would be one deploy process, but with a couple different copies of some environment variables, tagged with the different deployment targets. It made it easy to get an overall look at the many deploys, & see what was tagged where.
> To make decisions about which parts of a script are executed remotely, POSH produces a graph representation of the shell script’s execution - the nodes in the graph are commands, while the edges represent the flow of data between commands. Correctly transforming a shell script into this graph representation is a nuanced, yet critical function. To facilitate it, POSH leverages an annotation language capable of describing a given command’s parameters, inputs, and outputs (as well as a number of important configuration options).
Posh is likewise using annotations to explain to itself what pieces of deployment (of a part of a shell command) may be done on which systems. Unlike the octodeploy I was looking at, where one unified deploy could be instantiated for differently tagged environments, Posh is building pipelines that span multiple systems, and using the system annotations to figure out where to schedule bits of work.
> I wanted to note two important components of the annotation language important to understanding the rest of the paper. First, the annotations can be defined per command and per argument - this flexibility is important because different arguments to a command can change its behavior and arguments. Second, a command’s inputs/outputs can be typed, and its behavior is defined. For example, the annotation language can indicate a command’s parallelizablity or whether the command relies on the current directory. Defining these properties of a command allow the parser and scheduler to answer the three questions above.
Quite enjoying this write-up! Excellent highlight of contributions & core characteristics.
I wish there was an HTML shell, where applications can output not just text, but structured text, tables, even images. Where an application could have an 'easy mode' for uncommon tasks where it just prints a user interface with a few buttons.
This sounds pretty similar to what Powershell does. You can list the contents of the directory which outputs a structured table, then pipe that into Out-GridView for an interactive GUI window.
I can see the benefits of structured output from CLI tools. It’s a bit rare to find but they do exist. I believe the closest I have found in the wild is a terminal instance connecting to some 1980s mainframe tech.
There are also some FOSS tools aimed at increasing the readability of CLI tools
Doesn’t offer tables (yet) but is about as good as it’s going to get.
For “easy mode” apps, isn’t this what GUI apps were made for? The old Java applets and apps using Swing/JavaFX or Qt are the ones that immediately come to mind.
I'm struggling to understand what problem this is meant to solve. I've been working in high scale production environments for 15+ years and I can't think of a situation where I'd mount a network file server and run a local script to parse logs there.
If this is what you want to do there is almost certainly a better solution that involves parsing the logs another way entirely.
