On Apr 19, 2005, at 7:20 AM, Peter wrote:

>
> On Tue, 19 Apr 2005, Dan LaBell wrote:
>
>>> Is there perhaps an equivalent to ash or busybox on netbsd, for 
>>> rescue and repair purposes ? (ash is a minimal featureset 
>>> sh-compatible shell that is statically linked. It is used with some 
>>> systems for installation, bootable floppies and such).
>>> Peter
>> I don't see it pkgsrc.  HMM.. There is osh, at a glance looks like an 
>> old bourne shell, w/o the new posix features.
>> 22536 /usr/pkg/bin/osh
>> 128043 /bin/sh
>>
>> Glad you asked, I might not not have noticed, I've been complaining 
>> how bloated
>> /bin/sh looks these days.
>>
>> Wonder if replace /bin/sh with this, or do the rc scripts rely on the 
>> new posixisms?
>
> You should be able to boot normally to a shell running in a terminal 
> using /rescue/sh. You could try to copy /rescue/sh to /sbin/init and 
> see what happens (since init is missing). That should boot the machine 
> to a root shell prompt. You can do the copying from an install boot 
> diskette, then sync, umount and reboot, without the diskette.
>
The thread has drifted somewhat, approaching academic, at least in my 
case,  I think the original question was actually, "why panic if no 
init"  (in the compiled in locations)...  In my case I tried to answer 
the above, and also in process suggested something that doesn't work.. 
(I did say 'maybe try' ).. For myself, I had just been trying to see if 
I could tweak INSTALL_TINY which claims  needs 4MEGS, smaller.. there 
was a thread about someone trying to INSTALL on 386sx w/ only 2 megs... 
and been trying to test my results, when I noticed that when asked for 
init bin/sh doesn't work, it dies, so in course of my
experimentation I noticed... I never actually had the filesystem 
problems.

I guess one should do /rescue/init for kernel's prompt then /rescue/sh 
when init asks for shell. Perhaps the kernel should look for 
/rescue/init as well as init, oinit, and init.bak??


> This works for most *nices I know of (assuming the kernel comes up ok 
> and the root fs can be mounted and /bin/sh is not linked against 
> anything, i.e. it is totally static).
/sbin once connoted static didn't it? (on some systems??)


As far ash, I've found it quirky, and typically end up hitting an 
incompatibility for
any project that I ever attempted w/ it.  /bin/sh with its new posix 
features, job control, and linediting, among others, links, to ledit 
and ltermcap,  osh only needs
lc , I'm guessing that osh static will be smaller than /rescue/sh ? or 
not?
>>

>> Wonder if replace /bin/sh with this, or do the rc scripts rely on the 
>> new posixisms?
Here, again, drift from original topic.. I'm asking if rc scripts are 
'bourne compatible'
or do they use the new features in the posix sh ...  When I see /bin/sh 
  I think
bourne shell... I don't think posix shell, but /bin/sh is posix.. so I 
posed the question.   Now, I notice that osh man page claims it is 
backward compatible with
Thompson shell, the Six Edition shell, not the 7th ed Bourne shell, 
also seems to suggest
not secure as well.. sigh.


IMO posix should have
1. struck ages ago , in the time frame of  bash1 -> bash2, around that 
time /bin/ksh (+/- a few years) became standard on systems.  I think 
every shell programer that wanted extra
features over bourne shell, used either ksh, or perl, or tcsh, or bash, 
or wrote helper progs in C... It seems kinda of late.

2. standardized two shells: kept sh small, so there are less blocks to 
load from disk,
and less memory used on simple scripts.. maybe add a few builtins like 
[ , true, false,
and either, not added Arithmetic Expansion, or add expr as a builtin.  
Then made jsh,
the sh with job control found on Suns and elsewhere, a standard, and 
added linediting
and job control there... it like a waste for shell scripts
like
#! /bin/sh
SETONEVARIABLE="to some value"
export SETONEVARIABLE
exec someprog $*

to have linediting and job control, and other user features, just makes 
simple scripts more costly, taking more time to load blocks from disk 
etc.


> I have used similar methods to bootstrap minimal systems on embedded 
> pcs with low memory etc. The earliest I did was 1.2.13 linux based, 
> almost 10 years ago, when you still needed 2 floppies to start linux 
> and I got it down to one, without using a boot manager ;-)
>
> Peter
>