On 01/12/2021 11:44, Bart wrote:
> On 01/12/2021 08:15, David Brown wrote:
>> On 01/12/2021 00:52, Bart wrote:
>
>>> I just have my preferences and you have yours.
>>>
>>
>> Yes, and that's fine.  But drop the delusion that your unusual
>> collection of personal opinions is the absolute truth of how programming
>> languages should be.
>>
>
> Here's a summary of what I've been talking about:
>
>                        C (eg)      Me
>
>   Case-sensitive       Yes         No
>   0-based              Yes         No (both 1-based and N-based)
>   Braces               Yes         No (keyword block delimiters)
>   Library Read/Print   Yes         No (read/print *statements*)
>   Char-based text i/o  Yes         No (line-oriented i/o)
>   Millions of ";"      Yes         No (line-oriented source)
>
>
> It's just struck me that all the languages corresponding to the
> left-hand column are generally more rigid and inflexible**.
>
> The ones having attributes from the right are more forgiving, more
> tolerant, and therefore more user-friendly. That would be a desirable
> attribute of a scripting language.
>

Words like "flexible" are of questionable value - they mean different
things to different people. To me, C (and other languages with similar
attributes to those you list here - C is an example, nothing more) is
more flexible. Being case-sensitive is more flexible than
case-insensitive because it lets you choose capitalisation that conveys
more information to the user. Having 0-based arrays is more flexible
than 1-based arrays because it is easier to work with more complex
structures. (Allowing a choice of starting values, and other indexing
types, is much more flexible.) Use of statement terminators or
separators (C has statement terminators, Pascal has statement
separators) makes the language more flexible because your source code
layout can match the structure of the code you want to express in the
way you want to write it, rather than being forced into lines.

