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 X-Spam-Level: X-Spam-Status: No, score=-6.0 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B98E3C07E96 for ; Thu, 8 Jul 2021 16:13:33 +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 665296139A for ; Thu, 8 Jul 2021 16:13:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 665296139A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 2E4E5831A6; Thu, 8 Jul 2021 18:13:30 +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=1625760810; bh=PgrmyEgtE2Nuu07QS2enYGhWoWB/dZ+ZRHONpKdsXe4=; h=To:cc:From:Subject:In-reply-to:References:Date:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=zqLq9C+IWfUikoJAiKREIIrgMmvzCqxVLVeGu1AQOJzykRnTwZW13BjusfjeaKmZZ TGIB6YptptSX3Pen7K4QJo71jdxnkGAJxXKTjazYWUNKfrjsXmCFL5gxUgYC4Nn+T+ 73yD2ek9lnzmrdblzbygserDNjuMOuA9F3fbDE7dKCx1RdCINkUvKq7akeXMacwBi1 Vj878Yd/ptBxwe16gSpI3saXk0WlFDBiqX4DgLyc1FNoRbytXU/UPYdOfRG3YU4Kbo BuAi8U3AWeFouq3DFVsFwwh77sYkyhWkxp+o9ogmwsKbgV47mvx7y/wZt49l5l3xC1 TZChE0H08NOuA== 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 C8F63831A5 for ; Thu, 8 Jul 2021 18:13:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1625760808; bh=PgrmyEgtE2Nuu07QS2enYGhWoWB/dZ+ZRHONpKdsXe4=; h=To:cc:From:Subject:In-reply-to:References:Date:From; b=oapdKGFFfuVQkLs21gYNn0QGmOd8KPyVE4LM/MG8mziBvtdgxgkyfBKsmlo9o3WAc dEohii1TqeZh5a7GojEjDNEb+7WkGTASyvZJYn9VVDaFHcwXlNb68AevBfKsD0Cv52 tNNqBL0Jp+kHJ5pN4fVk1S7BuqQcql69nTAYNO4yOYTEXGEMy1kM2L+tEwQvTH8Yj4 Z+BW86RSdzjeCjhgaCozB10TEfW4Q2nJDNlBDDRMtTz/G/PtSkVYojSkBv9scmtBb1 /NvJ4vT96txmyFn8ifNz6wGoDIZupln3n2Cp7Ih8qyMmAcKrI9B02cX392Dp59Xpno fwDvv00vpXlzQ== Received: by janitor.denx.de (Postfix, from userid 108) id 66398A020C; Thu, 8 Jul 2021 18:13:28 +0200 (CEST) Received: from gemini.denx.de (gemini.denx.de [10.4.0.2]) by janitor.denx.de (Postfix) with ESMTPS id 22C37A0122; Thu, 8 Jul 2021 18:13:20 +0200 (CEST) Received: from gemini.denx.de (localhost [IPv6:::1]) by gemini.denx.de (Postfix) with ESMTP id CAA831E14C2; Thu, 8 Jul 2021 18:13:19 +0200 (CEST) To: Sean Anderson cc: Steve Bennett , Rasmus Villemoes , u-boot@lists.denx.de, Tom Rini , =?UTF-8?Q?Marek_Beh=c3=ban?= , Simon Glass , Roland Gaudig , Heinrich Schuchardt , Kostas Michalopoulos From: Wolfgang Denk Subject: Re: [RFC PATCH 03/28] cli: lil: Replace strclone with strdup MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 8bit In-reply-to: <4aa7ff19-b774-0d67-b96a-9c0c9290a708@gmail.com> References: <20210701061611.957918-1-seanga2@gmail.com> <20210701061611.957918-4-seanga2@gmail.com> <17176.1625340369@gemini.denx.de> <54A6EFA6-8D5B-4779-B344-87BCC8C14B9C@workware.net.au> <5a967151-94f0-6037-2d02-0114c43b846c@gmail.com> <163090.1625507434@gemini.denx.de> <4aa7ff19-b774-0d67-b96a-9c0c9290a708@gmail.com> Comments: In-reply-to Sean Anderson message dated "Thu, 08 Jul 2021 00:37:52 -0400." Date: Thu, 08 Jul 2021 18:13:19 +0200 Message-ID: <132363.1625760799@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 Sean, In message <4aa7ff19-b774-0d67-b96a-9c0c9290a708@gmail.com> you wrote: > > Without pipes, how do bourne-style shells communicate? Sure you can > transfer data into functions using arguments, but what about the other > way around? Numeric return values? Global variables? I think these are > rather anemic compared to proper return values. Pipes are basically just a shortcut to avoid buffer space and to make scripting easier and more elegant. For example: $ ps aux | grep foo | grep -v grep | awk '{print $2}' | xargs kill can be written without use of pipes as: $ ps aux >/tmp/$$.1 ; \ grep foo /tmp/$$.2 ; \ grep -v grep /tmp/$$.1 ; \ awk '{print $2}' /tmp/$$.2 ; \ xargs kill The point here is that many Hush features were written with fork. For > example, to create a new scope (such as for a subshell), Hush just > fork()s. When parsing, if it encounters a construct like $(), it fork()s Yes, of course I am fully aware of this. This is one of the reasons why command substitution was excluded from the inital port of hush to U-Boot - but again: command sustitution is just a shortcut; it is simple enough to write scripts without it, and it is certainly possible to implent this feature in a U-Boot context as well. The reason it was not done 18 years ago is 1) typical systems at that time did not have the resources (especially not enough ROM for a bigger U-Boot image), and 2) having a shell with basic scripting capabilities was sheer extravagance in a boot loader. Yes, the situation has changed since then; today a U-Boot image is as big as a v2.2 Linux kernel image was then, and nobody cares. > and then modifies the map variable, (correctly) assuming that the > "original" map will remain unmodified. These things are all over and > make doing a port difficult; especially when they crop up as unforseen > bugs. Though I suppose the real issue here is a lack of virtual memory. Not really. At the time of the port the concern was about code size (size of the text segment). > IMO "everything is a file" is more of an API thing than a shell thing. > E.g. the idea that you can use open/read/write/close to access any > resource. But without pipes, I don't think such an abstraction is very > useful. Pipes are just a notation to allow for a convenient use of coroutines, even from a command line interface. They make you think of concurrent processing, but (on single core machines - which was all they had at the time this was invented) it was just an emulation of concurrency on a strictly sequential system. Nothing really fancy at all, once you have the idea. And nothing that could not be emulated in a U-Boot environment, either. The question is: how urgently do we need it? My experience is that if anything is _really_ needed, someone will show up and implement it, probably funded by some customer who needs this feature for some product. I have yet to see any such urgent need for pipes in U-Boot. > > Expect the output of every program to become the input to another, as > > yet unknown, program. Don't clutter output with extraneous > > information. Avoid stringently columnar or binary input formats. That's the theory, yes. In reality, things are a bit different. Look at the output format of classic Unix commands: ls, ps, df, ... > I don't know about that. I think making U-Boot commands emit output > designed for machine consumption would require substantial effort. Unix commands usually have NOT been designed for "machine consumption", on contrary. Even network protocols, log files atc. were intentionally designed to be humanly readable. It's the flexibility of the tools which allows for clever usage. In U-Boot, commands could be cleaned up for better use in pipes - assuming we had those. But there would be no need to do this ina single huge action - it could be done step by step, one command at a time when somebody needs to use it in such a way. > >> * Tools such as grep, cut, tr, sed, sort, uniq, etc. which are extremely > >> useful when working with streams are not present in U-Boot. > > > > You are talking about OS environments here. But we are a boot > > loader. > > These programs are just as much part of the shell as the builtin > commands. Sorry, but they are definitely NOT part of the _shell_. They are part of the standard Unix toolbox for basic text processing, but for many good reasons each of these is a separate program, and the shell knows nothing of these. > > In which way do you think "a new language" needs to be ported when > > switching from an old to a new version of hush? It would be still a > > (mostly) POSIX compatible shell, with some restrictions. > > Modern Hush is completely unrecognizable compared to what we have in > U-Boot today. Any "updating" effort would be akin to going over the > entire upstream codebase and porting it from scratch. Agreed. But this means porting some code, which still implements the very same language (i. e. "shell"). There would be no new language in this case - just a bigger subset, less restrictions, more options, probably. 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 God made machine language; all the rest is the work of man.