[OpenIndiana-discuss] Shell to use?

[Hung Nguyen Gia]

Maybe our system just showing it age. Design decision at the time they was made are good but it's no longer true.

It's time to change, if we are willing to change. There are plenty of reference sources, from both Linux or the BSDs.




---- On Tue, 19 Jan 2021 17:17:54 +0700 Jim Klimov <jimklimov at cos.ru> wrote ----

 > On January 19, 2021 4:27:04 AM UTC, Hung Nguyen Gia via openindiana-discuss <openindiana-discuss at openindiana.org> wrote: 
 > >OI included many shells. So far I only stick with the default, bash. 
 > > 
 > >But the performance is very bad. e.g: when using pkgsrc to build 
 > >packages. 
 > > 
 > >As I have said on this list: pkgsrc bootstrap on OI is 4x slower than 
 > >on FreeBSD. Building packages also that slower. 
 > > 
 > >I think the problem is of the shell. Because I see it checking for 
 > >something very slowly. 
 > > 
 > >The output printed on the screen 'Checking for...' is line by line, 
 > >very slow. Meanwhile, the same thing on FreeBSD is blazing fast that I 
 > >can't even see what's going on at all. 
 > > 
 > >I'm thinking about using other shell than bash. 
 > > 
 > >But I can't test with each shell. They are too many. 
 > > 
 > >From your own experience, which shell is the fastest? 
 > > 
 > >_______________________________________________ 
 > >openindiana-discuss mailing list 
 > >openindiana-discuss at openindiana.org 
 > >https://openindiana.org/mailman/listinfo/openindiana-discuss 
 >  
 > This matches my experience sadly, also on systems with ksh93 as the real default system shell since Solaris, and e.g. configure scripts using that as-is or patched to use bash explicitly. 
 >  
 > Same codebase mounted from OI over NFS to a Linux VM passes configuration much faster - so it is not e.g. overheads of disk/FS layers. 
 >  
 > Similarly for shell/fork heavy tests like https://github.com/42ity/JSON.sh unit-testing (nearly zero I/O, but lots of shells tried) - the linux worker completes minutes before OI does. 
 >  
 > As far as I could unravel and guess, this is just about a more expensive forking routine (RBAC and all) than on less protective OSes. This is a PITA sadly, but unless something is just broken in the kernel but rather really does more work by design because of different goals and trade-offs, then so be it. 
 >  
 > If something *is* broken and can be made faster, it would be much appreciated :-) 
 >  
 > Jim 
 >  
 > -- 
 > Typos courtesy of K-9 Mail on my Android 
 >