One major reason I’m not fond of fork/exec componentizing

In Debian Linux recently the CryptKeeper encryption package fails to properly set passwords due to a bug fix in the command line handling of a package it runs (see this Register article for more details) .

It appears that the code was tested and worked perfectly in previous versions. The tool being used had a minor bug in its command line processing that resulted in the password being accepted even though it was placed improperly. Once the maintainers of this package fixed their big, the string sent by the CryptKeeper package resulted in the letter ‘p’ being taken as the password and the actual password being ignored and it would appear discarded.

It seems to me that Linux could use a universal (or nearly) –API switch that converts the command line and stdin/stdout/stderr to something like JSON with extensive and aggressive checking for validity in all inputs along with tightly specified outputs.

Most programmatic usage of command line tools that I’ve encountered to date makes broad assumptions about the details of the input and output formats for human usable tools. In most cases I’ve seen the checks for unexpected data are weak and porous. This generally results in tools that are fragile and often either need manual tweaking or are simply tied to a specific version of a particular distro. The alternative (less common but I’ve encountered it as well) is to force tools whose primary interaction is with humans on the command line to lock down the original output formats in ways that don’t necessarily work well for people in order to avoid breaking programs and scripts.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.