/λ/ - programming

If you are working embedded systems I would worry about assembly but with advances in resources that is less of an issue. It is still good to at least know a little to do reverse engineering.

>>591
shells being slow is basically expected, so i don't see what reason you would have for not using C? portability is definitely more important. if you want to put in extra time, do localised asm after you've already finished a portable C version (though make sure to check that it's actually more efficient too)

this sounds fun, though; what sorts of things weren't satisfying about other shells? or is it just for fun?

>>597
It's entirely just for fun. I'm not sure I can write something that will satisfy me enough to replace bash with it, but I sure am going to try.

It's going to be heavily integrated with lua. Right now I'm writing lua libraries in C to handle syscalls, termio, basically all the posix stuff, and then going to write the actuall shell in lua.

This way (in a fashion not entirely dissimilar to suckless.org software) the user will be able to edit the source of the shell itself in lua in order to customize it. The main goals of the project being customizability and easy script writting/integration. (I am not a fan of bash scripts)

So far, it's been really illuminating though. I'm starting to understand why things in bash are the way they are, once I've started trying to replace it.

>>599
do you think you could share what things you've found so far, researching? am interested in what goes into this as well.

can't claim to be a fan of lua, but either way, good luck!

>>600
Just simple language design stuff really, like why variables in bash are prefixed with $, or why the if/test commands and looping facilities are as funky as they are in bash.

Havne't delved very deep into actual bash source yet. Don't plan on looking into the actual source of bash/zsh until I get a solid POSIX shell done, and can focus on speed and "correctness".