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@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@minnie.tuhs.org
https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff