[COFF] Other OSes?

[Warner Losh]

I've often thought it a mistake to have main() be the only entry point.
There's a simple elegance in that, I'll grant, but if there were a
parse_args() entry point that also allowed for completion that was called
before main, and that you'd only proceed to main on a complete command
line, you could easily put the burdon of command line completion into the
programs. They know that arg3 is a filename or a sub command or a network
interface or an alternate name of cthulhu. tcsh does command completion,
but in a half-assed, gotta know about all the commands and have a giant
table that duplicates all the programs in the system's parsers, which isn't
scalable. It's had that since this 80's as has bash, and both have been
lame equally as long. It would also let the program do 'noise words' like
TOPS-20 did w/o having to actually parse them...

clang --complete is an interesting variation on my ideas within the realm
of doing non-standard weird things and starts to place the burden of
knowledge on the program itself, which is more in line with the thinking of
Unix and the main stream of OOish thought we've know about since the early
70s with smalltalk and other such pioneering things.

Then again, maybe my idea is too much influenced by TOPS-20 commands that
became resident to do command completion, then ran more quickly because
they were already at least half-loaded when the user hit return.

Warner

On Sun, Jul 8, 2018 at 9:43 PM, Grant Taylor via COFF <coff at minnie.tuhs.org>
wrote:

> On 07/08/2018 09:35 PM, Dan Cross wrote:
>
>> Back in the days of line editors, which read their commands from the
>> standard input and were relatively simple programs as far as their user
>> interface was concerned, you could put a set of editor commands into a file
>> and run it sort of like a shell script. This way, you could run the same
>> sequence of commands against (potentially) many files. Think something like:
>>
>
> ACK
>
> I figured that you were referring to something like that.  But I wanted to
> ask in case there was something else that I didn't know about but could
> benefit from knowing.  I.e. vimscript.
>
> $ cat >scr.ed
>> g/unix/s/unix/Unix/g
>> w
>> q
>> ^D
>> $ for f in *.ms; do ed $f << scr.ed; done; unset f
>> ...
>>
>
> Nice global command.  Run the substitution (globally on the line) on any
> line containing "unix".  I like it.  ;-)
>
> The double << is different than what I would expect.  I wonder if that's
> specific to the shell or appending to the input after the file?
>
> Back in the days of teletypes, line editors were of course the only things
>> we had. When we moved to glass TTYs with cursor addressing we got richer
>> user interfaces, but with those came more complex input handling (often
>> reading directly from the terminal in "raw" mode), which meant that
>> scripting the editor was harder, as you usually couldn't just redirect a
>> file into its stdin.
>>
>
> That makes sense.  Thank you for the explanation.
>
>
>
> --
> Grant. . . .
> unix || die
>
>
> _______________________________________________
> COFF mailing list
> COFF at minnie.tuhs.org
> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20180708/83c040d5/attachment.html>