(I don't think the other points on your list affect "flexibility".)

Then there is the question of "tolerance" and "forgiving", and whether
that makes a language "user friendly". Here I can accept that your
language may be more "tolerant" and "forgiving", but that's based
entirely on your judgement - nothing on the list here is, IMHO, a matter
of "tolerance".

But having long experience with more static and rigid languages such as
C and C++, and also with more tolerant and dynamic languages such as
Python, I think would be wrong to say one is more "user-friendly" than
the other. It is better to say that they are more suited for different
tasks. Python is much more user-friendly for some case, C for other
cases. A key point here is the dynamic nature of Python - it lets you
write code at a higher level (user-friendly), but can't do the kind of
compile-time error checking and control that is possible in C (making it
user-unfriendly).

> Since I develop both a compiled and scripting language which have the
> same syntax, it's natural they should share the same attributes.
>

I disagree. They might share some aspects, but you have different uses
and different needs for a compiled language and a scripting language
(otherwise, why have two languages at all?). Gratuitous similarities
are no better than gratuitous differences.

> (** Except that when it comes to C, compilers for it tend to be too lax
> in unsafe ways. You've got to get that semicolon just right, but never
> mind that you've missed out a return statement in that non-void function!)
>

I agree that a lot of C compilers are far too lenient by default. But
that's easy to solve - don't use the default settings. Adding "-Wall"
or "/W" or whatever flag you need, is not rocket science.

On 01/12/2021 12:12, David Brown wrote:
> On 01/12/2021 11:44, Bart wrote:
>> On 01/12/2021 08:15, David Brown wrote:
>>> On 01/12/2021 00:52, Bart wrote:
>>
>>>> I just have my preferences and you have yours.
>>>>
>>>
>>> Yes, and that's fine.  But drop the delusion that your unusual
>>> collection of personal opinions is the absolute truth of how programming
>>> languages should be.
>>>
>>
>> Here's a summary of what I've been talking about:
>>
>>                        C (eg)      Me
>>
>>   Case-sensitive       Yes         No
>>   0-based              Yes         No (both 1-based and N-based)
>>   Braces               Yes         No (keyword block delimiters)
>>   Library Read/Print   Yes         No (read/print *statements*)
>>   Char-based text i/o  Yes         No (line-oriented i/o)
>>   Millions of ";"      Yes         No (line-oriented source)
>>
>>
>> It's just struck me that all the languages corresponding to the
>> left-hand column are generally more rigid and inflexible**.
>>
>> The ones having attributes from the right are more forgiving, more
>> tolerant, and therefore more user-friendly. That would be a desirable
>> attribute of a scripting language.
>>
>
> Words like "flexible" are of questionable value - they mean different
> things to different people. To me, C (and other languages with similar
> attributes to those you list here - C is an example, nothing more) is
> more flexible. Being case-sensitive is more flexible than
> case-insensitive because it lets you choose capitalisation that conveys
> more information to the user.

You can use exactly the same capitalisaion, say of "AbcDef", in
case-insensitive syntax. But it's optional, so more flexible.

> Having 0-based arrays is more flexible
> than 1-based arrays because it is easier to work with more complex
> structures.

I'd dispute that, but I won't go into it, since I also do N-based which
/includes/ 0-based. More flexible.

> (Allowing a choice of starting values, and other indexing
> types, is much more flexible.)

Yeah...

> Use of statement terminators or
> separators (C has statement terminators, Pascal has statement
> separators) makes the language more flexible because your source code
> layout can match the structure of the code you want to express in the
> way you want to write it, rather than being forced into lines.

Actually the brace thing is not that much more flexible one way or
another. But my terminators do provide a choice, for example 'end', 'end
if', 'endif' or 'fi' can terminate an if-statement. 'end' can terminate
any block; the others must match the statement.

My users liked using 'End' and other camelcase:

Proc RuimOP =
For I = 1 To NidTot Do
DrawItem(NiewId[I],0)
DeleteItem(NiewId[I])
End
End

Their choice.

>
> Then there is the question of "tolerance" and "forgiving", and whether
> that makes a language "user friendly". Here I can accept that your
> language may be more "tolerant" and "forgiving", but that's based
> entirely on your judgement - nothing on the list here is, IMHO, a matter
> of "tolerance".

I'm tolerant of semicolons; I use them as separators, but 99% don't need
to be typed as they coincide with end-of-line.

And extra semicolons are harmless; in C they can have dramatic consequences.

If you're reading 3 numbers from ONE line of input using scanf, then
that line needs to have exactly 3 numbers, or it'll go wrong. My
line-based Read can tolerate fewer or more numbers on that line so much
better for interactive input.

If do 'print a,b,c', then change the types of those expressions, nothing
needs to change in that statement. I can also copy and paste that line
to print the local a,b,c expressions elsewhere. In C you have to rewrite
the format string.

>
>> Since I develop both a compiled and scripting language which have the
>> same syntax, it's natural they should share the same attributes.
>>
>
> I disagree. They might share some aspects, but you have different uses
> and different needs for a compiled language and a scripting language
> (otherwise, why have two languages at all?).

Why shouldn't they have the same syntax? Or near enough the same (one
will need more type annotations and so on).

This is fibonacci in one language:

function fib(int n)int=
if n<3 then
return 1
else
return fib(n-1)+fib(n-2)
fi
end

And in the other:

function fib(n)=
if n<3 then
return 1
else
return fib(n-1)+fib(n-2)
fi
end

(This demonstrates one reason why I like to have declarations out of the
way of the main code: the body of the function can be more easily ported
to the other language; it keeps the code clean.)

This is the driver code for a test program:

for i to 36 do
println i,fib(i)
od

which works in either language (except that the static language will go
beyond 36!).

(The static language needs it wrapped in a function; it will still
worked as dynamic, but there it is optional.)

On 29/11/2021 15:19, David Brown wrote:
> On 29/11/2021 14:06, Bart wrote:

>> This is just pure jealousy. Show me the C code needed to do the
>> equivalent of this (without knowing the types of a, b, c other than they
>> are numeric):
>>
>>    print "?"
>>    readln a, b, c
>>    println a, b, c

> You are under the delusion that there is one "correct" interpretation
> here. You think that /your/ ideas are the only "obvious" or "proper"
> way to handle things. In reality, there are dozens of questions that
> could be asked here, including:
>
> Does there have to be a delimiter between the inputs? Does it have to
> be comma, or space, or newline? Are these ignored if there are more
> than one? Are numbers treated differently in the input? Would an input
> of "true" be treated as a string or a boolean? Are there limits to the
> sizes?

This also comes up in command-line parameters to shell commands.

There you can also ask all your questions. The difference is that rather
than not make itemised parameters available at all (eg. as a single
string), it decides on sensible defaults.

But they are still not as sensible as what I use for Read. In Windows or
Linux, a command like:

prog a b c

returns those three args as 3 string parameters "a", "b", c". This:

prog a,b,c

returns one arg of "a,b,c". Here:

prog a, b, c

it results in 3 parameters "a," "b," "c" (notice the trailing commas).

prog "a b" c

gives 2 params "a b" and "c", without the quotes. So better than your
Python example. Here however:

prog *.c

Windows give one parameter "*.c", Linux gives *240* parameters. When I
try this:

prog *.c -option

Windows gives me "*.c" and "-option", but Linux now gives 241
parameters; information has been lost.

Anyway, imagine what a nuisance it would have been in C's main() was
defined like this:

int main(char* cmdline) {}

Just one string that you had to parse yourself.

When C decides to do something that is convenient, then that is great.
If I decide to do that, you have 101 reasons why it is a terrible idea.

NIH syndrome?

On 06/12/2021 19:58, Bart wrote:
> On 29/11/2021 15:19, David Brown wrote:
>> On 29/11/2021 14:06, Bart wrote:
>
>>> This is just pure jealousy. Show me the C code needed to do the
>>> equivalent of this (without knowing the types of a, b, c other than they
>>> are numeric):
>>>
>>>     print "?"
>>>     readln a, b, c
>>>     println a, b, c
>
>> You are under the delusion that there is one "correct" interpretation
>> here.  You think that /your/ ideas are the only "obvious" or "proper"
>> way to handle things.  In reality, there are dozens of questions that
>> could be asked here, including:
>>
>> Does there have to be a delimiter between the inputs?  Does it have to
>> be comma, or space, or newline?  Are these ignored if there are more
>> than one?  Are numbers treated differently in the input?  Would an input
>> of "true" be treated as a string or a boolean?  Are there limits to the
>> sizes?
>
>
> This also comes up in command-line parameters to shell commands.
>
> There you can also ask all your questions. The difference is that rather
> than not make itemised parameters available at all (eg. as a single
> string), it decides on sensible defaults.
>
> But they are still not as sensible as what I use for Read. In Windows or
> Linux, a command like:
>
>    prog a b c
>
> returns those three args as 3 string parameters "a", "b", c". This:
>
>    prog a,b,c
>
> returns one arg of "a,b,c". Here:
>
>    prog a, b, c
>
> it results in 3 parameters "a," "b," "c" (notice the trailing commas).
>
>    prog "a b" c
>
> gives 2 params "a b" and "c", without the quotes. So better than your
> Python example. Here however:
>
>    prog *.c
>
> Windows give one parameter "*.c", Linux gives *240* parameters. When I
> try this:
>
>    prog *.c -option
>
> Windows gives me "*.c" and "-option", but Linux now gives 241
> parameters; information has been lost.
>

Information has not been "lost". In the *nix world, there is a strong
tradition for avoiding duplication of work. The shell knows how to
expand wildcards, so it does that job - letting "prog" concentrate on
its own job. It makes it possible to keep things simpler and more
consistent (while retaining the flexibility to be overly complex and
inconsistent - I'm not saying everything in the *nix world is perfect).
In the Windows world, every program has to re-implement its own wheels
from scratch, every time.

If you want to pass "*.c" as an option in *nix, write :

prog \*.c -option

or

prog "*.c" -option

It's quite simple.

> Anyway, imagine what a nuisance it would have been in C's main() was
> defined like this:
>
>    int main(char* cmdline) {}
>
> Just one string that you had to parse yourself.
>
> When C decides to do something that is convenient, then that is great.
> If I decide to do that, you have 101 reasons why it is a terrible idea.
>
> NIH syndrome?

It is not "C" that decides this. It is the OS conventions that is in
charge of passing information to the start of the program, in
cooperation with the runtime startup code. It is no coincidence that
you get the same arguments in argv in C and in sys.argv in Python.

So the /shell/ is the bit that does the wildcard expansion. It is
normal for shells on *nix to expand wildcards, and normal for the more
minimal "command prompt" in DOS and Windows not to expand wildcards.
But you can have a shell in *nix that does not expand them, and a shell
in Windows that does.

It is the /OS/ and the the link-loader that splits command lines into
parts and passes them to the start of the program, regardless of the
language of the program.

Could this have been done differently? Sure. Could it have been done
better? Other ways might have had some advantages, and some
disadvantages - better in some ways, less good in others. Is this part
of the great conspiracy where everything in the computer world is made
because of C, is worse because of C, and designed that way with the sole
intention of annoying Bart? No.

On 2021-12-07 08:14, David Brown wrote:

> So the /shell/ is the bit that does the wildcard expansion.

That was a quite a problem back then. The damn thing ran out of memory
expanding *'s on i368 25Mz machines we used.

> Could this have been done differently? Sure.

In a well-designed system you would have a standard system library to
process the command line in a unified way. UNIX was a mixed bag trying
and failing to do both. In the end nobody respected any conventions and
UNIX utilities have totally unpredictable syntax of arguments.

[ Though I think UNIX missed an opportunity to make it even worse.
Consider if it not only expanded file lists but also opened the files
and passed the file descriptors to the process! ]

> Is this part
> of the great conspiracy where everything in the computer world is made
> because of C, is worse because of C, and designed that way with the sole
> intention of annoying Bart? No.

It is much bigger than Bart, the conspiracy, I mean... (:-))

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 07/12/2021 07:14, David Brown wrote:
> On 06/12/2021 19:58, Bart wrote:

>> NIH syndrome?
>
> It is not "C" that decides this. It is the OS conventions that is in
> charge of passing information to the start of the program, in
> cooperation with the runtime startup code. It is no coincidence that
> you get the same arguments in argv in C and in sys.argv in Python.
>
> So the /shell/ is the bit that does the wildcard expansion. It is
> normal for shells on *nix to expand wildcards, and normal for the more
> minimal "command prompt" in DOS and Windows not to expand wildcards.
> But you can have a shell in *nix that does not expand them, and a shell
> in Windows that does.
>
> It is the /OS/ and the the link-loader that splits command lines into
> parts and passes them to the start of the program, regardless of the
> language of the program.

That might be the case on Unix where where the OS and C are so
intertwined that that you don't know where one ends and the other begins.

On Windows, that doesn't happen automatically. If you see that behaviour
then it's due to the language runtime.

That 'int main(int argc, char** argv)' entry-point doesn't magically happen!

I need to call __getmainargs() in msvcrt.dll to get those arguments
expected of C programs. Before I knew about __getmainargs(), I used
GetCommandLine() from WinAPI to get the commands as one string, that I
had to parse myself.

> Could this have been done differently? Sure. Could it have been done
> better? Other ways might have had some advantages, and some
> disadvantages - better in some ways, less good in others. Is this part
> of the great conspiracy where everything in the computer world is made
> because of C, is worse because of C, and designed that way with the sole
> intention of annoying Bart? No.

I use a more sophisticated version of what happens with command-line
params (without turning the latter into a whole language like some
shells), and make it available via Readln on every line of console or
file input, not just the bit following the command invocation.

You said that is unworkable. C's argc/argv scheme shows that it can be.

On 07/12/2021 08:54, Dmitry A. Kazakov wrote:
> On 2021-12-07 08:14, David Brown wrote:
>
>> So the /shell/ is the bit that does the wildcard expansion.
>
> That was a quite a problem back then. The damn thing ran out of memory
> expanding *'s on i368 25Mz machines we used.

With big enough sets of files or command lines, /something/ is going to
run out of memory! Yes, sometimes command lines on *nix get too long,
and you have to use something like xargs. On the other side, because
DOS and Windows don't expand wildcards, the systems were made with much
shorter limits on the length of command lines which can lead to problems
with long filenames, lots of files (such as for linking), or lots of
flags. This is mostly a thing of the past, however, on both *nix and
Windows.

>
>> Could this have been done differently?  Sure.
>
> In a well-designed system you would have a standard system library to
> process the command line in a unified way. UNIX was a mixed bag trying
> and failing to do both. In the end nobody respected any conventions and
> UNIX utilities have totally unpredictable syntax of arguments.
>

It is far from being "totally unpredictable" - there are conventions
that are followed by most programs. But these are not enforced in any
way by *nix.

> [ Though I think UNIX missed an opportunity to make it even worse.
> Consider if it not only expanded file lists but also opened the files
> and passed the file descriptors to the process! ]
>

That would not make any sense - command line parameters are not
necessarily files!

>> Is this part
>> of the great conspiracy where everything in the computer world is made
>> because of C, is worse because of C, and designed that way with the sole
>> intention of annoying Bart?  No.
>
> It is much bigger than Bart, the conspiracy, I mean... (:-))
>

