From owner-freebsd-current@FreeBSD.ORG Wed Oct 9 16:19:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D031091B; Wed, 9 Oct 2013 16:19:51 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 99ACC22BB; Wed, 9 Oct 2013 16:19:51 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa04.fnfis.com (8.14.5/8.14.5) with ESMTP id r99GJnxX019638 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 9 Oct 2013 11:19:50 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.103]) by LTCFISWMSGHT05.FNFIS.com ([10.132.206.16]) with mapi id 14.02.0309.002; Wed, 9 Oct 2013 11:19:48 -0500 From: "Teske, Devin" To: Warren Block Subject: Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI Thread-Topic: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI Thread-Index: AQHOxHPFPJPIP8ZCyUiSsjBzr2++AA== Date: Wed, 9 Oct 2013 16:19:48 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D720FC4AFC9@LTCFISWMSGMB21.FNFIS.com> References: <52546844.2010608@freebsd.org> <5254774C.8030204@pix.net> <525478EA.8080207@freebsd.org> <13CA24D6AB415D428143D44749F57D720FC46904@LTCFISWMSGMB21.FNFIS.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.121] Content-Type: text/plain; charset="us-ascii" Content-ID: <2C435C588385274F8812895790825488@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-10-09_05:2013-10-09,2013-10-09,1970-01-01 signatures=0 Cc: "" , "Teske, Devin" , Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 16:19:52 -0000 On Oct 9, 2013, at 8:29 AM, Warren Block wrote: > On Tue, 8 Oct 2013, Teske, Devin wrote: >=20 >> "But shell is nasty; slow; and not as powerful as C" (it depends in what >> context; the first is rhetoric, the second is only true for poor impleme= nt- >> ations, and the third may be true in some contexts, but I consider the >> answer to "how maintainable is it" to be a factor in the "power" of a >> language, so don't necessarily consider C to be more powerful than >> shell as the latter is as-or-more maintainable with fewer LoC and a >> higher return on investment; see previous [above] arguments). >=20 > My question would be: why are sh and C the only choices? If the answer i= s "because that's all we have in base", is that a valid concern? >=20 > As far as sh, it lacks many high- or even mid-level constructs and has re= al problems with quoting, Enter helper functions... dteske@scribe9.vicor.com bsdconfig $ grep '^# f_' /usr/share/bsdconfig/stri= ngs.subr=20 # f_substr "$string" $start [ $length ] # f_snprintf $var_to_set $size $format ... # f_vsnprintf $var_to_set $size $format $format_args # f_longest_line_length # f_number_of_lines # f_isinteger $arg # f_uriencode [$text] # f_uridecode [$text] # f_replaceall $string $find $replace [$var_to_set] # f_str2varname $string [$var_to_set] # f_shell_escape $string [$var_to_set] # f_shell_unescape $string [$var_to_set] # f_expand_number $string [$var_to_set] The ones dealing specifically with quoting are f_shell_escape() and f_shell= _unescape(). With those two helper functions, I consider quoting in sh(1) to be complete= and maleable to handle all situations. > parsing, Surely, a strength. It can take a while to engrain or impart all the expans= ions and at- what stage (and in what context) they are performed, but when you understan= d the mechanics of (for example) in what order each element (escaped-sequences, p= arams, newlines, and sub-shells) is expanded... the parsing becomes an asset, not a hindrance (imho). Not to mention the flexibility afforded by "compound stri= ngs". Take for example, the following syntax (leveraging ordered expansion and co= mpound strings): f_dialog_input bar \ 'Enter *any* text; including globs [*] and shell special chars [$`#'"']..." f_dialog_input baz \ "Enter some *more* non-conforming text please..." f_shell_escape "$bar" bar f_shell_escape "$baz" baz items=3D"'$bar' '$baz'" show=3D"You entered:\n1=3D%s\n2=3D%s\n" eval printf \"\$show\" $items I'd be surprised if you could get anything out but the values you enter. > and output (2>&1 >&3, for example). I think it helps to highlight a technique for solving the general-purpose i= ssue of how you launch a program and have it talk to a parent's maintained file-des= criptor. In C, you'd have to pass special args to posix_spawn(3) to get this functio= nality. Talking about succinctness of syntax... that sequence is likely much shorte= r than any syntax I've ever seen in C for setting up file descriptors. I've interf= aced with dialog(1) from within C and getting the data back from it is non-trivial. ASIDE: You may be asking yourself... why on Earth would you fork-exec an instance of dialog(1) from within C instead of using dialog(3)? There are s= ome rare cases when this is advantageous. Usually when you want to support a dr= op- in replacement (like Xdialog(1)) for a long-running stateful widget (e.g. g= auge). Usually (>=3D99% of the time) a C program _should_ use dialog(3) but in tho= se rare cases ( see http://druidbsd.cvs.sf.net/viewvc/druidbsd/fdpv/ ) thank g= oodness I haven't had to mangle the file descriptors to get back any data (I call o= ut to gauge and just pump it massive amounts of data via stdin through a pipe passed to= the posix_spawn(3) call -- no data to read back. So I don't see the above syntax as anything to point out -- C programs have= more complicated setup for doing the same thing (they just have to do it less of= ten). Oh... and in bsdconfig, you'll notice I don't do that. Upon initialization = I clone the *real* terminal fd's _once_ and then use variables to reference the dup'd f= d. > These make it harder to do things (aka, more code to accomplish a task, m= ore code to be maintained, more difficult to modify) than the higher level = Perubython languages. >=20 Only because those languages have APIs that handle those things. Which I might add that those APIs have to be maintained. In that spirit, bsdconfig(8) provides the API for shell -- and similarly, said API (like mo= st APIs) will be need much less maintenance than the programs using said API (how often do we make changes to posix_spawn(3)? or how often does Perubython change an API call?). It's in that light that the bsdconfig(8) shell API is also treated just lik= e any other API with respect to changes (I treat all the "*.subr" includes as tho= ugh they are an ABI -- changes to function arguments must be well thought out). > In any case, thanks for working on this. A functioning program in any la= nguage is better than a non-existent "better" one. Indeed. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you.