Nice!

Way back when I was daily driving an SGI IRIX box, I was struck by how SGI often made IRIX system programs dual mode, command line and or GUI.

On the command line, one could specify -v or --verbose or -GUI and generally get the desired outcome.

Some programs, usually the ones with some sort of -GUI option, or that would detect the user running on an X Window system, contained the GUI mode in the same executable. And it would just appear on whatever display was specified in the user environment.

Others, generally the ones offering --verbose style output, were designed so that GUI wrapper type programs could just call them and have a robust enough command line interface so as to support a GUI without the user experience suffering much, if at all. All that extra output was so a gui could display options, progress, and all the things we might expect. The program just streamed that stuff on STDOUT, GUI streaming actions on STDIN and both using STDERR as needed.

neato!

Anyhow, I loved that kind of design. Learning either the GUI or command line was cross productive, generally speaking.

And back in the 90's and 00's when all this was happening, IRIX was NICE. Seriously. I cannot count the number of people who would come by and end up talking shop, often prompted by various desktops they might see in action.

Sidebar = 1

I really do miss that compute environment. I rarely have experiences in computing as good as all that was back then. I know, an SGI was a ton of money! But damn! Worth it to many.

Often felt like computing a little ways into the future:

We would be playing 3D games in the 90's via X and or various boxes capable of running them locally, all while yelling and making faces at one another via web cam and mic, sharing videos and files with one another using standard desktop tools included with the Indigo Magic Desktop, and more...

The PC got there close to a decade later, but I digress...

Sidebar = 0

We have bigger, faster and recently, more functional systems today. Things are almost there!

(In both Unix and Windows land, surprisingly)

What you say? Almost there?

Back then, say I wanted to bring up a new box, then perform software management on it.

The system bring up would start with a nice GUI running under ARC loader.

That would get a person into single user mode where one would run "swmgr" and specify the system load and sometimes additional software to be loaded.

Powerful commands got this done quickly.

Keep default

Add [subsystem name or wildcard]

Resolve conflicts would bring up a list one could work through, or one could also just specify a default, the system would sort it and then...

Go.

And soon you had a running system!

Run "swmgr" again, and this time you got a GUI that looked a lot Ike package management tools do today, but with hidden power!

Say you asked something to be installed and part way though disk ends up near full.

The SGI system would allow one to pause the current operation, yielding time to solve the problem simply through file management, or adding space. Whatever.

But, it would also allow one to start another operation right in the middle of one in progress too!

Often, I would Uninstall bigger subsystems not used often, and then carry on with the initial operation, all while...

A user is at the machine working! And I could do that graphically, thanks to X and multi user graphical computing, or command line, old school UNIX style, or both!

They might notice the high disk activity, but it was rare to see their work impacted beyond that. I could always bump the admin tasks to low priority, or bump their task up depending on what mattered most.

Managing those kinds of things command line is crazy, but possible. And scriptable.

Using a GUI is still a bit crazy, but a lot more possible, but not so scriptable in the GUI.

Because of how so much was made to work either way, it just did not matter much. Anyone wanting to automate could.

And there was always Tcl/TK for crude GUI actions in shell scripts. That was hard enough to be unused by me unless the automation was really going to see a lot of use and varied scenarios to make the effort worth it.

These functions seem much simpler than I recall from back then. And it appears one can write programs that work with the best of them too.

An application could be a combination of shell code, compiled C or Python, or any other thing, even the likes of Fortran, and the GUI tools presented here provide the user with more than enough.

Neat!

I going to have to test drive this by making a wrapper for something I use a lot.

And I look at tools like gparted and realize creating more like that one may just have become easier?

Double neato!