On 07/12/2021 10:22, Bart wrote:

> That might be the case on Unix where where the OS and C are so
> intertwined that that you don't know where one ends and the other begins.

No, /you/ don't know where one ends and the other begins - because you
have worked yourself into such an obsessive hatred of both that you
refuse to learn anything about either. Please don't judge others by
your own wilful ignorance - there are countless millions who manage to
program in C and work with *nix (the two being independent in practice).
There's nothing wrong with preferring other languages and/or other
OS's, but your struggles with C and your dislike of *nix are a personal
matter for you.

Please, find something new and interesting to post about rather than
your misconceptions, misunderstandings and FUD about languages and
systems that you don't like. It would be nice to get back to some
positive discussions.

On 07/12/2021 09:44, David Brown wrote:
> On 07/12/2021 08:54, Dmitry A. Kazakov wrote:
>> On 2021-12-07 08:14, David Brown wrote:
>>
>>> So the /shell/ is the bit that does the wildcard expansion.
>>
>> That was a quite a problem back then. The damn thing ran out of memory
>> expanding *'s on i368 25Mz machines we used.
>
> With big enough sets of files or command lines, /something/ is going to
> run out of memory!

But that needn't be the case! Suppose you had a million files in the
current directory, then input of "*" or "*.*" will try and create
1000000 strings; something is likely to break.

On Windows, it will just see one string. If the application actually
expected to work on multiple files, then with "*", it could iterate over
the files one by one, without needing to first create a list of them all.

>> [ Though I think UNIX missed an opportunity to make it even worse.
>> Consider if it not only expanded file lists but also opened the files
>> and passed the file descriptors to the process! ]
>>
>
> That would not make any sense - command line parameters are not
> necessarily files!

It doesn't make sense anyway: an input like "*" might means something
specific to an application, but the shell will turn it into an arbirary
list of strings, or into nothing.

Even if the app works with files, it can see that "* *" are two items
(perhaps two sets of files for different purposes), but on Linux, it
will turn it into one giant list, with duplicate files.

On 2021-12-07 10:44, David Brown wrote:
> On 07/12/2021 08:54, Dmitry A. Kazakov wrote:
>> On 2021-12-07 08:14, David Brown wrote:
>>
>>> So the /shell/ is the bit that does the wildcard expansion.
>>
>> That was a quite a problem back then. The damn thing ran out of memory
>> expanding *'s on i368 25Mz machines we used.
>
> With big enough sets of files or command lines, /something/ is going to
> run out of memory!

