Rixstep
	`About \| ACP \| Buy \| Industry Watch \| Learning Curve \| News \| Products \| Search \| Substack`

Home » Learning Curve

Using CLIX

Rixstep can offer CLIX; it's up to you to take advantage of it.

Get It

Try It

Background

CLIX was born in the nascent period of OS X when the plurality of users were legacy 'MacOS' users with little or no knowledge of Unix. Carpetbaggers came on the scene to sell their snake oil with hidden Unix commands otherwise accessible through the command line. Apple have also gone out of their way to hide the extent of the underlying operating system, making basic Unix directories nigh on impossible to access and making over 800 classic and often used Unix programs out of the reach of users.

The carpetbaggers learned to use Interface Builder (a graphics design program) and Project Builder (and later Xcode) to write rudimentary Cocoa shell applications to wrap obfuscated AppleScript modules which in turn called the otherwise unknown Unix programs.

Any Cocoa program can wrap a Unix program; the fact that AppleScript was used to obfuscate the use of already available Unix programs shows the carpetbaggers were trying to hide what they were doing.

The new OS X users needed to learn how to use their platform, yet the carpetbaggers weren't teaching them anything; they ran the desired commands but demonstrably did not offer a clue to the knowledge-thirsty users what was really going on.

Not only were 'secrets' users wanted to learn deliberately hidden from them but the carpetbaggers locked the functionality of their products into inflexible graphical interfaces that required an upgrade (and a further payment by the user) to expand and enhance. And the user was always left at the mercy of the vendor - only features the vendor put in the program could be used; the user was powerless.

Worse still, the carpetbaggers often grouped at times unrelated commands together and the user got an 'all or none' option - and if something went wrong with the system the user was almost powerless to trace the error.

The carpetbaggers didn't care about niceties like cleaning up preferences: they never checked what the system defaults really were; the user had little or no way to 'restore' a system to its pristine condition because the 'software' didn't care.

These programs would also demand the user's administrator password just to run - and then stored said password in either plain text or base64 in a preferences file, leaving the computer open to an easy attack.

Further, as Apple explicitly do not allow privilege escalation through their scripting engine, the carpetbaggers simply passed the administrator passwords onto the background programs in plain text in full light of day for all interlopers to see and use - and then of course kept completely quiet about the matter and never told a soul systems were being left open to attack.

The Truth Sets You

The idea behind CLIX was to provide a free replacement for this chicanery - and yet from idea to implementation took considerable time: what was needed was a solid yet flexible model so users could modify, add, and delete functions - and above all receive immediate answers to the perennial question 'how the ____ do you do that?'

The decision was to stay with a basic database management model. And from the 'detail' view (a Cocoa 'sheet') to engineer the ability to run these Unix commands directly - and completely 'WYSIWYG'.

Development time was initially estimated to be about one half workday; it turned out to take seven hours for two people to complete.

The initial release had several limitations. Amongst other things it was found that generation of the output window text put undue strain on the application's virtual memory usage and so output was truncated at 128 KB. Later a way to optimise this operation was found and the truncation was removed.

The original idea was to provide a shell and a newsletter where users could exchange useful command lines - thus the CLIXchange newsletter was born (and later the independent CLIX Exchange forum). In moments of boredom the developers used Xfile to peruse the Unix directories and add new commands of their own. Today CLIX comes with close to 1500 useful Unix commands, dramatically dwarfing what the carpetbaggers collectively touted as offering.

