Date: Wed, 9 Oct 2013 16:19:48 +0000 From: "Teske, Devin" <Devin.Teske@fisglobal.com> To: Warren Block <wblock@wonkity.com> Cc: "<freebsd-current@freebsd.org>" <freebsd-current@freebsd.org>, "Teske, Devin" <Devin.Teske@fisglobal.com>, Nathan Whitehorn <nwhitehorn@freebsd.org> Subject: Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI Message-ID: <13CA24D6AB415D428143D44749F57D720FC4AFC9@LTCFISWMSGMB21.FNFIS.com> In-Reply-To: <alpine.BSF.2.00.1310090914210.37118@wonkity.com> References: <52546844.2010608@freebsd.org> <5254774C.8030204@pix.net> <525478EA.8080207@freebsd.org> <13CA24D6AB415D428143D44749F57D720FC46904@LTCFISWMSGMB21.FNFIS.com> <alpine.BSF.2.00.1310090914210.37118@wonkity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13CA24D6AB415D428143D44749F57D720FC4AFC9>