Normally you would just walk the list of files without expanding it in
the memory.

[ The secret lore lost to younger generations, that there is no need
load all document into the memory in order to read or edit it. (:-)) ]

>> In a well-designed system you would have a standard system library to
>> process the command line in a unified way. UNIX was a mixed bag trying
>> and failing to do both. In the end nobody respected any conventions and
>> UNIX utilities have totally unpredictable syntax of arguments.
>
> It is far from being "totally unpredictable" - there are conventions
> that are followed by most programs.

Like in the case of dd?

>> [ Though I think UNIX missed an opportunity to make it even worse.
>> Consider if it not only expanded file lists but also opened the files
>> and passed the file descriptors to the process! ]
>
> That would not make any sense - command line parameters are not
> necessarily files!

They are, unless introduced by a symbol of a key, e.g. /a, -a, --a etc,
so was the "convention." I never liked it, BTW.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 07/12/2021 09:57, David Brown wrote:
> On 07/12/2021 10:22, Bart wrote:
>
>> That might be the case on Unix where where the OS and C are so
>> intertwined that that you don't know where one ends and the other begins.
>
> No, /you/ don't know where one ends and the other begins - because you
> have worked yourself into such an obsessive hatred of both

Where's the hatred above? I'm still stating what I see.

that you
> refuse to learn anything about either. Please don't judge others by
> your own wilful ignorance - there are countless millions who manage to
> program in C and work with *nix (the two being independent in practice).
> There's nothing wrong with preferring other languages and/or other
> OS's, but your struggles with C and your dislike of *nix are a personal
> matter for you.
>
> Please, find something new and interesting to post about rather than
> your misconceptions, misunderstandings and FUD about languages and
> systems that you don't like. It would be nice to get back to some
> positive discussions.
>

You said this:

> It is the /OS/ and the the link-loader that splits command lines into
> parts and passes them to the start of the program, regardless of the
> language of the program.

That appears to be incorrect.

It might be happy coincidence that on Unix, at the entry point to a
program in any language, the parameter stack happens to contain suitable
values of argc and argv, just like you get with C's main(); what a bit
of luck!

But I haven't seen that in Windows (or any previous OSes I've used).

Can you point me to a link which says that Windows does exactly the
same, or please say you were mistaken.

/You/ seem to have an obsessive hatred of anything I say or do.

On 2021-12-07 11:33, Bart wrote:
> On 07/12/2021 09:57, David Brown wrote:

> You said this:
>
> > It is the /OS/ and the the link-loader that splits command lines into
> > parts and passes them to the start of the program, regardless of the
> > language of the program.
>
> That appears to be incorrect.

Nope, it is perfectly correct. If external command line parsing happens,
then it is ultimately the OS that pushes the results to the program. It
a part of the interface between C's run-time and the OS. Other languages
do more or less the same, e.g. see Ada RM A.15 The package Command_Line.

> It might be happy coincidence that on Unix, at the entry point to a
> program in any language, the parameter stack happens to contain suitable
> values of argc and argv, just like you get with C's main(); what a bit
> of luck!
>
> But I haven't seen that in Windows (or any previous OSes I've used).
>
> Can you point me to a link which says that Windows does exactly the
> same, or please say you were mistaken.

https://docs.microsoft.com/en-us/cpp/c-runtime-library/argc-argv-wargv?view=msvc-170

https://docs.microsoft.com/en-us/cpp/c-language/parsing-c-command-line-arguments?view=msvc-170

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 07/12/2021 10:56, Dmitry A. Kazakov wrote:
> On 2021-12-07 11:33, Bart wrote:
>> On 07/12/2021 09:57, David Brown wrote:
>
>> You said this:
>>
>>  > It is the /OS/ and the the link-loader that splits command lines into
>>  > parts and passes them to the start of the program, regardless of the
>>  > language of the program.
>>
>> That appears to be incorrect.
>
> Nope, it is perfectly correct. If external command line parsing happens,
> then it is ultimately the OS that pushes the results to the program.

On Windows it pushes nothing. Language start-up code needs to do the
work behinds the scenes so that user-programs can use entry-point
functions like:

main(argc, argv)
WinMain(Hinstance, etc)

> It
> a part of the interface between C's run-time and the OS.

Yes, it is part of the language. It is NOT the OS as David Brown stated.
It might be on Unix since Unix and C are so chummy.

> Other languages
> do more or less the same, e.g. see Ada RM A.15 The package Command_Line.
>
>> It might be happy coincidence that on Unix, at the entry point to a
>> program in any language, the parameter stack happens to contain
>> suitable values of argc and argv, just like you get with C's main();
>> what a bit of luck!
>>
>> But I haven't seen that in Windows (or any previous OSes I've used).
>>
>> Can you point me to a link which says that Windows does exactly the
>> same, or please say you were mistaken.
>
> https://docs.microsoft.com/en-us/cpp/c-runtime-library/argc-argv-wargv?view=msvc-170
>
>
> https://docs.microsoft.com/en-us/cpp/c-language/parsing-c-command-line-arguments?view=msvc-170

Those two links are specific to C implementations. So of course they
will set up the main's arguments for you! That's what I have to do too
in my C implementation:

#include <stdio.h>

int main (int n, char** a) {

for (int i=1; i<=n; ++i) {
printf("%d: %s\n",i,*a);
++a;
}
}

This generates the asm code below. The user's 'main' function is renamed
'.main'.

