Feature: CLI Manager #247
Feature: CLI Manager #247
Conversation
Well I'll need to adjust that in my IDE...
`bc` is not always available, and we won't be using any of the special functions, so use standard `expr` instead.
Note: This has debug code in it to test remote sourcing. Please Hold.
Just testing out the capabilities and limitations of pulling from remote.
Allows the user to use locally stored versions of the dependent files, in the event that they are executing the manager locally (from within the Git/Source directory). This will be useful in the future if this script is expanded in any ways where it may be installed locally in /usr/bin for managing the current installation. That said, in that case, we may have to split manager and installer, but, whateves. The research and groundwork is there anyway.
This is a bit weird, but when sourching inside a source... SHELLOPTS[errexit] gets set while processing the nested source, and never get's unset... Which... I THINK... Is causing me a bit of an issue... The issue: A bit of an edge case, but, if you SOURCE the manager, close it, and then CALL the manager (./scripts/manager.sh) and close that, it straight up kills your terminal. As an added bonus: If you don't kill the CALL, and it exits on it's own, and go to use tab completion... POOF, THAT kills your teminal... Odd indeed...
Turns out the issue was two-fold: - Mind your line-endings, kids\! - Nested source calls don't reset the environment correctly when inturupted. This coupled with the fact that traps modify the return state, and unless VERY precisely timed, the source call may or may not ALSO modify the return state (with regards to checking success), AND you can't EXIT a command-line sourced script... Made for some fun times. Sorted. Moving on.
Yeah, so, sourcing at the command line is STUPID... But I learned that you can use the bash command the same way. Nice and clean, AND accepts arguments (which piping doesn't, which is why I was shying away from that option). Well that was an experience...
You didn't ask for it, but you got it: - This is the groundwork for a pretty comprehensive commandline manager for OctoScreen. - Supports... Well... Anything, in a pretty robust manner. Right now it really only handles 'install', but I have some boilerplate in there to handle building, as well as LCD configuration. Adding Config File manipulation and other tasks would be fairly trivial too. Hmmmmm... *leans back* yup, cool...
|
Oh yeah, side note: I spent a LOT of STUPID time battling this damn thing because I, for some reason, insisted on using Also: I did end up moving the installed check to the prepare for install. |
|
Another thought, I should probably think about moving the check for if it's 'in a bad way' to the |
|
And finally: I need to remember some of the other notes I have in #240, such as the check that multi-login is not active (that is the only screw up with installing over |
Also not sure if I mentioned that I added `remove`. Additionally, this moves the installed and healthy checks to `octoscreen.main`. Should about do it for building/installing/removing and such.
|
Added Build, and Remove. Also sorted the "installed" and "healthy" checks in main. mazel |
|
Last little update to this conversation and I am walking away: I have used this a bunch to install 2.6 and 2.7 on the same device. And it works a real treat. That said, I have NOT used it to install on a "clean" device, yet. However, it should be good to go in that regard. I will try shortly. |
- Added consumption of local /etc/os-release (made it mandatory, but if this seems incorrect, sure) - Added ability to specify Release Target - Spelling Correction - Made '--nodep' visible
|
Sooooooo... Curiously... Build really doesn't like: Waited the better part of 20 minutes before |
|
OOF, fresh build on a 4:
Yippie... (but, it all worked, bruh, and this is a... er, "kinda fresh" system [hasn't seen this script before, anyway], and 2.7, so... woot) |
|
Note for self:
|
|
@JeffB42 - I know you have other things on your plate right now, and this is the wrong branch to merge this into, but do you have any feedback thusfar? |
Not yet. I've glanced at it but haven't looked at it in detail yet. My plan is:
Yea, I've been pretty busy the last few weeks. I work as a software developer and this is a side project/hobby for me, and the last few weeks have been busy with work and family. I've still been able to work on the weekends on this, but I've been focused with getting 2.7.0 released (a lot of testing, as well as supporting issues that are being reported), and plan to look at this after 2.7.0 releases. Jeff PS. There seems to be interest in a roadmap, so I'll probably create a road map doc in the wiki. I mentioned the roadmap a little in the 2.6 doc, but I'll probably create a separate wiki doc for it. |
|
I get all of this. Find me. If you can, email me. If not, just flag me as a contrib. If any of that sounds weird: I'm drinking. Ignore me. |
|
So I added the LCD install process, sans-options (at this time), and really sans anything, now that it occurs to me that I didn't even add a flag for it... DERP... I will, in a second, maybe. So this is close to complete for the immediate purpose, but I am also wondering about the Splash Screen... I DID include as a service in the primary package in PR #258, but part of me is still on the fence about that... I think that is the right place, but I also wonder if it should maybe be separate? The part of me that says NOOOOO is the part of me that points out it is fairly specific to this system (there is no telling or ensuring it would work with anything else), and it really should be handled as part of the package install process. But, at the same time, it would need a manager, right? For changing the configuration for it? Derp, I think I am over-thinking it. The boot screen gets installed with the package, if someone wants to customize it, they have the config. If we want to add the configuration to the CLI manager, that can be done at a later time... YEAH lol |
The commented line would be un-commented when we allow for optioning, and the lcd35 hidden (but still active) for a time, for backwards-sake.
|
Added the LCD driver flag. This is pretty much feature-complete at this stage as far as I am concerned. I can think of a few things I would change, but for the moment, it seems good enough for deploy. Obviously, as we get feedback, it can be extended. But as far as reliability goes, I have been using it for all of my test builds for the past week, and it has worked a treat. If anyone has any feedback, please let me know, but I am releasing this from draft now. |
This WAS correct, but somehow in testing I buggered it up. Kindly ignore... ;-)
|
How do I install this? OctoScreen for my 800x480 TFT is displaying a higher resolution than the screen (which makes elements display offscreen) |
|
@JeffB42 - Should I get back to fleshing this out? Sure seems like it would be a nice touch. Let me know. |
There is no 2.8 Dev branch, so I am going to add this here for consideration, and we will go from there...
I started walking down this path because of @JeffB42 comment on #240 , but then, as things do, it got out of hand and I wrote some bash scripting libraries and went down the rabbit hole of writing a CLI management script in full... OOPS
Also, unironically, this doesn't actually INSTALL THE LCD... yet. Right now it only handles
install(including what would beupgrade, maybe I should make that it's own handler, or at least a pre-processor... dunno). However, sliding LCD in there is going to be trivial, and the boilerplate is already there, as well as forbuild.IT'S A LOT, I KNOW.
It should be noted: Although this is ~2k lines added, that is mostly helpers, and allows for A LOT of expandability and flexibility. I think it will serve us SUPER well...
Discussion about the layout and "complexity":
sources external scripts as dependencies, EVEN REMOTE:Yeah, this may seem weird at first, but consider: I didn't want this to be one huge file, and I wanted to be able to upgrade/manage any bash utilities separate from the script it's self, so they had to be separate as well. This is not all THAT bad, however. Consider that the deps are sourced from the master repo, so we know (as much as we can) that they are safe. Also, it will use local files if it finds them (executing the script from INSIDE the OctoScreen directory, or the scripts directory). This is to allow for a future plan where this is installed into the OctoScreen dir, and registered as a
bin. But more on that later.echos:There once was a maintainer who said: "OctoScreen attracts many users, with different levels of experience in Linux, so try and think of ways the script might fail, and try and make it bullet proof." Part of that is allowing for OBSCURE AMOUNTS of feedback (for when it is needed).
versionformat we may use: Accounts for Potential MakeFile Development Version Changes #243 or anything elseThis is a matter of streamlining the process. It allows for handling stacked tasks that may be able to consolidate other tasks, like dependency installation (would be a real pain to want to
buildand THENinstallthat built package, and hitapt-getmultiple times for each task, yeah no). It also allows for validation, although I haven't really gotten down that path yet.Execution (for README):
Or if you are OUTSIDE the Git Directory:
Or INSIDE it:
Or (once we install it with OctoScreen):
It even has a
--helpscreen, and--licenseI mean, I'm pretty damn proud here... :-)