Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.development.system > #699
| From | crankypuss <crankypuss@nomail.invalid> |
|---|---|
| Newsgroups | comp.os.linux.development.system |
| Subject | Re: UNIX(*)/ Linux history & system design |
| Date | 2014-05-09 02:23 -0600 |
| Organization | A noiseless patient Spider |
| Message-ID | <lki3a0$t2q$1@dont-email.me> (permalink) |
| References | (21 earlier) <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> |
On 05/08/2014 02:24 PM, Jerry Peters wrote:
> crankypuss <crankypuss@nomail.invalid> wrote:
>> On 05/07/2014 02:25 PM, Jerry Peters wrote:
>>> crankypuss <crankypuss@nomail.invalid> wrote:
>>>> On 05/07/2014 09:23 AM, Rainer Weikusat wrote:
>>>>>
>>>>> Would you care to elaborate why precisely you consider it to be 'so
>>>>> crude that it is astonishing it didn't vanish'?
>>>>
>>>> Do I really need to elaborate on that? Only positional parameters for
>>>> functions, no builtin functions to speak of, which drives the user to
>>>> using sed or some similar external program for even trivial
>>>> functionality. It's a very basic script processor, not a language. On
>>>> top of that, the bash rules for escaping the characters it has coopted
>>>> for special purposes make it a syntactic nightmare even worse than C.
>>>> The fact that someone kludged control structures onto a simple
>>>> substitution engine does not make it a programming language.
>>>
>>> But sed, date, awk, and all of the other text processing utilities are
>>> the "library of functions" for shell programming. Why should there be
>>> duplicate functions in bash?
>>
>> Our concepts of what "shell programming" means is not even close to the
>> same. You are apparently content with what a history of add-ons has
>> provided. By all means, carry on.
>
> I could say the same about C, which also has a long history of "add
> ons" which make it better and add useful features.
> I'm pointing out that *useful* languages tend to have some sort of
> "library" of routines available, Python, for example has a rich set of
> extension modules, as does PERL. For the shell the common UNIX command
> line utilities provide this rich environment.
The common UNIX command line utilities provide only *HALF* of this rich
environment. The option/argument format commonly used for command
invocation provides the passing of boolean options, string options, and
positional string arguments, as defined by the target command.
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; 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 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.
And the poor "caller" is forced to parse the command output, which in
bash scripts is a hideous mess requiring even more external commands
like 'sed' because bash scripts lack sufficient builtins to perform the
parsing themselves.
The whole thing is a massive kludge, and imo the longer we wait before
fixing it the more difficult it will be to ever fix it. I would say "if
it is not already too late", but I am of the opinion that it has been
too late for years, decades even, and that truly fixing it while
allowing existing code to continue functioning may require a level of
cleverness exceeding that which is available.
I'm not just "whining Dixie" here, one of the projects I'm working on is
headed in the direction of providing a possible replacement for much of
what is involved, but it moves at its own pace. If by commenting in
this thread I can succeed in getting even a /few/ people to grasp that a
problem exists, then that is a minor victory.
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