Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Newsgroups: comp.os.linux.development.system
Subject: Re: UNIX(*)/ Linux history & system design
Date: Fri, 09 May 2014 18:36:59 +0100
Lines: 52
Message-ID: <87bnv6c0qs.fsf@sable.mobileactivedefense.com>
References: <limvgj$tse$1@dont-email.me> <ljdbhe$ol8$1@dont-email.me> <87k3adxomn.fsf@sable.mobileactivedefense.com> <ljg06q$f5s$1@dont-email.me> <87wqear01o.fsf@sable.mobileactivedefense.com> <ljl6uh$rbi$1@dont-email.me> <874n1dwvo0.fsf@sable.mobileactivedefense.com> <87zjj5vf1k.fsf@sable.mobileactivedefense.com> <ljnp3t$ni7$1@dont-email.me> <87k3a0q867.fsf@sable.mobileactivedefense.com> <lk91qa$9l3$1@dont-email.me> <lk965t$3o3$1@dont-email.me> <lka3vv$r0j$1@dont-email.me> <87zjivatio.fsf@sable.mobileactivedefense.com> <lkchdq$jqn$1@dont-email.me> <87a9atpq7y.fsf@sable.mobileactivedefense.com> <lkdoa0$t83$1@dont-email.me> <lke4ra$n51$1@dont-email.me> <lkfk0f$126$1@dont-email.me> <lkgp5k$csf$1@dont-email.me> <lki3a0$t2q$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: individual.net jopdePsU6Rmr1jKpyrK1FQuTbyRWGgWxOgPAUaX/t6OFTmbPM=
Cancel-Lock: sha1:EIHtdvNwtwc4dLqTDrB26SAo9lo= sha1:Lg3H1r6oqtrTNxnf7ejwmGASpVw=
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)
Xref: csiph.com comp.os.linux.development.system:701

crankypuss <crankypuss@nomail.invalid> writes:

[...]

> But the caller (invoker of the command) receives as a result from the
> command only a simple exit-code and whatever command-specific text has
> been output to stdout (or stderr).  It is up to the "caller" to parse
> the "result" text and hopefully make sense of it.
>
> If the C language were suddenly restricted that way, people would
> immediately revolt by finding some other language to use;

Considering that C neither supports automatic memory management nor easy
parsing of text, that's not exactly a surpising.  

> that "shell" languages are forced to operate in this restrictive mode
> is accepted because that's how the first crude shells were implemented
> and they evolved ad-hoc from there.
>
> Parsing the textual output of a command is basically a "bad" thing for
> a number of reasons, primary among which imo is that it generates an
> ever-increasing codebase which depends on command output remaining in
> its initial (or previous) format.

That's your opinion. A guy named Doug McIlroy, however, was pretty
convinced that programs should be able to process the output of other
programs and that their output might, in turn, be processed by yet other
programs, cf

	To put my strongest concerns into a nutshell:

	1. We should have some ways of connecting programs like garden
	hose--screw in another segment when it becomes when it becomes
	necessary to massage data in another way.
        
        http://cm.bell-labs.com/cm/cs/who/dmr/mdmpipe.html

> That now-massive codebase pushes very hard against the possibility of
> change, because a change in the format of the default message output
> of one of the core commands would invalidate so much existing code
> that it must be avoided.
>
> When it is necessary ("oh, never thought of that", or "look, something
> new was invented!") to change existing command output format, in
> marches yet-another-option to request the new format instead of the
> old one, and with it additional logic and additional possibilities for
> errors within the modified command.

It is absolutely not 'necessary' to keep hacking features into a single
program until the source code collapses into a singularity under its own
weight. Sometimes, writing a new program might be a better
idea. Actually, most of the time.