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 C0CB4C433EF for ; Fri, 22 Oct 2021 08:07:09 +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 1B829604D2 for ; Fri, 22 Oct 2021 08:07:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1B829604D2 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=denx.de 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 706D9834C1; Fri, 22 Oct 2021 10:07:06 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1634890027; bh=B2MIn0bTwOzAAfpy2vwwhwxzYJmRT6J4keJdY8YKk5s=; h=To:cc:From:Subject:In-reply-to:References:Date:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=VtXpnblLZyWNM+kWn/C0gciqsiYkEKAxD0+kXTNLgSddafg6Z6WE/G732Pl9yXy/x /xbNElKgdTWUbx/3c114Snu2AzCDhjBbL2q2mKfbzYoIKo1qs4GGKeKxUbasBuUBim EzAAKmCeubnreQ4sIXf8tGaNqKfqTx5pxlC5VQ3Tk9h1ZkF+iOsmybBae1VrwU9WDH Ll/DW/p2Ct25zbcAmX02yhBp8tFvMqToyjeHv/6nuxnXLEcL4V9SVl80zvz333psxA 0BAUD8qRr5+osSuTApqzgED4/aOlk8m2NqnsFoTmcGhpqyA5wOC0M5F9yaaT53rST5 hbDXv7kEJQbFA== Received: from janitor.denx.de (unknown [62.91.23.180]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: noc@denx.de) by phobos.denx.de (Postfix) with ESMTPSA id 289D383311 for ; Fri, 22 Oct 2021 10:07:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1634890024; bh=B2MIn0bTwOzAAfpy2vwwhwxzYJmRT6J4keJdY8YKk5s=; h=To:cc:From:Subject:In-reply-to:References:Date:From; b=K9lbNOrLke2yL1/MH1tdW5ZQq5kfa7osEKazNH7jIZsMoyOZ4ZSXUo3FmtDi7Bwm7 ULJmSml7rIkhjrBOoz/VSki12+0wJU8pDTVIkOHLtRJplX6ZL3A1i2EHFvnXYiE+xx wvZwJ/ELEixYfed/3K360H/nOu4DfTz11KsQdXzmmRBKRKGIDsUITZWniYN/+rBfPq +XEhfDR2Y167JDG8uUwa8q1aKG7xg9f672zZkpdnyIxeTkFwmEIuvd3J6tdLHD5sPW WRIv9APQVBeBWJZmC4f4Pzz8CATjKnp+S+93qU0KeDQnex0yYQhocFR6RdxClpeNAl +X3q75qDMjypQ== Received: by janitor.denx.de (Postfix, from userid 108) id 87C91A0156; Fri, 22 Oct 2021 10:07:03 +0200 (CEST) Received: from gemini.denx.de (gemini.denx.de [10.4.0.2]) by janitor.denx.de (Postfix) with ESMTPS id 259E5A005A; Fri, 22 Oct 2021 10:06:56 +0200 (CEST) Received: from gemini.denx.de (localhost [IPv6:::1]) by gemini.denx.de (Postfix) with ESMTP id EF2681E0F1B; Fri, 22 Oct 2021 10:06:55 +0200 (CEST) To: Simon Glass cc: =?UTF-8?B?TWFyZWsgQmVow7pu?= , Tom Rini , U-Boot Mailing List , Rasmus Villemoes , Heinrich Schuchardt , Joe Hershberger From: Wolfgang Denk Subject: Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 8bit In-reply-to: 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> Comments: In-reply-to Simon Glass message dated "Thu, 21 Oct 2021 09:59:38 -0600." Date: Fri, 22 Oct 2021 10:06:55 +0200 Message-ID: <3763165.1634890015@gemini.denx.de> 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 Dear Simon, In message you wrote: > > > > i.e. > > > var+=value > > > appends value to var, while > > > var\+=value > > > 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. 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. > My distance second preference is what Marek has here, using a > backslash to escape the + character. Actually this has the same problem, as the backslash is also a legal character in a variable name: => setenv foo\\+ bar => printenv foo\\+ foo\+=bar 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?). The fact is, '=' and NUL are the only characters that cannot be used in a variable name. > As for =+ ...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. What do people expect? This is a totally new feature, so people will use what they find in the documentation and in example code. > Also, putting the > + after the = places (similarly unlikely) restrictions on the > expression. There is a fundamental difference here. For the '+=' case, there is no way to escape the '+', as all commonly used escapes are valid characters in the variable name, too. With '=+', the '=' 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. > 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 + But '\' is a legal character in the variable name, too. Anything but '=' and NUL is a legal char. And this makes escaping impossible: => setenv \'foo\\-\' foobar => printenv \'foo\\-\' 'foo\-'=foobar > > Also, I think that it would be better if spaces and tabs were allowed > > to indent the .env file, i.e. > > > > var_a = 3 > > var_bcd = 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). You mean this automatically insert a newline between parts? ugh... I didn't realize this. Did I miss it in the documentation? > We could update it to skip any leading space after the = I think. So what if you need a leading space? > I don't like spaces before the = though. It doesn't match the 'print' > output (which has no space) and it is confusing: env print also does not add any spaces after the '='. > I think we need strict rules so it is easy for people to get exactly > the env they want. Strict rules, proper documentation, and a set of examples. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Any time things appear to be going better, you have overlooked some- thing.