On 17.09.2023 17:14, Muttley@dastardlyhq.com wrote:
> On Sat, 16 Sep 2023 23:46:04 +0200
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>> On 16.09.2023 10:58, Muttley@dastardlyhq.com wrote:
>>> On Fri, 15 Sep 2023 17:46:39 +0200
>>
>> Not perfectly sure I understand the "a substitute interpreted language"
>> here correctly. For sure a shell is (and always was; since Bourne) an
>> interpreted language. (And David Korn certainly, and correctly, named
>> ksh as what it was intended, a "Command and Programming Language".)
>
> A substitute for interpreted languages such as perl or python. Ie easy to
> write with a lot of functionality but slow as hell. [...]

Okay, I see where you're coming from. A few comments...
The argument should probably be the other way round; perl and python
(for reasons we may leave alone for the moment) are [maybe] meant as
substitute for shell (where shells were here earlier as inherent part
of the Unixes).
Speed is indeed an issue with shells, though mind; bash is faster than
old Bourne sh (because of built-in functions that avoid costly external
tools/processes), and that Kornshell is a lot faster then bash (as one
of its central runtime optimization design criteria).

>>
>> (This appears to me to be a very limited application view.) - Are you
>> saying here that already in 1988 (or 1993 ?) Korn (et al.) provided
>> extensions to Bourne sh that were unnecessary? - You think a shell is
>> (and should be) just a command line processor (like MS cmd, or so)?
>> Even Bourne sh had while/for/case/if/... and signal traps.
>
> Yes it does, and its as ugly and hacky as fuck with idiotic syntactic
> quirks just like most shells.

I basically agree on that. Though the control constructs frame of the
sh-family (the part that was heavily influenced by the [probably most
formal] Algol[68] language) is still an outstanding clean concept!
It's amazing that in Unix they invented such a language base for stuff
that was formerly handled by simple "command processors".
The ugly stuff, all that cryptic syntax parts, is indeed a "challenge"
for the programmer. Note here, though, that even that ugly part of the
shells' syntax has been made to some degree coherent by the Kornshell
designers (and some made their way into the POSIX sh and other shells).

> No sensible dev uses shell beyond kicking
> something off and maybe simply monitoring. Sysops however whom mostly can't
> code well to save their lives seem to think programming in shell is normal
> because often thats all they know.

(These opinions, prejudices, and generalizations can't be sensibly
commented on; I abstain. It certainly doesn't [generally] match with
the various folks that are doing such tasks hereabouts that I've seen.)

>
>> It's really hard to understand (from your statements) your view what
>> you think a shell should provide and what it shouldn't. Some examples
>> would help.
>
> Sub shell, co processes, process substitution, lists, idiotic numeric
> syntax with (( )) everywhere (not to be confused with () or [[]] !) and
> make sure you use your whitespace correctly because [hacky historical reasons].

This is correct. To pick out one prominent example from your list...

Numeric processing. You wouldn't do math, say, algebra with matrix
calculations in shell. But you have to handle numbers and numeric
expressions. That's why (besides the clumsy 'let') the $((...)) has
been introduced in shell to write readable math expressions inside
the parenthesis and use its value. The introduction of ((...)) is
a [syntactically] straightforward ksh extension to use an arithmetic
expression as command to control the program flow in the Algol-frame
with a C/C++ boolean logic of arithmetic types.

Similar with $(...), replacing the old Bourne-sh `...`. It's been
introduced not only to fix inherent problems with nesting and the
optical confusion with single quotes and whatnot. The syntax is also
coherent with the (...) expression. Both forms create sub-processes
(conceptually; may be optimized internally to not spawn a process),
one expands the value for use, the other just runs it.

So, yes, historic reasons lead to an evolution of shells that lead
to what we have now. And any language that is designed from scratch
for specific (other) purposes could be defined with cleaner syntax.
Though given the syntax of some newer language [versions], say C++,
current shell versions are not too bad for the areas where we use
them. (But see also my "beginners" caveat in another post here.)

> [...]
>> suited for the tasks I typically do with shell.
>
> So basically you know essentially squat about real programming yet you're

(Don't understand what "squat about real programming" is supposed to
mean.)

> advocating that shell is great for dev. Got it. Reminds me of people who

(I haven't mentioned "dev" anywhere.)

> only know BASIC and wonder why any other language would ever be needed.

Well, I cannot speak about "other people" (as you seem to be able,
as above, here again).

I can only speak for myself (if that's what helps you understanding
the area better); I started using shells from the Bourne family on
a regular basis around 1990. At that time I could fluently program
software solutions in more than half a dozen high-level programming
languages from that time (plus a couple assembler). In the following
decades a couple more languages filled my proficiency list. There was
never a reason to switch from shell (for the tasks suited for shells)
to other languages; also later when (e.g.) perl got more mature and I
used it for (a few) professional tasks [in environments where it was
possible to use] where it was sensible to use it - it was unnecessary.

>
>>> which leads shell authors to bung in features no sane
>>> person in their right mind would ever need, never mind use.
>>
>> Before diving into the details it would be good to know whether you
>> are criticizing Martijn's "ksh93 u+m" fixes, or AT&T's ksh93 or ksh88
>> and POSIX sh.
>
> The list posted a few days ago.

For the second time you didn't answer that question (which was not
about the list). - From this post I infer that you opinion is to
not use shell for (which?) tasks. That perl and python are "better".

That's not much substance. - Good luck, anyway.

Janis

On Mon, 18 Sep 2023 12:05:29 +0200
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>On 17.09.2023 17:14, Muttley@dastardlyhq.com wrote:
>> A substitute for interpreted languages such as perl or python. Ie easy to
>> write with a lot of functionality but slow as hell. [...]
>
>Okay, I see where you're coming from. A few comments...
>The argument should probably be the other way round; perl and python
>(for reasons we may leave alone for the moment) are [maybe] meant as
>substitute for shell (where shells were here earlier as inherent part
>of the Unixes).

Perl yes, though arguably first as an improved awk. Python I don't know. I
suspect it was a clean sheet language that he wanted certain functionality in
that proved useful as a command line and scripting language too and better
than Perl for most things.

>> The list posted a few days ago.
>
>For the second time you didn't answer that question (which was not

I'm not going to repost what he posted. Its easy to find.

>about the list). - From this post I infer that you opinion is to
>not use shell for (which?) tasks. That perl and python are "better".

They're better for most scripting tasks that require any significant logic
and/or mathematics. I'm not claiming they're better for just doing basic unix
housekeeping and admin tasks, that would be silly. If you want to do "ls -l"
and pipe it to a file obviously you'd use shell. But if you need to go through
every file in a directory, sum up some columns in them and print a formatted
subtotalling and totalled result you'd at least use awk if not perl/python.
You sure as hell wouldn't do it all in shell (though you probably could).

On 15.09.2023 20:26, Martijn Dekker wrote:
> Op 15-09-2023 om 16:26 schreef Janis Papanagnou:
>> One thing... - is that version number intentional:
>>
>> $ ./ksh --version
>> version sh (AT&T Research) 93u+m/1.1.0-alpha+49904531 2023-09-15
>
> No. You compiled ksh from the dev branch. Try the release tarball or the
> 1.0 branch :)

Oh, okay. - The first link I tried my git didn't like for a clone.

>
> The dev branch has started diverging from 1.0 in a few ways and is not
> ready for production use.

Okay. (I just tested it cursory, and it seemed to work fine.)

Thanks again.

Janis