[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: MSH function support
From:       Mike Frysinger <vapier () gentoo ! org>
Date:       2009-03-22 23:12:58
Message-ID: 200903221912.59651.vapier () gentoo ! org
[Download RAW message or body]

On Saturday 21 March 2009 15:54:51 Denys Vlasenko wrote:
> On Thursday 19 March 2009 13:07, Mike Frysinger wrote:
> > > > what's the nommu status of hush ?  nommu is the only reason msh lives
> > > > on.
> > >
> > > hush is working on NOMMU.
> >
> > you dont happen to know off hand feature parity between the two ?  msh
> > doesnt support a whole lot, but it'd be annoying if one of those things
> > were missing in hush.  i'll switch the Blackfin dist to hush after our
> > release (in the process of freezing/making), so we'll get some testing
> > there ...
>
> What msh does and hush does not support:
> * here documents

this seems like it should be easier.  here documents are just sending to stdin 
which means we can refactor:
cmd << EOF
input
EOF

into this statement:
printf "EOF\n\n" | cmd

i dont think here strings are part of POSIX though ?  those would be the same 
method though:
cmd <<<input
printf "input\n" | cmd

> var=val
> func() {
> 	echo Hello world
> }
> (echo "$var";func;echo $?)
>
> I cannot just vfork+re-exec "hush -c 'echo "$var";func;echo $?'".
> I need to do:
>
> hush -V 'var=val' -F 'func=\necho Hello world\n' -c 'echo "$var";func;echo
> $?'
>
> and for this, I need to have all functions as strings!

that gets kind of ugly ... how do you detect which vars are needed ?  eval 
indirection makes any chance of sanely detecting things impossible.  better to 
pass all variables that are set (but not exported) with -V to the sub shell.  
or maybe use environ to pass variables ... bash does this with "exported 
functions", so while it might not be clean, there is a little bit of 
precedence.

and i dont know what POSIX says wrt "valid" environment, but if the env string 
read something like:
\001hush-var=val
then it shouldnt really be readily accessible ...

> > > NOMMU situation is very simple: the only applet which is
> > > completely off-limits for NOMMU is ash.
> >
> > yes, but there are sub-features which are no go's atm.  job support
> > (obviously) and sub shells (not so obvious depending on the code).
>
> IIRC job control in hush is the same as on MMU. There is no reason
> it should be more limited.

jobs is non-existent ... enable job support and force nommu support and you'll 
see it not work.
hush: can't exec 'jobs': No such file or directory

> Pinging me about hush problems might make them disappear faster :)

sure, once our next release is out, we'll pay attention to hush.  since we 
knew msh sucked, we looked for workarounds in source rather than fixing the 
shell itself.
-mike
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]