9 Jul
2018
9 Jul
'18
9:52 a.m.
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(a)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(a)minnie.tuhs.org
https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff