Groups | Search | Server Info | Keyboard shortcuts | Login | Register
Groups > comp.os.linux.development.system > #701
| From | Rainer Weikusat <rweikusat@mobileactivedefense.com> |
|---|---|
| Newsgroups | comp.os.linux.development.system |
| Subject | Re: UNIX(*)/ Linux history & system design |
| Date | 2014-05-09 18:36 +0100 |
| Message-ID | <87bnv6c0qs.fsf@sable.mobileactivedefense.com> (permalink) |
| References | (16 earlier) <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> |
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.
Back to comp.os.linux.development.system | Previous | Next — Previous in thread | Next in thread | Find similar
shred or scrub "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-16 18:17 -0400
Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-17 04:19 -0600
Re: shred or scrub "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-18 22:30 -0400
Re: shred or scrub Jasen Betts <jasen@xnet.co.nz> - 2014-04-19 07:42 +0000
Re: shred or scrub Richard Kettlewell <rjk@greenend.org.uk> - 2014-04-19 10:04 +0100
Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-19 02:15 -0600
Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-19 23:05 +0100
Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-20 02:47 -0600
Re: shred or scrub John Hasler <jhasler@newsguy.com> - 2014-04-20 07:56 -0500
Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-21 03:51 -0600
Re: shred or scrub Jasen Betts <jasen@xnet.co.nz> - 2014-04-21 11:50 +0000
Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-21 06:14 -0600
Re: shred or scrub "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-21 18:44 -0400
Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-21 13:24 +0100
Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-22 04:10 -0600
Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-22 14:39 +0100
Re: shred or scrub Kristof Provost <kristof@codepro.be> - 2014-04-17 13:15 +0000
Re: shred or scrub John Hasler <jhasler@newsguy.com> - 2014-04-17 09:40 -0500
Re: shred or scrub Kristof Provost <kristof@codepro.be> - 2014-04-18 14:40 +0000
Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-18 02:12 -0600
Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-18 11:49 +0200
Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-18 09:59 -0600
Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-21 16:14 +0200
Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-22 04:22 -0600
Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-23 00:06 +0200
Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-23 05:50 -0600
Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-24 22:46 +0200
Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-25 03:57 -0600
Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-25 19:14 +0100
Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-26 04:02 -0600
Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-27 21:26 +0100
Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-28 03:27 -0600
Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-28 12:17 +0100
Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-28 13:01 +0100
Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-29 02:50 -0600
UNIX(*)/ Linux history & system design (was: shred or scrub) Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-05 21:31 +0100
Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-05 16:02 -0600
Re: UNIX(*)/ Linux history & system design David Brown <david.brown@hesbynett.no> - 2014-05-06 01:17 +0200
Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-06 01:46 -0600
Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-06 15:09 +0100
Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-06 23:47 -0600
Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-07 16:23 +0100
Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-07 10:51 -0600
Re: UNIX(*)/ Linux history & system design Jerry Peters <jerry@example.invalid> - 2014-05-07 20:25 +0000
Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-08 03:50 -0600
Re: UNIX(*)/ Linux history & system design Jerry Peters <jerry@example.invalid> - 2014-05-08 20:24 +0000
Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-09 02:23 -0600
Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-09 18:36 +0100
Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-09 21:24 +0100
Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-07 22:01 +0100
Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-08 03:37 -0600
Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-08 14:02 +0100
Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-09 02:56 -0600
Re: UNIX(*)/ Linux history & system design David Brown <david.brown@hesbynett.no> - 2014-05-07 00:15 +0200
Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-07 00:32 -0600
Re: UNIX(*)/ Linux history & system design Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-05-07 08:47 +0000
Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-07 10:59 -0600
Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-06 14:35 +0100
Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-26 16:30 +0200
Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-27 05:59 -0600
Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-27 20:15 +0100
Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-28 03:29 -0600
Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-28 12:06 +0100
Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-27 21:41 +0200
Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-28 04:03 -0600
Re: shred or scrub Richard Kettlewell <rjk@greenend.org.uk> - 2014-04-28 16:44 +0100
Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-28 23:39 +0200
Re: shred or scrub John Hasler <jhasler@newsguy.com> - 2014-04-18 07:37 -0500
Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-18 10:16 -0600
Re: shred or scrub John Hasler <jhasler@newsguy.com> - 2014-04-18 12:01 -0500
Re: shred or scrub Kristof Provost <kristof@codepro.be> - 2014-04-18 14:42 +0000
Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-17 16:41 +0200
csiph-web