Writting a shell is easy, but it's already done (do'h). You could be restricted to a really basic one, with no cd having to reimplenent that yourself. A simple "cd" command taking ARGV as the path would be around 10 lines in C.
Reimplementing echo would be the obvious second thing to do, and later, a barebones cat a la plan9/OpenBSD. Finally the 3rd basic tool would be an ed(1) clone without regex support.
ed(1) can work as a simple "more" like pager, too. Add add readonly flag to argc/argv so it fopens the file with just
read permissions and you have the best setting to start.
ed(1) is much easier to write than a visual editor.
Any TCP/IP stack related would be hard, but it the libc/kernel has a basic implementation bundled, I'd write a gopher client and I'd declare the problem solved, as I can fetch everything from here.
Gopher is much easier to implement than banging the FTP ports. Also you can do a barebones IRC client with few lines. Nothing too complex, but usable enough.
Or better: write a netcat clone, https://git.2f30.org/openbsd-nc/ connect to gopher, fetch the specs, write a dumb gopher client, (or fetch sacc(1), you can compile it without ncurses by editing the Makefile), connect to gpoherpedia/gutenberg Gopher proxies to fetch all the documentation.
But the netcat clone combined with the ed editor could serve as a basic IRC client with FIFO files, also as a basic gopher client if you don't want to fetch sacc(1). Once you get connected to an IRC channel in order to seek help, among Gopher, you'll have tons of information.
Also it's the most Unix-y way to solve a problem, by far.
Note: The “cd” command must be a built-in command in the shell, since it must call chdir(2) inside the shell process; it must affect the “current directory” internal state of the shell process. Therefore, “cd” cannot be a separate external binary.
You could sort of do it via Bernstein chaining. If we call this substitute command 'notcd' then you'd invoke it like `exec notcd /some/path sh` and then continue your work in the subshell.
The shell would then have to also have a mechanism to pass all local state such as command history, local non-exported variables (including shell functions), open file descriptors, currently running jobs, etc. to the subshell.
We're talking about bootstrapping to more usable tools, not about whether this hack fully replaces the standard feature. 'cd' certainly comes before command history, for example.
Incidentally you could take the same approach to some other shell built-ins, like redirection. Instead of `cat foo >outfile`, define a program named '>' and then say `> outfile cat foo`. (Assuming the initial bare-bones shell parses '>' as just another ordinary character, not special.) Use these until you've written a more featureful shell.
It might be interesting to figure out a design for a shell where this decentralized approach works well and does not feel like a kludge -- I imagine you'd have to change some deeper aspects of the OS design to really make it work.
There are a couple of problems with that design. Firstly, if the program crashes for any reason, you don’t have a shell to fall back on, unless you run the debugger as your shell, like ITS did back in the 1960s. Secondly, you can’t have more than one job running at the same time, or even any suspended jobs. And even ITS (again) has subjobs.
If your shell crashes, same problem. And the shell is a bigger program. This issue seems pretty orthogonal. Again, I was never saying this is a better way to design a shell for everyday use, unless maybe with a lot of complementary design decisions changed to go with it.
> Secondly
Why couldn't you spawn jobs like `& do-the-job` in this style? Admittedly I don't remember much about Unix job handling.
You're asking on Hacker News if people still use IRC? In this same discussion thread where people are talking about writing Gopher clients?
Yes, it's still in very wide use. The numbers might be declining as greybeards retire and noobs pick Slack instead, but there's still plenty of us out here.
It's the default method for technical channels such as programming or OS projects. Please, use IRC with TLS if you can.
Also, Usenet is still good for Slackware and C users, you'll have a high level there. comp.lang.c.moderated and alt.os.linux.slackware are really good. Also, the ones for Interactive Fiction and Nethack, I can't remember the groups. rec.games.roguelike.nethack, maybe.
Freenode is where I turn when I'm completely stumped by a tough problem. Some helpful person usually points me in the right way quickly. Sometimes I can even point someone in the right direction myself.
Reimplementing echo would be the obvious second thing to do, and later, a barebones cat a la plan9/OpenBSD. Finally the 3rd basic tool would be an ed(1) clone without regex support.
ed(1) can work as a simple "more" like pager, too. Add add readonly flag to argc/argv so it fopens the file with just read permissions and you have the best setting to start. ed(1) is much easier to write than a visual editor.
Any TCP/IP stack related would be hard, but it the libc/kernel has a basic implementation bundled, I'd write a gopher client and I'd declare the problem solved, as I can fetch everything from here.
Gopher is much easier to implement than banging the FTP ports. Also you can do a barebones IRC client with few lines. Nothing too complex, but usable enough.
Or better: write a netcat clone, https://git.2f30.org/openbsd-nc/ connect to gopher, fetch the specs, write a dumb gopher client, (or fetch sacc(1), you can compile it without ncurses by editing the Makefile), connect to gpoherpedia/gutenberg Gopher proxies to fetch all the documentation.
gopher://1436.ninja/1/Project_Gutenberg_in_Gopherspace
gopher://gopherpedia.com
But the netcat clone combined with the ed editor could serve as a basic IRC client with FIFO files, also as a basic gopher client if you don't want to fetch sacc(1). Once you get connected to an IRC channel in order to seek help, among Gopher, you'll have tons of information.
Also it's the most Unix-y way to solve a problem, by far.