Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Newsgroups: comp.unix.shell
Subject: Re: Command Languages Versus Programming Languages
Date: Fri, 29 Mar 2024 12:36:34 +0100
Organization: A noiseless patient Spider
Lines: 34
Message-ID: <uu6943$91br$1@dont-email.me>
References: <uu54la$3su5b$6@dont-email.me> <87edbtz43p.fsf@tudado.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 29 Mar 2024 11:36:36 +0100 (CET)
Injection-Info: dont-email.me; posting-host="e69c431b514d7dea0b983a8ae814ccd0";
	logging-data="296315"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX190W/6OjKKv5OdfAQdZF7qm"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:u8OKecLS/u4/vL8HP2RP166SYIs=
X-Enigmail-Draft-Status: N1110
In-Reply-To: <87edbtz43p.fsf@tudado.org>
Bytes: 2503

On 29.03.2024 12:09, Johanne Fairchild wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> 
>> At one time, we distinguished between “scripting” languages and
>> “programming” languages. [...] But there is one distinction that I
>> think is still relevant, and that is the one between shell/command
>> languages and programming languages.
> 
> [...]
> 
> Consider looking at a shell language like a domain-specific programming
> language.  A shell is a programming language made specifically for
> running programs.  When you write a shell line, you're specifying the
> arguments of execve(2).  In other words, a shell is a programming
> language made to prepare the memory to be consumed by the system in a
> specific way---execve(2).  (Of course, the idea evolves and you want to
> glue programs, do variable substitution et cetera.)

I like the characterization as domain-specific programming
languages.

The "glue" is also control constructs (if/case/while/for/...),
which are typical characteristics of programming languages.

It's not only 'exec'. You can also view the exec'ed commands
as the functions from a "library" (/usr/bin, etc.), called
from the shell's control logic.

That's another view that may be better suited when inspecting
the modern more powerful shells than the legacy ones from the
1970's (which of course also had control constructs already).

Janis