From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heinrich Schuchardt Date: Fri, 25 Sep 2020 15:38:22 +0200 Subject: [PATCH 0/3] add "call" command In-Reply-To: <4118922.1601039395@gemini.denx.de> References: <20200925111942.4629-1-rasmus.villemoes@prevas.dk> <4b00225d-d960-4a14-9aec-110ddddf7f30@gmx.de> <4118922.1601039395@gemini.denx.de> Message-ID: <99821acf-b921-2c06-05b8-dd32058f28f2@gmx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 25.09.20 15:09, Wolfgang Denk wrote: > Dear Heinrich Schuchardt, > > In message <4b00225d-d960-4a14-9aec-110ddddf7f30@gmx.de> you wrote: >> >> Further we cannot first introduce a command call and then eliminate it >> due to backward compatibility. We should decide on the final version >> beforehand. > > Full agreement. we need a concept of what is needed / wanted first. > And then we should look how current vrsions of hush fit into this. > >> In the Linux world you can override a command using an alias. So I am >> not sure if a built in command should take precedence over a variable of >> the same name or the other way round. > > This is simple. The PoLA (Principle of Least Astonishment) applies > here. Behaviour must be the same as in other (to some extent POSIX > compatible) shells. A shell should parse it's input, not adhoculate > it. For me this could be realized by enhancing the run command to allow: run varname1 varname2 ... varnameN --args argv1 argv2 argv3 Arguments argv1, argv2, ... are passed to the script identified by the last variable (varnameN). No new command to learn. Just a new option. Best regards Heinrich