41–49 of 49 posts
Bit of pedantry but I don't think traditional unix shell (like this) follows repl model; the shell is not usually doing printing of the result of evaluation . Instead the printing happens more as a side effect of the commands.
It prints a prompt.
Bit of pedantry but I don't think traditional unix shell (like this) follows repl model; the shell is not usually doing printing of the result of evaluation . Instead the printing happens more as a side effect of the commands.
It’s a shell, not the whole thing. The whole thing is the shell+kernel+programs.
[dead]
Yup, job control is a huge mess. I think Bill Joy was able to modify the shell, the syscall interface, and the terminal driver at the same time to implement the hacky mechanism of job control. But a few years later that kind of crosscutting change would have been harder One thing we learned from implementing job control in https://oils.pub is that the differing pipeline semantics of bash and zsh makes a difference In…
In this case it was the Zed editor spawning the zsh shell:
How to Lose Control of your Shell - https://registerspill.thorstenball.com/p/how-to-lose-control...
zsh has a bug where it doesn't do the job control cleanup properly in some cases -- when fork-exec() optimizations happen.
This can mess up the calling process. For example, here you could no longer kill Zed by hitting Ctrl-C, even after zsh is done.
My comment: https://lobste.rs/s/hru0ib/how_lose_control_your_shell#c_dfl...
Is there a (real) shell whose code is relatively short and self contained and would be valuable to read? This was always something I wanted to do but never quite spent time to look for a good one to explore.
I don't know how real you want -- those criteria are probably self contradictory :-) Marc Rochkind's book Avanced UNIX Programming implemented a basic shell, through iterations. You can see the first at e.g. here https://github.com/gmarler/AUPv2/blob/master/c5/sh0.c It might be a bit old too. The book is very good but again, quite old. There seem to be free copies of it on the net. BTW, does anyone know if Marc Rochk…
Building a shell is a great exercise, but honestly having to deal with string parsing is such a bother that it robs like 2/3 of the joy along the way. I once built a very simple one in Go [0] as a learning exercise and I stopped once I started getting frustrated with all the corner cases. [0] https://github.com/lourencovales/codecrafters/blob/master/sh...
A common problem I noticed is that if you took certain courses in computer science, you may have a pre-conceived notion of how to parse programming languages, and the shell language doesn't quite fit that model I have seen this misconception many times In Oils, we have some pretty minor elaborations of the standard model, and it makes things a lot easier How to Parse Shell Like a Programming Language - https://www.oi…
Bit of pedantry but I don't think traditional unix shell (like this) follows repl model; the shell is not usually doing printing of the result of evaluation . Instead the printing happens more as a side effect of the commands.
I always include $? in the prompt, so I guess I can say it does print the result of the evaluation.
Earlier quoted context omitted.
Editing the current line works because I brought in https://man7.org/linux/man-pages/man3/readline.3.html towards the end so I could support editing, tab completion, and history. IIRC readline uses a `char *` internally since the length of a user-edited line is fairly bounded.
worth noting that you get basic line editing for "free" from kernels tty subsystem even if you don't use readline.