From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 24EC3C433EF for ; Fri, 22 Oct 2021 14:50:27 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 589E060F02 for ; Fri, 22 Oct 2021 14:50:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 589E060F02 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 31EE9834A9; Fri, 22 Oct 2021 16:50:24 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=konsulko.com header.i=@konsulko.com header.b="LWshte3p"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 13B5B834FB; Fri, 22 Oct 2021 16:50:21 +0200 (CEST) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 004D583458 for ; Fri, 22 Oct 2021 16:50:15 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qt1-x82a.google.com with SMTP id g17so3698519qtk.8 for ; Fri, 22 Oct 2021 07:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=OLlKUCa3k1EGjQ/ehSguRlsekTNd0+ElSpnOQAeA0P8=; b=LWshte3peDP37cODbVVI1+aYmk/scoDBooDUOyhekKWis5yLqGlkyYEXcbFBVbF/Tz Z1INLFmpc8bC4CkfIYLuKkZAP4+rUVxa1LxmtJ+E9seKJ6yuNebhqaraBEFY+mpIf1J8 2Hh5qjCztcgvnjHT5DqQgu7ker31RN0A4ZZF0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=OLlKUCa3k1EGjQ/ehSguRlsekTNd0+ElSpnOQAeA0P8=; b=FIi3Qit/idFqynHvn1DEU5m0dPT9zDLXT4n9SGMGVbi75rUFBhv2XBmfmFWrNv14N3 L3qAQy58ZinLLGX8ToB59diDPfmjTeAjD/m+vYiidNdAzyKSwVCDEo9+MK1VEwjDQPPn M52T/Z8Ka+4YABMC06NHJYnkElhcCpOwUNv9HBZ1By3GEA4rSIW9PxZF96Y0WB7af3MR WhHkz+VgytSGiQjFKZzBtv7FkOf2fEecwmCk3sihSHvpBkWjOPipw2XL/19ZUb3USgTE hawWmmIRiciVhG4Axjw2uX6v+Jyf7nOXkuGYIkMFjGa7+FGS3kpHPb9VmDX46uH6Z7FN ThCA== X-Gm-Message-State: AOAM531gjHFjR9pDWV9hOAd4wqUIpjY+XCLLySG48DcX2r94M8kqXPLc fFct6j9c5JzwmmrAITZrO1KtCw== X-Google-Smtp-Source: ABdhPJzd0lQZ8w6QVP1rQYzV4eiiQv874qwrAs29+toPlOQB9m7XPRrRwSxN0UO1TMfMZP9fox9aaA== X-Received: by 2002:a05:622a:2cd:: with SMTP id a13mr386042qtx.328.1634914214733; Fri, 22 Oct 2021 07:50:14 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-f084-0129-62d8-869d.res6.spectrum.com. [2603:6081:7b01:cbda:f084:129:62d8:869d]) by smtp.gmail.com with ESMTPSA id v3sm4206488qkd.20.2021.10.22.07.50.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Oct 2021 07:50:14 -0700 (PDT) Date: Fri, 22 Oct 2021 10:50:12 -0400 From: Tom Rini To: Wolfgang Denk Cc: Simon Glass , Marek =?iso-8859-1?Q?Beh=FAn?= , U-Boot Mailing List , Rasmus Villemoes , Heinrich Schuchardt , Joe Hershberger Subject: Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file Message-ID: <20211022145012.GH3577824@bill-the-cat> References: <20211019224422.1447059-1-sjg@chromium.org> <20211019164418.v9.3.Ie78bfbfca0d01d9cba501e127f446ec48e1f7afe@changeid> <3682215.1634809802@gemini.denx.de> <20211021122325.GX7964@bill-the-cat> <3695947.1634821611@gemini.denx.de> <20211021152537.441c37b9@thinkpad> <20211021152831.15524883@thinkpad> <3763165.1634890015@gemini.denx.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="a8sldprk+5E/pDEv" Content-Disposition: inline In-Reply-To: <3763165.1634890015@gemini.denx.de> X-Clacks-Overhead: GNU Terry Pratchett X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean --a8sldprk+5E/pDEv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 22, 2021 at 10:06:55AM +0200, Wolfgang Denk wrote: > Dear Simon, >=20 > In message you wrote: > > > > > > i.e. > > > > var+=3Dvalue > > > > appends value to var, while > > > > var\+=3Dvalue > > > > sets variable with name "var+" > > > > My first preference is to disallow + at the end of an end var. Perhaps > > we can start printing a warning if people do it, for a few releases. >=20 > This might seem to be a harmless change, but it is actually a > fundamental one. And it breaks backward compatiility. And all this > without need, as a list of alternatives have been suggested. >=20 > > My distance second preference is what Marek has here, using a > > backslash to escape the + character. >=20 > Actually this has the same problem, as the backslash is also a legal > character in a variable name: >=20 > =3D> setenv foo\\+ bar > =3D> printenv foo\\+ =20 > foo\+=3Dbar >=20 >=20 > Yes, it was probably not a good idea not to restrict the allowed > character set when I implemented this stuff 21 years ago, but then > code size was critical - we had U-Boot running from 128 kB EPROM > (you remember these huge chips which were erased under UV light?). >=20 > The fact is, '=3D' and NUL are the only characters that cannot be used > in a variable name. >=20 >=20 > > As for =3D+ ...while I can see how people might parse it (we are setting > > the var equal to what it has with an appending string) I think it is a > > terrible idea as it is just not what people expect. >=20 > What do people expect? This is a totally new feature, so people will > use what they find in the documentation and in example code. >=20 > > Also, putting the > > + after the =3D places (similarly unlikely) restrictions on the > > expression. >=20 > There is a fundamental difference here. >=20 > For the '+=3D' case, there is no way to escape the '+', as all > commonly used escapes are valid characters in the variable name, > too. >=20 > With '=3D+', the '=3D' defines where the variable name ends, and from > here you can define your own rules as where the value part begins - > this is just a matter how you implement your parser. >=20 > > The current format is basically the same as 'print'. So if I can't > > have the first preference, we could ensure that it prints a \ in the > > case that the var ends with + >=20 > But '\' is a legal character in the variable name, too. Anything but > '=3D' and NUL is a legal char. And this makes escaping impossible: >=20 > =3D> setenv \'foo\\-\' foobar > =3D> printenv \'foo\\-\' > 'foo\-'=3Dfoobar >=20 > > > Also, I think that it would be better if spaces and tabs were allowed > > > to indent the .env file, i.e. > > > > > > var_a =3D 3 > > > var_bcd =3D 7 > > > > > > should set "var_a" to "3", "var_bcd" to "7". > > > > > > If special character are needed in either name or value, they could be > > > escaped and/or quoted. > > > > They are allowed in the value but are reduced to a single space in the > > front. We need this for multi-line strings (but I'm a bit worried > > about it). >=20 > You mean this automatically insert a newline between parts? ugh... > I didn't realize this. Did I miss it in the documentation? >=20 > > We could update it to skip any leading space after the =3D I think. >=20 > So what if you need a leading space? >=20 >=20 > > I don't like spaces before the =3D though. It doesn't match the 'print' > > output (which has no space) and it is confusing: >=20 > env print also does not add any spaces after the '=3D'. >=20 > > I think we need strict rules so it is easy for people to get exactly > > the env they want. >=20 > Strict rules, proper documentation, and a set of examples. And sanity and restrictions introduced to our environment variables. The amount of "fun" things that were allowed by disallowing only NUL and =3D from names, and also allowing us to stay crazy tiny are just not relevant to where we are now. --=20 Tom --a8sldprk+5E/pDEv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmFyz6QACgkQFHw5/5Y0 tyznYAwAh2wgre5x39nchaPPXLmM/qeQq7lDdU3ZrKC0b6GSUUqCWGPmRBgFBMhj Sx5j01syg9KtBIj/2hcQ/BT/s7edamScpgHeT6rwfU3mzO+kn+xC2hY6WTyX1zic J8KABghZ/k73YLKnh8/6kNvJcEwvlw5nzNqY5BrFd7xwgeAAn48i9wSUCEkAPZ/S SVrjnVeMckFazgsg6lMlKQJvI/GlGdXXq1WQieQZagq3hydfmOh1tqLRu/jOPB9J 910rpG0XNZx9iSFfDDYdvKaSntfPTqeiR9v68vupMsOOPfWCySfhnQE8QxxzXYcr /3AvpgkZdtwUu/hpKYi1pfXZ8C2lycRFRpo02N4lQKNxUmmv8uXrhXbfLA/Qh4rD Pntk7WrZ/0tpemEyoyKhuaTmPtIbs0qsSCQUK82Ua4Xo+FV+ORM2QOnZTHvQ4Oqk uJEb3Sz/j3vWad4L41HwBDxULnoipccZ8chdCYzHtlKwsyQxL+vmN25gpfY6DSDn N1kG18+j =VPxv -----END PGP SIGNATURE----- --a8sldprk+5E/pDEv--