From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1gdseH-0002a0-Pa for mharc-grub-devel@gnu.org; Mon, 31 Dec 2018 03:10:09 -0500 Received: from eggs.gnu.org ([208.118.235.92]:55486) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gdseF-0002Zs-LS for grub-devel@gnu.org; Mon, 31 Dec 2018 03:10:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gdseB-00016o-NV for grub-devel@gnu.org; Mon, 31 Dec 2018 03:10:07 -0500 Received: from ionic.de ([87.98.244.45]:42407 helo=mail.ionic.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gdse7-0000xh-Jj for grub-devel@gnu.org; Mon, 31 Dec 2018 03:10:01 -0500 Received: from [10.20.44.11] (178.162.222.163.adsl.inet-telecom.org [178.162.222.163]) by mail.ionic.de (Postfix) with ESMTPSA id 7E87D4F0007E; Mon, 31 Dec 2018 08:09:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ionic.de; s=default; t=1546243793; bh=M4cpVxWaEpbIi8RZGtsaCDAfsni5B3D+jwUIhSonTto=; h=To:References:From:Subject:Date:In-Reply-To:From; b=bqJ24gVEw8LxpYQLaaIKkO2NSJt5opNBp03MmYntZIoU9X+mO2phn/v0VNCLyJf3Z dNIwC5lFSygGGBHZDE/VvR/bLxHJb9lD1ejB2+g/aWK1kDWPmYd4+lP+uYJ3Jkmgiv 7iFqjalYyetg2vDGI3xgszZ9GZNveh1qUXagT41c= To: The development of GNU GRUB , Jeff Norden References: From: Mihai Moldovan Openpgp: preference=signencrypt Autocrypt: addr=ionic@ionic.de; prefer-encrypt=mutual; keydata= xsFNBEjok5sBEADlDP0MwtucH6BJN2pUuvLLuRgVo2rBG2TsE/Ijht8/C4QZ6v91pXEs02m0 y/q3L/FzDSdcKddY6mWqplOiCAbT6F83e08ioF5+AqBs9PsI5XwohW9DPjtRApYlUiQgofe9 0t9F/77hPTafypycks9buJHvWKRy7NZ+ZtYv3bQMPFXVmDG7FXJqI65uZh2jH9jeJ+YyGnBX j82XHHtiRoR7+2XVnDZiFNYPhFVBEML7X0IGICMbtWUd/jECMJ6g8V7KMyi321GP3ijC9ygh 3SeT+Z+mJNkMmq2ii6Q2OkE12gelw1p0wzf7XF4Pl014pDp/j+A99/VLGyJK52VoNc8OMO5o gZE0DldJzzEmf+xX7fopNVE3NYtldJWG6QV+tZr3DN5KcHIOQ7JRAFlYuROywQAFrQb7TG0M S/iVEngg2DssRQ0sq9HkHahxCFyelBYKGAaljBJ4A4T8DcP2DoPVG5cm9qe4jKlJMmM1JtZz jNlEH4qp6ZzdpYT/FSWQWg57S6ISDryf6Cn+YAg14VWm0saE8NkJXTaOZjA+7qI/uOLLTUaa aGjSEsXFE7po6KDjx+BkyOrp3i/LBWcyClfY/OUvpyKT5+mDE5H0x074MTBcH9p7Zdy8DatA Jryb0vt2YeEe3vE4e1+M0kn8QfDlB9/VAAOmUKUvGTdvVlRNdwARAQABzR9NaWhhaSBNb2xk b3ZhbiA8aW9uaWNAaW9uaWMuZGU+wsGfBBMBCABJAhsjAh4BAheAAhkBCwsKDQkMCAsHAQMC BxUKCQgLAwIFFgIDAQAWIQRuEdCPdTOBx0TxyDwf1i7ZbiU6hwUCW5Cf6AUJFKOdzQAKCRAf 1i7ZbiU6h/kZD/kBqwtaw0VCognCgk3VlNYr4bOpKf6HTyAonnlUsOs9w+Y4yptFO8pDO8PO j2k2Q5FEv1rsKHkThvJtEFOYEqqVhgR4nnvxhIAOel8gs801q0Ez0coqS+kmU50tSRz//Ft4 i+Eqyi1kocB64/hHTKEvYAYQWV9Y8jmHPx5lfPz2nWXPIRLiUylCJrnpgq/Ld2j+BRSOH7AD URodTGdeovZOnkpDzpt5l5/Xowe0Momfm4io6hLR282vHJ8v2E8NW7VvAT4UqQkrkpG+fBnt fOjz/o1lNNg1EMRUavdq0+HhLpJR/kmt2oi4andJz4fi4WuHX38RjyJhB7q7XuCm2Tcg7rbh ns75dh10jCqJR6RUlLeFgYiSd22+h3J6vG4Epo0ciE7tSklBLWzvj9DOolMS19Qfq9Wt3SqN EA6rNg32ODw+qCtC3+VOam1+Kogj8BoxHj3I7TzKlGlEtQDujZ3ZCCLeUldZojdzhR4Pw+2s dV0nT6g0eJtlwY1XNmM89ZGk76B3wo3KldwZsvTqS5yoD5NJkAiHZPjKNRkKMbtU/+w6XRdm L4sY/JC/2OZmz36QL2g+8qdQTxMLQE5n27ugdkzlEMrIlzjSa+vrQfn2L1qV1bZ+U6BbJaoj dqvnOBLyyF6HTWFySsN9Mezb0Ywh4a6++szqoLzFmtm3k+NhlM7BTQRI6JObARAA8Prkme+B PwRqallmmNUuWC8Yt+J6XjYAH+Uf0k/H6MLA7Z+ZL8AHQ+0N306r/YFVnw2SjhaDODwhRoMv dOKtoIcJZ9L0LQAtizhZMbHCb+CMtcezGZXamXXpk10TzrbI9gnROz1xBnTkzpuOkgo43HRx 7GuYy+imM4Lxh/hfgRM6MFjQlcIsUd0UGRCxuq8QmxRqQpRougCwPeXjfOeMRkaQUI7A8kLJ 7bTmSzjB9fSBv63b7bajhFHid1COYGe3EZOYRi1RTzblTnq2Fdv+BN/ve/9BdZgApfRSX8Qk uLsuZF9OWHxIs3wwpvqFoyBXR29CqgrcQFFA/Lm3i/de3kFuXJUVFTYM4tLwV85J9yGtK6nU sA/v6LXcaTGrQ9P3rJ3iVPYKuyF2w8IMqvFTnHu6+nCvBJxLymOsYJFN4W/5TYdWk1hdIYmm NlM/PH+RWL8z+1WWZgZOBPFJ0FQQbDvTMP6m0/GZT1ZFUVoBG/FAiIQ9UDl8gRsGfe0wS6gz k2evXeAZQyZCii3Dni7Di2KjaPpnl/1F7Zelueb7VbgdoPRmND9rFixI6bFC4yjlSnL5iwIi ULDkLDJN5lcRHI5FO/6bzwVSgHmI+eMlNA/hysdTtp9AjE7VkVxeC9TJ+kEZDv5VUTSxUpNs Wj922PkX+78EYPPGTOG4xx7PMqcAEQEAAcLBfAQYAQgAJgIbDBYhBG4R0I91M4HHRPHIPB/W LtluJTqHBQJbkKA7BQkUo54gAAoJEB/WLtluJTqH5xAP/3Bn3T2iCafYN4QP4Q/Z9l6BUNkX t59HorInEZ5mT8kQZvX9w1I4cfY69WZC7Bpw1BigN7uiogaV/wFgS8TUGHVbRkyU+1jD7CZf BUmCmCENdAkfDUSMf4fQEu5+7P6iGL6hkMZtpz4NqwNdkLqPwc7n+Ep009CenIDADn7woQT7 W6xvTMLd5BR+hbbiiJ6v22gQoBq1a7tD4RhX8EJ7cSTb/2Ln8qmV60vB/qnf+dqI7/7Tg2vq nlt4iIwH/hGoC8IQ8MZ2AMEJWfxoLHUrr82yDl3Kcmw4ANEG794Uash7+6m8GJB0hv8pThFN z2sm5yqpOOtTZvuZ85Qz/Z8k/c8MvcaR8Ja8ykdq/WgVD0jONhZAQBnToNkWSJZalouyN+FN vW2V9VtusyKPR8FFVg0Dc3+JRLFpylqhCYxSbs7dDs4GoRH7exIQnY8ErMlMRw0oYuAE9Z3S Lh+ZCc0vIcLCQDGeJA5na2RfHzdPgvWQuqOuMbt/zd4KmXRvw/fygtuDpteJi18YXCL1eb9v QIHMR/YOeLDTJDC9adA4g7nI+6dDuvM4UU89vnjw4yIbq9DhOJeXxSE9fu6W3C63htfYf/kN G5L38cOQ+xFc7ya9Q77ThrdBR8vZhqlhuDYQA0IC5NYvJhYH9xL/BLgbhBZ1+yPDDkPTRgTj 6s/RcD55 Subject: Re: Proposed PATCH to allow control of the kernel ordering in grub.cfg Message-ID: Date: Mon, 31 Dec 2018 09:09:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qjmnM5o0PsDUhURjZJt4us9j6O4mhYnOd" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 87.98.244.45 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2018 08:10:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qjmnM5o0PsDUhURjZJt4us9j6O4mhYnOd Content-Type: multipart/mixed; boundary="VRD3wblUkWDkCyIYYDRY8rSm1BAd5ITYP"; protected-headers="v1" From: Mihai Moldovan To: The development of GNU GRUB , Jeff Norden Message-ID: Subject: Re: Proposed PATCH to allow control of the kernel ordering in grub.cfg References: In-Reply-To: --VRD3wblUkWDkCyIYYDRY8rSm1BAd5ITYP Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable * On 12/27/18 3:23 PM, Jeff Norden wrote: > Nothing is ever as simple as it seems, is it? Never is. > 1) Deleting the tr after the grep actually seems to break the patch. M= y > apologies for not testing this more carefully in advance. It looks lik= e > the second tr masks grep's exit status, which is important b/c the > script runs with 'set -e' and exits immediately on any "error". Careful, that's not universally true. Some shells error out, others don't= =2E POSIX/SUS (at least in its current iteration) specifies that "any command= " with a few exceptions (a few reserved words, any but the last command in pipes= , any but the last command in an AND-OR list and some other exception I wasn't = able to understand even after thinking about it for half an hour) shall make the = shell fail. However, bash for instance didn't care for stuff that happens in su= bshells (which backticks or the better $() notation create) before version 4, so = it seems that older versions would NOT error out if anything within a subshe= ll failed. Newer ones do, but there are even more caveats. Consider [1] (set -e; printf '%s\n' 'blargh' | grep -E 'foo'; printf '%s\n' 'bar')= ; printf '%s\n' "${?}" which should print "1\n", but [2] (set -e; ret=3D"$(printf '%s\n' 'blargh' | grep -E 'foo'; printf '%s\= n' 'bar')"; printf '%s\n' "${ret}"); printf '%s\n' "${?}" which prints "bar\n0\n" in my bash version and then again [3] (set -e; ret=3D"$(set -e; printf '%s\n' 'blargh' | grep -E 'foo'; pri= ntf '%s\n' 'bar')"; printf '%s\n' "${ret}"); printf '%s\n' "${?}" which prints "1\n" again. In older bash versions, any error within the subshell would have been ign= ored (contrary to POSIX requirements), so in my understanding [2] and [3] woul= d have printed the same "bar\n0\n" string there. The errexit shell feature can be and often is a venomous snake pit. > Seems like changing |tr to ||true will work. Yeah, the usual workaround for that is either "cmdthatmightfail || true" = or "cmdthatmightfail || :" > 2) After reading Mihai Moldovan's comments above, I think it is better > to just use grep rather than egrep. You could always add "-E" at the > beginning of the GRUB_PREFERRED_KERNEL string if you need to. With GNU= > grep, egrep and grep have the same functionality, and only differ in > when you need to backslash-escape some of the special characters. No, don't even start with that. Either use egrep "${GRUB_PREFERRED_KERNEL}" or grep -E "${GRUB_PREFERRED_KERNEL}" Why? ionic@apgunner ~/ $ input=3D"-E 4.20"; grep "${input}" '/dev/null' grep: invalid option -- ' ' Usage: grep [OPTION]... PATTERN [FILE]... Try 'grep --help' for more information. In such a scenario, because the input string is quoted, it will be passed= as one single argument to the grep utility, which then tries to parse the full s= tring as one huge option. Take into consideration that short options can be usu= ally concatenated together, so grep's option parsing tries to adhere to this a= s soon as it saw the short option starting sequence "-". Funnily enough, a short= option such as "- " might just be valid. It just turns out that grep doesn't sup= port it. A remedy to this could be to prefix any user-provided input with the options-terminating pseudo-option "--" (often called delimiter). input=3D"-E 4.20"; grep -- "${input}" /dev/null would work "correctly" (if you really *intended* to search for a string s= uch as "-E 4.20" or "-E 4,20" or "-E 4a20" or ...), but also not treat anything = that might resemble an option in the user string as a real option, which usual= ly is the right thing to do. Input sanitization or lack thereof is a huge probl= em. You generally do not want users to pass random options to commands, for the r= easons you have outlined yourself in point 3. The problem is just that command line parsing is difficult and while "--"= is an accepted delimiter for getopt() and friends, there are utilities that don= 't even use getopt(), but instead roll their custom solution that happens to not = support that. Another common exception to this is bash's "echo" builtin which exp= licitly does not handle "--" as a delimiter. Also, people are lazy and don't like= to clutter every command invocation with a delimiter after specifying wanted= options and even when they actually try to, it's oh-so-easy to forget. To my mind, grep -E -- "${GRUB_PREFERRED_KERNEL}" sounds like the best so= lution. You obviously already took into account that dots in regular expressions = match arbitrary characters and outlined that, including consequences, in the documentation; good work on that! Originally, I was just trying to point out that I'd prefer to use "grep -= E" nowadays compared to "egrep" - seems like we went off the rail pretty qui= ckly. :) Mihai --VRD3wblUkWDkCyIYYDRY8rSm1BAd5ITYP-- --qjmnM5o0PsDUhURjZJt4us9j6O4mhYnOd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCgAdFiEEbhHQj3UzgcdE8cg8H9Yu2W4lOocFAlwpzs0ACgkQH9Yu2W4l Ood9nA//T3x21GbsOxPblqgPozlQ0t0k7/wRKGsV/ghdAJYxjWwehUs0IYCE+NIL eGF4bk92OjgQFLJyZT1xBPKOhjCPts2OHIMu+E8/Ven6DPZEYET6cR3F/zmSkIMs 32MqskWvrvesna5IQkR9/dezwY6WbKUf5cTTpSuKMTj/5zrVLOJeitOcE2RxUvWK M/Nj2aA8EqEdVHcCcoN0FO9FA5OA1qZrvbhvKfADI8OeJiDNgtMrjCtYHoVqQ7Uh XzFnxffDQIqSfXkKwqlCHwKawXYCW23Proc86nW3/Cz6qe25NObPNTXgkzM6KSY9 S4o60yMeoHGC0O6fJTCBaKwPgr1qNEGpAp735r8GfFrrplKjAmDvT55c8SNAm/pf 7J+VFb5zID6nZXPTPZAX+jICYuYSt1sxE7OFx5MI7f5F5laFvacJi1+UCsw8Dzgc O6YBQS/Wp56ZEUgAeuRgtFF3qJJfJOQzaL/ACrB4vNbGt+wGU97SOPHFHXdSDvZv SL++pbJCWp+7Vec6ksyD3uw1Ywx64RFBXRHCjckRAeQn+OdHNkBrpdqjaPL9MdWF a1j5QLDhUGT+Nv5OGcTbeW/eP4bNesmD4EVt9iGONKnfPXxIBcpRZpYAkNyiza/h VLHpoAgvgbXaACclY7aa+6//NKm07aC392p4FF1pu8NtkqxlfGo= =lZoH -----END PGP SIGNATURE----- --qjmnM5o0PsDUhURjZJt4us9j6O4mhYnOd--