[And it's important to remember CLIX is extensible: new commands you or anyone comes upon can be added to CLIX immediately. Ed.]

It's hard to remember what Unix commands are available on OS X unless you have either a nanopixel memory - or Xfile.

Database Model

The model for CLIX was Xbase but with a static configuration with four columns of data: Title, Category, Description, and Command Line, sorting in both ascending and descending order.

Sorting by either of the two first columns involves a nested sort using a proprietary 'dictionary' algorithm: in the first pass of the sort elements are sorted case-insensitive and if two elements match they are then sorted case-sensitive. Further, no matter if you sort by Title or Category the sort will always be nested with the one column being sorted within the other.

Rixstep's general purpose flat database manager Xbase was used as the chief design model for CLIX.

The 'detail' sheet is used to run commands. Four buttons at the lower right manage the necessary tasks for running and stopping commands, for closing the sheet, for saving changes, and for copying the contents of the output window to the clipboard.

The decision was made to not put both the 'master' and 'detail' views in the same window as separate panes so as to afford the user more 'working space' with fewer constraints.

The 'Command Line' field is somewhat larger than the others so long command lines are still visible. You cannot insert newline characters into command lines but you can use the semicolon (';') for the same purpose instead.

It is not wise to edit CLIX command files with a text editor, even though they appear to be plain text, as they're using 'Unix DSV' to separate columns of data: certain values have to be 'escaped' in a certain way. Commas and backslashes are the two characters dealt with in this fashion.

Sudo Privilege Escalation

As many commands require authorisation a special 'sudo' sheet was introduced. The corresponding menu item was deliberately kept on the 'wrong' menu for security reasons.

If the sudo sheet comes up on a document window then its menu item shouldn't be on the application menu; it was considered necessary to couple the sheet to a document window to avoid situations where input panels could be lost by the user, later to be found and exploited by interlopers. The only way around this would have involved creating a fully application modal window, but this would have undermined security considerations of another sort - see below.

The sheet is totally modal: although any document window can in principle invoke this sheet, only one such sheet can be visible at any one given time. If the sudo sheet is invoked and another document window is currently displaying it, focus moves to that document window and its own sudo sheet - this so users do not waylay their sudo sheets.

The sudo (administrator) password is never stored on disk and its internal storage is obliterated when the computer goes to sleep. This obliteration also covers the input field in the sudo sheet, if visible: all is 'zapped' when the computer goes to sleep.

Had the sudo sheet been an application modal window instead, the notification that the system was going to sleep would have never reached the application - see above.

When your computer goes to sleep, CLIX clears your administrator password everywhere - even in exposed text fields.

CLIX does not run commands through a TTY but nevertheless the sudo time stamp is killed on command exit (and currently immediately before running commands). Sudo allows a default grace period of five minutes before requiring a password again; an interloper can otherwise easily piggyback onto previous authenticated commands.

As long as CLIX is going this far, it might as well go all the way: when the system goes to sleep CLIX kills all time stamps everywhere for all possible TTYs as well - so even open (and authenticated) Terminal sessions will lose their authorisation.

It is very important to always know why you are being prompted for your password: you should never run scripts you don't control. CLIX will automatically submit your password when needed - and this is a great convenience - but you won't see when it occurs. Either secure your scripts (execute only and owned by root:wheel) or else store the entire script inside CLIX.

Mac|Life: Using CLIX

Perhaps the best article ever written - on this site or elsewhere - on using CLIX can be found at Mac|Life. It's a brief article but the accompanying illustration is in this case worth at least 1,000 words and the author shows step by step how to use CLIX.

Taking things in a somewhat different order you'd:

Browse (with your file manager or the CLIX open file dialog) to a CLIX command file of your choosing. Currently 1,400+ commands accompany the download in approximately eighteen files. [The files use the extension 'clix' but you can use any extension you like (or no extension at all).]

Browse commands by Title, Category, Description or Command Line.
Double-click a command (Edit-Edit on the menu) to open it in the command sheet.

Tweak the command as you like and then click 'Run' to run it.
Click 'Save' to save any changes you made (and close the sheet). [Note: this only saves the command back to the command database and does not save the command database back to disk, so if you made a mistake, simply close the document without saving changes and then reopen it.]

Once the command has run (or if you've stopped it by clicking 'Stop') the output text will be available for copying to the clipboard; this is plain text and can be pasted into any plain text editor.

Finally, click the 'Close' button to close the command sheet (without saving any changes).

[And of course copy, cut, delete, paste, and drag and drop commands as you wish between CLIX document files. Ed.]

Title, Category, Description

Only Command Line fields are chiseled in stone - and even these you may find reason to alter. The Title, Category, and Description fields are completely arbitrary - as are the names of the CLIX files themselves. You organise your files as you want, define titles and categories as you want, and add comments et al to the description fields as you want.

Additional Features

As CLIX uses Unix programs extensively and as these programs normally have their documentation in so called 'man pages' CLIX can also offer a convenient access to these.

There are a number of ways to invoke this help facility and a choice between two help systems to use.

The first help system is 'built in': when you invoke it your powder blue output window turns Macintosh beige and the manpage you requested comes up reformatted to fit your window.

Just click the empty area immediately to the left of the push buttons to summon up the CLIX manpage feature.

The second help system uses an external (free) utility called ManOpen. Details on the download are available in the CLIX documentation.

To get at these help systems you have to find the hidden text field on the CLIX command sheet. [It's to the left of the push buttons but kept hidden for aesthetic reasons until you click on it.]

Enter any keyword and hit Enter; prefix a keyword with '-k' to invoke the 'apropos' feature which lists all 'related' manpages.

But while working in the Command Line field on your command sheet you can also option double-click on a word to get the same manpage help for it; and cmd double-click on the word to get 'apropos' help.

Flipping between the built in system and the external ManOpen system is done with a CLIX command also found in the CLIX download. [Look for the file _mo.clix and take it from there.]

Caveats

Any command using sudo - whether in CLIX or from the Terminal command line - is subject to foul play. The Rixstep site has numerous articles about the inherent dangers and how you protect yourself from them.

CLIX does what it can to protect you - more than will for example happen with your Terminal. CLIX namely scours your $PATH so no extraneous (malicious) programs can creep onto your system and be executed instead of the commands you want to run.

ACP users can avail themselves of the Resolve Path facility to see where their commands will go before they run them. All command invocations are expanded to use full paths; if something's not right you'll see it at once and not be compromised.

[Note: Resolve Path works with any Cocoa program, in any context - not just CLIX. Resolve Path is part of the ACP Text Services and as such available only to the ACP subscribers. Ed.]