Surprising to see this article. I am a CS student, and at the second year, in OS course in one the assigment, we are actually building Shell in C. Very simplistic one. Great to read.
Building a simple shell in C – Part 3
21–30 of 48 posts
Re: Building a simple shell in C – Part 3
#22Quoted post unavailable.
Yes. I enjoy writing C and as long as it does not face the internet and does not handle that much untrusted input I will just use it. I frankly haven't found an ecosystem in which I feel more comfortable than the one from C. Yes, C has its vulnerabilities, but for my own projects I do in my own time, I will use any language I have fun with, even if it has huge problems.
This in my opinion, is the one true answer.
Same when people post "I built X with Language Y" and some one comments "Why did you use Y? You should have used Z". What difference does it make? You don't like it don't use it!
Don't get me wrong, I'm all for constructive criticism but sometimes the comments do not come across as criticisms but as attacks.
Again, just my opinion.
Re: Building a simple shell in C – Part 3
#23Quoted post unavailable.
If you want to discourage people from using C, like it sounds like you do, there's ways to do so without being a finger-wagging nag. For example, you could write a follow up article that demonstrates security vulnerabilities of the simple shell in the linked article, and build an analogue in Rust and show how it addresses them. That's probably more persuasive than writing a drive-by post shitting on a cool project th…
Also, examine why people are using C, and improve alternatives until they can match it.
Re: Building a simple shell in C – Part 3
#24Earlier quoted context omitted.
Yes. Some people (myself included) enjoy "unsafe" languages like C. I'm not one of those people that argue that being careful is enough. For applications where security really matters, _please_ use something with a bit more verification (though even that doesn't disqualify C, see seL4). Now take a singleplayer game, or a text editor. It's not a security risk if these crash, so do you need the safety? I'd argue it's u…
> Now take a singleplayer game, or a text editor. It's not a security risk if these crash, so do you need the safety Any program that operates on untrusted data can be a security vulnerability. If an attacker can make your text editor execute arbitrary code if you open a specially crafted file, that's a major security problem. Why would you create the risk of this sort of problem on purpose when we have adequate safe…
Even an offline game is dangerous. What if the save files are backed up and that storage is compromised? This allows an attacker to escalate access from one computer or service to others.
Re: Building a simple shell in C – Part 3
#25I have personally tried to build one in C but the parsing was the real pain, I managed to have a tokenizer, barely found how to make an AST and never figured out what to do with. All parsing tutorials are about parsing mathematical expressions, I found it hard to adapt to shell grammar.
Parsing shell input is somewhat different than other languages because keywords are contextual. For example `if echo` and `echo if` are both legal, but `if` is only a keyword in the first example. This affects the design of the lexer.
Despite that, fish-shell still uses a traditional handwritten recursive descent parser. Link if you want to see: https://github.com/fish-shell/fish-shell/blob/master/src/ast...
Re: Building a simple shell in C – Part 3
#26I have personally tried to build one in C but the parsing was the real pain, I managed to have a tokenizer, barely found how to make an AST and never figured out what to do with. All parsing tutorials are about parsing mathematical expressions, I found it hard to adapt to shell grammar.
You should check out Crafting Interpreters! http://craftinginterpreters.com
Wow this looks really interesting, thanks for sharing!
Re: Building a simple shell in C – Part 3
#27Shameless Plug: a simple shell in ~60 lines of Go: https://simjue.pages.dev/post/2018/07-01-go-unix-shell/
Re: Building a simple shell in C – Part 3
#28I have personally tried to build one in C but the parsing was the real pain, I managed to have a tokenizer, barely found how to make an AST and never figured out what to do with. All parsing tutorials are about parsing mathematical expressions, I found it hard to adapt to shell grammar.
Yes a huge part of shell is parsing, and C is a bad language for that.
If you want POSIX shell you'll have at least 5K lines of parsing code; if you want bash it's at least 10K lines. It's closer to 20K lines of C in bash itself.
There's really no way around that, and IMO the best answer is to use a different language -- which is ALSO hard, because many language runtimes don't support fork() or signals in the way that a shell needs.
(e.g. CPython is actually closer than say Go because it supports fork() and exec(), but even it has issues with signals, EINTR, etc.)
I wrote a bunch of posts on how Oil does it:
How to Parse Shell Like a Programming Language - https://www.oilshell.org/blog/2019/02/07.html
posts tagged #parsing-shell: https://www.oilshell.org/blog/tags.html?tag=parsing-shell#pa...
Oil Is Being Implemented "Middle Out" https://www.oilshell.org/blog/2022/03/middle-out.html
Re: Building a simple shell in C – Part 3
#29Earlier quoted context omitted.
> It's not possible for humans to write correct and secure C code on an ongoing and consistent basis. https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-repl... "Safety. Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows." "I understand that many people, particularly those already enamored with Rust, won’t agree with much of this article. B…
> "Safety. Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows." The problem is that when you write a program in C for the public , this program's buffer overflows and segfaults aren't a problem only for you , but also for everyone around you . Security vulnerabilities are a serious problem. You can think of them as a form of software pollution:…
> The problem is that when you write a program in C for the public, this program's buffer overflows and segfaults aren't a problem only for you, but also for everyone around you.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Re: Building a simple shell in C – Part 3
#30Quoted post unavailable.
Yes. Some people (myself included) enjoy "unsafe" languages like C. I'm not one of those people that argue that being careful is enough. For applications where security really matters, _please_ use something with a bit more verification (though even that doesn't disqualify C, see seL4). Now take a singleplayer game, or a text editor. It's not a security risk if these crash, so do you need the safety? I'd argue it's u…
Yet OWASP vulnerabilities hit lots of non-C languages and things that you definitely don't do in C: https://owasp.org/Top10
I am starting to wonder lately if all this "implicit language security" (use Rust, use Go so you don't have memory errors, overflows, etc.) is not just some way to shift accountability to some other layer.
I do understand that lower level languages require better programming skills because you actually need to know what you are doing, unlike Python which generally shields you from a lot of ugly things, but that's about it. You can do bad shit in Python/Java too. And that happens like A LOT.
So what are we actually protecting our services/software from? Reducing the attack surface, totally agreed. But then log4j... Or are we moving to more "user-friendly" languages because they don't require such an amount of knowledge?
I don't know. I do see the value Rust and Go create, but if we follow good software practices in C, don't you think we could ship decent safe software there too? Or are all C programs inherently buggy by default?