On Mon, 21 Dec 2015, li...@wrant.com wrote: >> > Usability means then it should be not only humans but also programs >> > who are able to interact with the installer. So, since stream editors >> > know nothing about this seasons' (or Luddite's) line drawing symbols, >> > and users barely see the information between these on another terminal >> > capability controlled device, just and only: > > On Mon, 21 Dec 2015 00:16:02 +0100 Kamil Cholewiński <harry6...@gmail.com> >> >> A DSL. > > Get out of your ideas inception hat. If you did not witness it, the > books say UNIX command line domain specific language is called shell, > the one used in OpenBSD is ksh(1). The rest is history. There is > absolutely no way to add another on top of this one to make it a silly > dungeon quest instead of a 3 min installer susceptible to automation.
Pardon sir, I believe there is quite a lot of well-established prior art that disproves your point. Or perhaps someone is interested in patches to turn hostname.if(5), doas.conf(5), or pf.conf(5) into executable shell scripts. > susceptible to automation. Step 1. create a tool that requires user interaction Step 2. create a tool that automates the interaction When you type "ls" without an argument, does it start asking you questions? We'd soon need "autols" to automate feeding answers to "ls". Perhaps I'm a bit unclear about my POV, because I've both proposed a silly dungeon quest language, and argued against interactive scripts. Interactive scripts have their place, the installer is one. Building an interactive script to gather answers is a common pattern, that may be worthy of capturing and reusing. However with almost every interactive tool, soon someone shows up that just needs the "interactive" part to get out of their way. Now they must write more code to "defeat" the interactive code. Now which one is simpler? > a=`echo 1 | read answer && echo $answer` or: > a=1 Silly dungeon quest could do the broad equivalent of the latter form. You could tell it to read answers from a file instead of bugging the user, or having them write automation code. This is only possible in the general case if a DSL is used. You can't automate automating sh - you're now dealing with the halting problem. K.
