Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > comp.os.linux.development.apps > #727

Re: UNIX(*)/ Linux history & system design

Cross-posted to 2 groups.

Show all headers | View raw

crankypuss <crankypuss@nomail.invalid> writes:
> On 05/07/2014 03:01 PM, Rainer Weikusat wrote:
>> crankypuss <crankypuss@nomail.invalid> writes:
>>> On 05/07/2014 09:23 AM, Rainer Weikusat wrote:
>>
>> [cross-posted to colda with follow-up to, as this is not really about
>> system development[*]]
>
> Actually it rather is, but clearly you do not see it that way;
> apparently you are able to look at "bash scripts" that are part of the
> init system, and "bash scripts" that are divorced from the system
> insofar that they do not participate in boot-manager setup (cf grub2)
> or similar functions, without seeing that they are in any way similar.

Something like this was my idea when I changed the subject. But since
the topic has shifted more towards 'apply something to some use' and I'm
actually doing 'application development' and not 'system development'
(except when necessary/ unavoidable) and consequently, use the shell
rather for that (and some people staring making annoyed noises I sort-of
understand [or believe to do so] ...) ...

>
>> [*] It is not terribly on topic, there, either, but 'shell-related
>> groups' tend to be inhabited by 'strange people' solely busy with
>> telling others why the shell mustn't be used (a la 'in 1492, on a
>> DUCStation Donald running Infrix PI - 12, /bin/sh was really a hard link
>> to /usr/ucb/bbc/cia/doa, therefore, this code is not only not portable
>> but will actually cause a major earth quake in California' ...) and I'm
>> more interested in 'using the shell to develop actual applications' than
>> 'Klingon-quoting in hostile environments' ...
>
> Oh look, it has called me "strange", what a quaint and helpful
> introduction, thank you ever so much!

I didn't address anyone personally and actually consider 'behaviour of
people belonging to recognizable groups' generally strange, eg, "on
weekends, this pub is populated by strange people who seem to enjoy
making loud, ugly noises aka 'shouting' very much (at least, they keep
doing this for some inexplainable reason), seem to enjoy drinking until
they can't walk straight anymore (I can understand the first part but
not the second: As soon as this starts to happen to me, and usually, I
avoid that, I'm obviously having a technical problem and should go home
before I trip over a kerbstone and break a leg or something like this)
and who don't ever seem to get much beyond being an arbitrary appendix
of their own sex life (I'm totally flabbergasted that they're apparently
never bored by this topic)".

Computers are easier to deal with: They usually don't resort to violence
when they feel mistreated, hence, "how to avoid mistreating them" can be
determined by experiments.

>
>> [bourne shell language]
>
> following from RW:
>>>> In addition to constructs specific to its purpose, ie invoking
>>>> programs, possibly, programs cooperating in a pipeline, it supports the
>>>> usual syntactic constructs available in 'pre-OO' high-level languages:
>>>> Three kinds of loop ('loop while a condition is true', 'loop until a
>>>> condition becomes false', 'loop over the elements of a list'), loop
>>>> control statements ('break' and 'continue'), conditionals (if .. elif
>>>> ... elif ... else, a 'case statement' and the possibility to create
>>>> named subroutines (but not lexically-scoped variables, although bash has
>>>> them as an extension). It doesn't use braces as universal block
>>>> delimiter but keywords depending on the 'block construct' being
>>>> used. For loops, thats do .... done, for if then ... fi and for case, it
>>>> is case ... esac. The latter two pairs are Algol-68 influenced,
>>>> presumably, because Steve Bournce (author of the original Bourne shell)
>>>> was very fond of that. It doesn't support named parameters for functions
>>>> (or scripts), only positional ones. While I wouldn't to use it (in case
>>>> suitable alternatives are available) for something larger than at most a
>>>> few hundred lines of code[*], it is a perfectly usable programming language
>>>> and often, a very easy to use one.
>>>>
>>>> Would you care to elaborate why precisely you consider it to be 'so
>>>> crude that it is astonishing it didn't vanish'?
>>
>> [...]
>
> from C (the first elaboration):
>>> Only positional parameters for functions,
>
> from RW:
>> There are (to the best of my knowledge) the following models for dealing
>> with 'parameters passed to something'
>>
>> 	- assign passed parameters to predefined 'parameter names' 'by
>>            position', possibly with support for optional or 'default
>>            value' arguments
>>
>> 	- parameters are passed in form of 'key/value'-pairs where the
>>            'key' designates the name of a possible input parameter and
>>            the value its value
>>
>> 	- access passed parameters by position

[...]

>> The third is the most general as it can> be used to emulate the
>> other two,

[...]

> from C:
>
> It's a shame that at one level or another we are all surrounded by
> things we don't truly understand.
>
> In regard to a shell language, one should (imo, of course, which you
> have already implied is "strange") perhaps consider the actual form of
> the 'nix command string, which provides for the passing of both
> arguments and options, in other words, positional parameters
> (arguments) plus key/value pairs (options of the short or long
> flavor), as appropriate to the function performed.

I think I already wrote that: An ordered sequence of arguments can be
interpreted as 'positional argument list' or 'set of key/values pairs'
or both. 'getopt' is both a C library routine and available to 'shell
scripts and functions defined by them' (I think the lack of both
lexically scoped parameters and lexically bound dynamic parameters is a
much graver deficiency, at least theoretically).

> You might also consider the possibility that a "functional" script,
> that being one which is called to perform a specific function and
> passed whatever parameters are appropriate to that function, *might*
> benefit from being able to return data to its caller beyond a simple
> exit-code and whatever possibly-parseable string data it has written
> to stdout or stderr, a "result" that does not have to be parsed by

Whatever facilities might be available in a given environment, they
could always be improved ...

> something as crude as 'sed' in order to obtain an approximation of
> what could simply be returned.

... by adding missing functionality. Eg, a C function can 'simply
return' any C type or a pointer to a C type, however, if that is
supposed to be written to a file in order to be processed next week or
on a computer in Tierra del Fuego, the ability to serialize and
deserialize a complex data structure could also be very helpful. In
general (truism ahead), different programming environment provide
different features and usually, lack some other features. And "weeping
oneself into sleep because reality is much more harsh and ugly than one
would like it to be" usually doesn't accomplish anything.

>>> no builtin functions to speak of, which drives the user to
>>> using sed or some similar external program for even trivial
>>> functionality.
>>
>> The main purpose of the shell is to provide facilities for invoking
>> external programs within a 'global control context' supplying the
>> facilities for using these 'library routines' in order to solve more
>> complex problems than what could be done with them in isolation.

[example program with explanation]

>>> It's a very basic script processor, not a language.
>>
>> The 'shell program' is an interpreter for 'the shell language'.
>
> I am constantly amazed at the way some can, through the tunes of the
> unthought words they parrot, consistently hide what is not there by
> covering it with popular illusion.

I'm pretty certain that you never heard anyone speak to me, hence, you
cannot possibly know what I might or might not have heard elsewhere, and
you certainly can't read my mind, hence, you know nothing about 'my
thoughts' (or lack thereof). 

>>> 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.
>>
>> In theory, yes. In practice, "it can be dealt with", especially
>> considering that a lot of 'shell code' is supposed to operate in a
>> rather controlled environment.
>
> Yes, it is sometimes possible to use a three-headed hammer to adjust a
> watch.

An interpreter is not a hammer and 'adjusting watches' not something
programs usually do, IOW, this doesn't really communicated anything
except that you're strongly convinced that something I consider to be
'fit for purpose' (for some purposes) because of in depth practical
experiences with it isn't really 'fit any purposes' and you rejected it
almost outright because of this (earlier, you wrote that you had written
'exactly one shell script'). That's your prerogative but I disagree with
it.

Back to comp.os.linux.development.apps | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

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 David Brown <david.brown@hesbynett.no> - 2014-04-17 16:41 +0200
  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 Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-08 15:43 +0100
        Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-09 02:56 -0600
          Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-09 17:57 +0100

csiph-web