A new 'main' function is generated which calls __getmainargs. (There are
also __argc and __argv exported by msvcrt.dll, but I don't use those.)

Once obtained, it calls .main() with those new parameters. The program
thinks the OS put those on the stack; apparently so does everyone else!

Below this code, is the import list used by a version of this C program
compiled with tcc. Tcc also has a startup routine (bigger than mine),
which loads the arguments that become main's argc/argv. But notice it
imports __getmainargs too.

This routine is not the OS. The msvcrt.dll library is not the OS.

!x64 output for showargs.c
align 16
!------------------------------------
`main::
sub Dstack,160
lea D0,[Dstack+8]
push D0
sub Dstack,32
lea D0,[Dstack+196]
mov [Dstack],D0
lea D0,[Dstack+184]
mov [Dstack+8],D0
lea D0,[Dstack+176]
mov [Dstack+16],D0
mov A0,0
mov [Dstack+24],A0
mov D10,[Dstack]
mov D11,[Dstack+8]
mov D12,[Dstack+16]
mov D13,[Dstack+24]
call __getmainargs*
add Dstack,16
mov A0,[Dstack+180]
mov [Dstack],A0
mov D0,[Dstack+168]
mov [Dstack+8],D0
mov D10,[Dstack]
mov D11,[Dstack+8]
call .main
mov A10,A0
call exit*

..main::
push Dframe
mov Dframe, Dstack
sub Dstack, 16
mov [Dframe+16], D10
mov [Dframe+24], D11
! -------------------------------------------------
mov word32 [Dframe-8], 1
jmp L4
L5:
sub Dstack, 32
mov D0, [Dframe+24]
push word64 [D0]
mov D10, KK1
mov A11, [Dframe-8]
pop D12
call `printf*
add Dstack, 32
add word64 [Dframe+24], 8
L2:
inc word32 [Dframe-8]
L4:
mov A0, [Dframe-8]
cmp A0, [Dframe+16]
jle L5
L3:
L1:
! -------------------------------------------------
sub Dstack, 32
mov D10, 0
call exit*

!String Table
segment idata
align 8
KK1:db "%d: %s",10,0

Tcc imports:

Name: msvcrt.dll
Import Addr RVA: 2038
Import: 20d3 0 printf
Import: 20dc 0 __set_app_type
Import: 20ed 0 _controlfp
Import: 20fa 0 __argc
Import: 2103 0 __argv
Import: 210c 0 _environ
Import: 2117 0 __getmainargs
Import: 2127 0 exit

On 07/12/2021 07:14, David Brown wrote:

> So the /shell/ is the bit that does the wildcard expansion. It is
> normal for shells on *nix to expand wildcards, and normal for the more
> minimal "command prompt" in DOS and Windows not to expand wildcards.
> But you can have a shell in *nix that does not expand them, and a shell
> in Windows that does.

This is not quite right either.

If I take this line that I use to obtain the command params on Windows:

__getmainargs(&nargs, &args, &env,0, &startupinfo)

and change that 0 to 1, then I will get expanded wildcards too!

(And the first message I saw was: "Too many params"! I have a limit of
128 parameters, which seems more than adeqite for normal shell use, but
there were 160 matching files. Such expansion is just inappropropriate
at this point.)

Anyway, this bit is clearly not a shell.

Interesting the things you find out when you implement languages instead
of merely using them.

On 2021-12-07 12:22, Bart wrote:
> On 07/12/2021 10:56, Dmitry A. Kazakov wrote:
>> On 2021-12-07 11:33, Bart wrote:
>>> On 07/12/2021 09:57, David Brown wrote:
>>
>>> You said this:
>>>
>>>  > It is the /OS/ and the the link-loader that splits command lines into
>>>  > parts and passes them to the start of the program, regardless of the
>>>  > language of the program.
>>>
>>> That appears to be incorrect.
>>
>> Nope, it is perfectly correct. If external command line parsing
>> happens, then it is ultimately the OS that pushes the results to the
>> program.
>
> On Windows it pushes nothing. Language start-up code needs to do the
> work behinds the scenes so that user-programs can use entry-point
> functions like:
>
>     main(argc, argv)
>     WinMain(Hinstance, etc)

Yes and that was the point. This happens *before* main() is called.

> Yes, it is part of the language. It is NOT the OS as David Brown stated.
> It might be on Unix since Unix and C are so chummy.

It is specified by the language and fulfilled by the OS. Maybe, you
meant something like the context where parsing to happen:

Linux - The caller process
Windows - The callee process
xxx - The system kernel, maybe VxWorks would fall into this
category, I am not sure

?

This is kind of pointless distinction, especially because processes in
Linux and Windows are very different.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 07/12/2021 12:00, Dmitry A. Kazakov wrote:
> On 2021-12-07 12:22, Bart wrote:
>> On 07/12/2021 10:56, Dmitry A. Kazakov wrote:
>>> On 2021-12-07 11:33, Bart wrote:
>>>> On 07/12/2021 09:57, David Brown wrote:
>>>
>>>> You said this:
>>>>
>>>>  > It is the /OS/ and the the link-loader that splits command lines
>>>> into
>>>>  > parts and passes them to the start of the program, regardless of the
>>>>  > language of the program.
>>>>
>>>> That appears to be incorrect.
>>>
>>> Nope, it is perfectly correct. If external command line parsing
>>> happens, then it is ultimately the OS that pushes the results to the
>>> program.
>>
>> On Windows it pushes nothing. Language start-up code needs to do the
>> work behinds the scenes so that user-programs can use entry-point
>> functions like:
>>
>>      main(argc, argv)
>>      WinMain(Hinstance, etc)
>
> Yes and that was the point. This happens *before* main() is called.

But *after* execution commences at the program's official entry point,
by the language's startup code.

What it comes down is that, if you are implementing a language, these
argc/argv values don't magically appear on the stack, not on Windows.
The language must arrange for that to happen.

>> Yes, it is part of the language. It is NOT the OS as David Brown
>> stated. It might be on Unix since Unix and C are so chummy.
>
> It is specified by the language and fulfilled by the OS.

The only WinAPI function I know of that gives that info is
GetCommandLine, which delivers a single string you have to process.

If you know of a better WinAPI function on Windows, or of some exported
data from a Windows DLL that provides the same info, or perhaps of some
data block within the loaded PE image that contains it, then I will use
that instead.

> Maybe, you
> meant something like the context where parsing to happen:
>
>    Linux   - The caller process
>    Windows - The callee process
>    xxx     - The system kernel, maybe VxWorks would fall into this
> category, I am not sure
>
> ?
>
> This is kind of pointless distinction, especially because processes in
> Linux and Windows are very different.

Well, I was responding to this:

DB:
> It is the /OS/ and the the link-loader that splits command lines into
> parts and passes them to the start of the program, regardless of the
> language of the program.

The distinction was important since it is this very process that is
commonly done on Unix and/or C, which is equivalent to what I do with
Read on every line. Apparently it's OK when C (and/or Unix) does it on
the command line, but not OK when a language does it on any input line.

Correction: when /my/ language does it.

On 2021-12-07 14:57, Bart wrote:
> On 07/12/2021 12:00, Dmitry A. Kazakov wrote:
>> On 2021-12-07 12:22, Bart wrote:
>>> On 07/12/2021 10:56, Dmitry A. Kazakov wrote:
>>>> On 2021-12-07 11:33, Bart wrote:
>>>>> On 07/12/2021 09:57, David Brown wrote:
>>>>
>>>>> You said this:
>>>>>
>>>>>  > It is the /OS/ and the the link-loader that splits command lines
>>>>> into
>>>>>  > parts and passes them to the start of the program, regardless of
>>>>> the
>>>>>  > language of the program.
>>>>>
>>>>> That appears to be incorrect.
>>>>
>>>> Nope, it is perfectly correct. If external command line parsing
>>>> happens, then it is ultimately the OS that pushes the results to the
>>>> program.
>>>
>>> On Windows it pushes nothing. Language start-up code needs to do the
>>> work behinds the scenes so that user-programs can use entry-point
>>> functions like:
>>>
>>>      main(argc, argv)
>>>      WinMain(Hinstance, etc)
>>
>> Yes and that was the point. This happens *before* main() is called.
>
> But *after* execution commences at the program's official entry point,
> by the language's startup code.

The official entry point of a C console program is main().

> What it comes down is that, if you are implementing a language, these
> argc/argv values don't magically appear on the stack, not on Windows.
> The language must arrange for that to happen.

The linker, there is a switch to instruct the MS linker which CRT to
link to the executable. E.g. one can link one that skips command line
parsing altogether.

> The only WinAPI function I know of that gives that info is
> GetCommandLine, which delivers a single string you have to process.

> If you know of a better WinAPI function on Windows, or of some exported
> data from a Windows DLL that provides the same info, or perhaps of some
> data block within the loaded PE image that contains it, then I will use
> that instead.

CommandLineToArgv[A|W]

Why do you think it should be physically stored in the process address
space in the first place? It might be the case for a very primitive OS
UNIX was when it was developed. These days it could be anywhere. You
know there is GetCommandLineA and GetCommandLineW, which one is a fake?
Why do you even care?

>> Maybe, you meant something like the context where parsing to happen:
>>
>>     Linux   - The caller process
>>     Windows - The callee process
>>     xxx     - The system kernel, maybe VxWorks would fall into this
>> category, I am not sure
>>
>> ?
>>
>> This is kind of pointless distinction, especially because processes in
>> Linux and Windows are very different.
>
> Well, I was responding to this:
>
> DB:
> > It is the /OS/ and the the link-loader that splits command lines into
> > parts and passes them to the start of the program, regardless of the
> > language of the program.
>
> The distinction was important since it is this very process that is
> commonly done on Unix and/or C, which is equivalent to what I do with
> Read on every line. Apparently it's OK when C (and/or Unix) does it on
> the command line, but not OK when a language does it on any input line.

I have no idea what this is supposed to mean.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 07/12/2021 15:25, Dmitry A. Kazakov wrote:
> On 2021-12-07 14:57, Bart wrote:

>>> Yes and that was the point. This happens *before* main() is called.
>>
>> But *after* execution commences at the program's official entry point,
>> by the language's startup code.
>
> The official entry point of a C console program is main().

No. You don't quite understand how it works, that's fine.

But if your C program's entrypoint point is 'main', and the EXE's
entrypoint name is also 'main', then this code must be executed within
main(), by specially injected code.

Actually, with gcc, it changes the EXE's entry point to something else,
probably some injected code if it is not some function in the runtime.
It then eventually calls the user-code main(), with argc/argv as parameters.

In any case, fetching the command params is done after the application
has started running.

>> What it comes down is that, if you are implementing a language, these
>> argc/argv values don't magically appear on the stack, not on Windows.
>> The language must arrange for that to happen.
>
> The linker, there is a switch to instruct the MS linker which CRT to
> link to the executable. E.g. one can link one that skips command line
> parsing altogether.

I don't use a linker...

But if what you say is correct, then this is still code that is within
the application.

>> The only WinAPI function I know of that gives that info is
>> GetCommandLine, which delivers a single string you have to process.
>
>> If you know of a better WinAPI function on Windows, or of some
>> exported data from a Windows DLL that provides the same info, or
>> perhaps of some data block within the loaded PE image that contains
>> it, then I will use that instead.
>
> CommandLineToArgv[A|W]

This would be the next step /after/ calling GetCommandLine.

I might use this, but instead I will probably apply my own parsing since
the C-style processing is not quite up to scratch. For example it would
be nice to do:

readln @cmdline, a, b, c

when a, b, c are numbers, without all the usual palaver of checking argc
and applying atoi and the rest, or having to employ some library to do
that simple task.

> Why do you think it should be physically stored in the process address
> space in the first place? It might be the case for a very primitive OS
> UNIX was when it was developed. These days it could be anywhere. You
> know there is GetCommandLineA and GetCommandLineW, which one is a fake?
> Why do you even care?
>
>>> Maybe, you meant something like the context where parsing to happen:
>>>
>>>     Linux   - The caller process
>>>     Windows - The callee process
>>>     xxx     - The system kernel, maybe VxWorks would fall into this
>>> category, I am not sure
>>>
>>> ?
>>>
>>> This is kind of pointless distinction, especially because processes
>>> in Linux and Windows are very different.
>>
>> Well, I was responding to this:
>>
>> DB:
>>  > It is the /OS/ and the the link-loader that splits command lines into
>>  > parts and passes them to the start of the program, regardless of the
>>  > language of the program.
>>
>> The distinction was important since it is this very process that is
>> commonly done on Unix and/or C, which is equivalent to what I do with
>> Read on every line. Apparently it's OK when C (and/or Unix) does it on
>> the command line, but not OK when a language does it on any input line.
>
> I have no idea what this is supposed to mean.

This subthread is about the similarity between:

- Command line parsing (chopping one input line into separate args)
- My language's Readln which reads separate items from one input line

DB said the latter can't possibly work because of too many unknowns. Yet
it hasn't stopped shells using command line parameters.

On 2021-12-07 17:54, Bart wrote:

> In any case, fetching the command params is done after the application
> has started running.

No, the process /= application. There is a lot of things happening
between creation of a process and the application running on the context
of that process (or processes).

>>> What it comes down is that, if you are implementing a language, these
>>> argc/argv values don't magically appear on the stack, not on Windows.
>>> The language must arrange for that to happen.
>>
>> The linker, there is a switch to instruct the MS linker which CRT to
>> link to the executable. E.g. one can link one that skips command line
>> parsing altogether.
>
> I don't use a linker...
>
> But if what you say is correct, then this is still code that is within
> the application.

No, it is within the C run-time and furthermore nothing prevents an
implementation of the run-time to call to the system kernel and/or other
processes and services.

>>> The only WinAPI function I know of that gives that info is
>>> GetCommandLine, which delivers a single string you have to process.
>>
>>> If you know of a better WinAPI function on Windows, or of some
>>> exported data from a Windows DLL that provides the same info, or
>>> perhaps of some data block within the loaded PE image that contains
>>> it, then I will use that instead.
>>
>> CommandLineToArgv[A|W]
>
> This would be the next step /after/ calling GetCommandLine.

Calling GetCommandLine is no way obligatory and it tells nothing about
the implementation of. When a Windows process is created, the caller can
specify a command line parameter either as an ASCII or as an UTF-16
encoded string. What happens with that parameter, e.g. if it is
marshaled to process address space, converted, or whatever else is up to
Windows. You are making groundless assumptions about the implementation
of Windows API. You shall not, as it is a subject of change at any time
MS finds that appropriate.

> This subthread is about the similarity between:
>
>   - Command line parsing (chopping one input line into separate args)
>   - My language's Readln which reads separate items from one input line
>
> DB said the latter can't possibly work because of too many unknowns. Yet
> it hasn't stopped shells using command line parameters.

He is right.

1. If the OS does not impose a specific way of treating parameters,
there is no safe way to process arguments.

2. If the OS, as Linux does, requires parameters pre-parsed outside the
process, there are again limits to what could be done. E.g. in Linux
there is no reliable way to get the original command line it simply
might not exist.

In both cases there is absolutely no guarantee of any correspondence
between the "perceived" command line and what the process gets.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 07/12/2021 19:31, Dmitry A. Kazakov wrote:
> On 2021-12-07 17:54, Bart wrote:
>
>> In any case, fetching the command params is done after the application
>> has started running.
>
> No, the process /= application. There is a lot of things happening
> between creation of a process and the application running on the context
> of that process (or processes).

OK, it has to load the PE and do a bunch of fixups, but eventually it
will pass control to the entry point.

Then, where are the command line parameters to be found?

I can tell you they are not on the stack, which is where they must be if
C's main(argc, argv) is to work properly.

They have to be put there. Windows will not do that. The application's
language's startup code must do it.

That's the bit /I/ write.

>> DB said the latter can't possibly work because of too many unknowns.
>> Yet it hasn't stopped shells using command line parameters.
>
> He is right.
>
> 1. If the OS does not impose a specific way of treating parameters,
> there is no safe way to process arguments.

> 2. If the OS, as Linux does, requires parameters pre-parsed outside the
> process, there are again limits to what could be done. E.g. in Linux
> there is no reliable way to get the original command line it simply
> might not exist.
>
> In both cases there is absolutely no guarantee of any correspondence
> between the "perceived" command line and what the process gets.

The point is that C, somehow, ended up with a scheme where that one line
of commands WAS processed into convenient chunks for the application
work work.

Despite there being 'too many variables' to work; too many possible ways
that different programmers might want that command line parsed.

So, why can't a language also specify a set of defaults for proper
line-reading routines:

readln a, b, c

But I can see that I'm banging my head against a brick wall:

* No one here is ever going to admit that Bart's Readln statements
might actually be a good idea, despite C command-line processing
doing pretty much the same thing.

* And apparently no one is going to admit that that command-line
processing is not actually done automatically by Windows; it is up
to the startup code of a language implementation to get it sorted

On 2021-12-07 21:49, Bart wrote:
> On 07/12/2021 19:31, Dmitry A. Kazakov wrote:
>> On 2021-12-07 17:54, Bart wrote:
>>
>>> In any case, fetching the command params is done after the
>>> application has started running.
>>
>> No, the process /= application. There is a lot of things happening
>> between creation of a process and the application running on the
>> context of that process (or processes).
>
> OK, it has to load the PE and do a bunch of fixups, but eventually it
> will pass control to the entry point.
>
> Then, where are the command line parameters to be found?

> I can tell you they are not on the stack, which is where they must be
> if C's main(argc, argv) is to work properly.

If calling conventions are to use the stack, then both argc and
argv (a pointer) are on the stack, if not they are in the registers, why
should I care?

You are trying to make a point about some imaginary implementation. Even
if your musings were true that would not prove or disprove anything. The
API are as they are. The OS can send the command line to another end of
the universe and back using quantum entanglement. So?

> They have to be put there Windows will not do that. The
> application's language's startup code must do it.
>
> That's the bit /I/ write.

There was never objection to that. Prior to calling main() a lot of
things happens, and?

> The point is that C, somehow, ended up with a scheme where that one
> line of commands WAS processed into convenient chunks for the
> application work work.

Nope. You can call a program without having any commands at all:

1. Windows:

https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa

2. Linux:

https://www.man7.org/linux/man-pages/man3/posix_spawn.3.html

Again, these are interfaces to bring C's argc and argv into a desired
state, nothing more. There is no need to parse anything, just pass what
you want a be done with that.

> But I can see that I'm banging my head against a brick wall:

A quite unhealthy custom...

> * No one here is ever going to admit that Bart's Readln statements
> might actually be a good idea, despite C command-line processing
> doing pretty much the same thing.

It is not. The real problems with this stuff is lack of typing and its
low level nature. Consider passing another process as a parameter
accompained by access rights, an end of a stream, an event etc. These
produce an incredibly ugly code both under Windows and Linux.

> * And apparently no one is going to admit that that command-line
> processing is not actually done automatically by Windows; it is up to
> the startup code of a language implementation to get it sorted

It is done automatically by the CRT.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 07/12/2021 21:49, Bart wrote:
> So, why can't a language also specify a set of defaults for proper
> line-reading routines:
>
>    readln a, b, c
>
> But I can see that I'm banging my head against a brick wall:
>
>  * No one here is ever going to admit that Bart's Readln statements
>    might actually be a good idea, despite C command-line processing
>    doing pretty much the same thing.
>

You are not the only one who feels like he is banging his head against a
wall. You misinterpret everything though your paranoia.

Your "readln" could be a perfectly good solution - for /your/ language,
and /your/ needs. Something similar could be useful in wider contexts.

Where you are wrong, however, is in your believe that it is somehow
better than any other solution, or that it covers other peoples' needs,
or that it is somehow "fundamental" and something that should be part of
any language.

It doesn't cover typing, formatting, separators, syntax matching,
errors, or any of a dozen other possible requirements. If you don't
need any of that - you've just got a little script or a dedicated
program run in a specific way - then that's fine. People who need
something more, can't use it.

And no, just because you don't like C's input facilities does not mean
your methods are naturally superior.

And just because someone says your readln is too limited and simplistic,
does not mean they think C's alternatives are good or complete.

A low-level language needs basic, raw input facilities that you can use
to build the high-level input concepts that you need for your use. It
does not need high-level input facilities - those should be in libraries
so the user can choose what they need at the time (either from standard
libraries of common solutions, or roll their own specialist one).

A simple, limited high-level language can get away with saying "this is
what you get - take it or leave it". Much of the programming world left
such philosophies behind decades ago, but if you want to hang onto it
with your own language, that's up to you - that's an advantage of having
your own language.

On 08/12/2021 08:37, David Brown wrote:
> On 07/12/2021 21:49, Bart wrote:
>> So, why can't a language also specify a set of defaults for proper
>> line-reading routines:
>>
>>    readln a, b, c
>>
>> But I can see that I'm banging my head against a brick wall:
>>
>>  * No one here is ever going to admit that Bart's Readln statements
>>    might actually be a good idea, despite C command-line processing
>>    doing pretty much the same thing.
>>
>
> You are not the only one who feels like he is banging his head against a
> wall. You misinterpret everything though your paranoia.
>
> Your "readln" could be a perfectly good solution - for /your/ language,
> and /your/ needs. Something similar could be useful in wider contexts.
>
> Where you are wrong, however, is in your believe that it is somehow
> better than any other solution, or that it covers other peoples' needs,
> or that it is somehow "fundamental" and something that should be part of
> any language.
>
> It doesn't cover typing, formatting, separators, syntax matching,
> errors, or any of a dozen other possible requirements. If you don't
> need any of that - you've just got a little script or a dedicated
> program run in a specific way - then that's fine. People who need
> something more, can't use it.
>
> And no, just because you don't like C's input facilities does not mean
> your methods are naturally superior.
>
> And just because someone says your readln is too limited and simplistic,
> does not mean they think C's alternatives are good or complete.
>
> A low-level language needs basic, raw input facilities that you can use
> to build the high-level input concepts that you need for your use. It
> does not need high-level input facilities - those should be in libraries
> so the user can choose what they need at the time (either from standard
> libraries of common solutions, or roll their own specialist one).
>
> A simple, limited high-level language can get away with saying "this is
> what you get - take it or leave it". Much of the programming world left
> such philosophies behind decades ago, but if you want to hang onto it
> with your own language, that's up to you - that's an advantage of having
> your own language.

Having easy-to-use Read/Print statements doesn't mean more advanced or
more customised ways of doing i/o are off the table. (For a start, I can
call scanf/printf etc via the FFI of my language, if absolutely
necessary, but it rarely is.)

One important difference with mine is that they are line-oriented. C
input especially is character-oriented so it will see \n as white space,
and gives rise to all sorts of synchronisation issues when input
(interactive from keyword, or text files) /is/ strongly line-oriented.

This is an idea I had yesterday which I've now implemented:

proc start =
int a,b,c

readln @cmdline, a, b, c

println "Args:", a, b, c
println "Total:", a + b + c
end

If I invoke this program like this:

prog 10 20 30

it will read those as numbers and print their sum. (If they're not
numbers or just missing, it reads zeros.)

But look, I can do this too:

prog 10,20,30
prog 10, 20, 30

it still works! (Because it's using the same code as my Readln uses
elsewhere.)

Here's the C equivalent:

#include <stdio.h> // for printf
#include <stdlib.h> // for atoi

int main(int n, char** argv) {
int a = atoi(argv[1]);
int b = atoi(argv[2]);
int c = atoi(argv[3]);

printf("Args: %d %d %d\n", a, b, c);
printf("Total: %d\n", a + b + c);
}

If works with "10 20 30", and with "10, 20, 30". But with "10,20,30" or
"10" or no input, it crashes.

BTW for input of "10 20 30", n has the value 4, obviously!

One more trick: I decide to make a, b, c floats. In my code, I just
change "int" to "real", and it just works.

In the C, I need to change "int" to "double", all "atoi" to "strtod",
and all "%d" to "%f".

Is that it? Not quite: strtod needs a NULL second argument. Or maybe
'atof' could have been used?

Yeah, you can clearly see how C is superior here; you need that precise
control!

On 07/12/2021 10:14, Dmitry A. Kazakov wrote:
> On 2021-12-07 10:44, David Brown wrote:
>> On 07/12/2021 08:54, Dmitry A. Kazakov wrote:

....

>>> [ Though I think UNIX missed an opportunity to make it even worse.
>>> Consider if it not only expanded file lists but also opened the files
>>> and passed the file descriptors to the process! ]
>>
>> That would not make any sense - command line parameters are not
>> necessarily files!
>
> They are, unless introduced by a symbol of a key, e.g. /a, -a, --a etc,
> so was the "convention." I never liked it, BTW.
>

What convention would you prefer? I have tried to come up with something
better but without success.

BTW, words on a command line don't have to be file names.

--
James Harris

On 2021-12-13 18:42, James Harris wrote:
> On 07/12/2021 10:14, Dmitry A. Kazakov wrote:
>> On 2021-12-07 10:44, David Brown wrote:
>>> On 07/12/2021 08:54, Dmitry A. Kazakov wrote:
>
> ...
>
>>>> [ Though I think UNIX missed an opportunity to make it even worse.
>>>> Consider if it not only expanded file lists but also opened the files
>>>> and passed the file descriptors to the process! ]
>>>
>>> That would not make any sense - command line parameters are not
>>> necessarily files!
>>
>> They are, unless introduced by a symbol of a key, e.g. /a, -a, --a
>> etc, so was the "convention." I never liked it, BTW.
>>
>
> What convention would you prefer? I have tried to come up with something
> better but without success.

Same here. I prefer something that resembles a sentence, but it is
difficult to remember too.

> BTW, words on a command line don't have to be file names.

Yes, which is why expanding filename wildcards was a bad idea from the
start.

I think that there is no solution. A command line language is a problem
domain one. All problem domain languages are bad no matter how you
design them. It is a law of nature. So any command line language is
necessarily doomed.

An alternative existed since early days when OS came from the same
vendor. Many things were configurable per unified UI. That reduced need
in the command line languages. File managers helped to get rid on
command line file operations. IDE helped with compiler switches. Around
mid-90s all UIs switched to OO. You clicked the mouse on the object and
got the list of "virtual" functions applicable to the object. [This does
not work well with many objects, that pesky multiple dispatch is in the
way.]

Actually both Windows and Linux go this path deploying registry, XML,
SQLite DBs, UIs, managers etc to keep and modify parameters instead of
using commands. The success is sort of questionable.

P.S. The younger generation seems to be unaware of command line
interfaces. It was fun to watch Linus Tech Tips (LTT) Linux challenge
series on youtube. Two guys in 30s capable to install NAS servers and
tinkering hardware could not configure and use a Linux box fighting
through macabre Linux GUIs when a command line would do the work in 5
minutes.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de