OSDev.org

Who Thinks That There Should Be Information About Command Prompt In The Wiki.

What sort of information? I ported GNU bash, and that fits all of my needs nicely.

I'd be interested to know what sort of info you're looking for that you can't find

Is there a reason for starting each word with a capital? Next to the annoying read it serves absolutely no purpose and makes me not want to take you to seriously. The fact that this poll is your 3rd post is a kind of affirmation of this thought. Next i am missing a reason why you want to have it in the wiki, backed up with pros and cons.
So unless you provide this information and edit your post i abstain the vote.

Don't be put back by these remarks, but the poll question could also be 'Who thinks the sky should be magenta?'. So give more info and i'll be glad to give an answer

os64dev wrote:Is there a reason for starting each word with a capital? Next to the annoying read it serves absolutely no purpose and makes me not want to take you to seriously. The fact that this poll is your 3rd post is a kind of affirmation of this thought. Next i am missing a reason why you want to have it in the wiki, backed up with pros and cons.
So unless you provide this information and edit your post i abstain the vote.

Don't be put back by these remarks, but the poll question could also be 'Who thinks the sky should be magenta?'. So give more info and i'll be glad to give an answer

Hey, at least he read the wiki enough to see that there isn't much on command prompts, but there is this: http://www.osdev.org/wiki/Text_UI unlike a lot of people who just post some very basic questions (how to get started) before reading the wiki much. And I am NOT naming names.

-JL (and I agree the capital letters.......no.) But there should be more on command lines. Even if you have bash(nice work JamesM)

The current TextUI page covers a lot of the practical aspects of the IBM-clones' video modes. It doesn't really cover any theory about command lines and how to write them.

I (and I'm guessing quite a few other people) are developing operating systems to which BASH can't be ported. So there does need to be a page on this. <poke>We're not all doing UNIX clones.</poke>


Edit: I've added it as a 'less urgent' item on the Wish List (http://www.osdev.org/wiki/Wish_List#Less_Urgent).

now the above are all very nice point and gives more detail. o yeah, i also voted yes.

<poke>We're not all doing UNIX clones.</poke>

How about DOS clones then

Hmm, I could write something on it. I would have to assume a few things though, and please tell me if I can be correct in assuming them:

- Fork()/Execve().
- The developer has flex/bison installed on their dev machine (if you don't know, flex is a lexical scanner generator and bison is a parser generator, each generates pure C code so should*l run on any OS).
- putc/getc support

If I can assume these I'll put together a sample project and stick some notes up about it (tutorial styleeee)

Sound alright?

JamesM wrote:- Fork()/Execve().

Not supportable on platforms that don't do memory protection / per-process memory mapping. (AmigaOS couldn't do a fork(), for example.) But I guess today that (having a non-protected OS) means either embedded systems, or an OS that is not far enough "down the road" to support it, and both cases will probably not aim for shell support anyway.

Solar wrote:

JamesM wrote:- Fork()/Execve().

Not supportable on platforms that don't do memory protection / per-process memory mapping. (AmigaOS couldn't do a fork(), for example.) But I guess today that (having a non-protected OS) means either embedded systems, or an OS that is not far enough "down the road" to support it, and both cases will probably not aim for shell support anyway.

Fair point, but the fork()/exec() combo is just the generic *nix mechanism for spawning a process. Readers are free to substitute their own such functions...

JamesM wrote:Fair point, but the fork()/exec() combo is just the generic *nix mechanism for spawning a process.

I know. But it is next to impossible to "spawn" a process on a system that doesn't use a MMU. That's what was the bane of libixemul, the Unix emulation layer of AmigaOS: It could emulate almost everything, except process spawning.

Solar wrote:I know. But it is next to impossible to "spawn" a process on a system that doesn't use a MMU. That's what was the bane of libixemul, the Unix emulation layer of AmigaOS: It could emulate almost everything, except process spawning.

The uClinux project implements "vfork()" in place of fork on MMU-less systems.. Thus when a parent process creates a child, both processes share all their memory space. (including the stack..)

I don't think there should be a wiki for a "command prompt" because the core of a "shell" or basic UI's are covered in almost EVERY other 'OS Dev Starters guide'. If you can write to video memory then from there it is up to the imagination to create your 'command prompt' and I dont believe it should be standardized in any way. As much as the wiki is helpful, it creates alot of dependancy if that is all someone goes off of. If someone cant create a simple UI after knowing the addresses for the video memory, then they probably need a little more practice in their language of choice (and that is NOT meant to be an insult to beginners).

I'd like to see more discussion of different shells, some features that are nice, how different shells work (does UNIX use the environment variables to manipulate directories? I don't know!), etc.

Your point about feeding off the wiki is valid for many other things too. I'm used to pretty much BASH now. I can't use DOS shell anymore. Does that mean I want to create a BASH shell for my OS? No. I want something new. I want discussion. I want an improvement. Only discussion, and open information, will let us make new choices in a better direction.

Those who want to clone something will always clone something, whether you give them the information (and the information will help them do it too). Those who want to create something new will do a better job with more information. Win Win.

Those who want to clone something will always clone something, whether you give them the information (and the information will help them do it too). Those who want to create something new will do a better job with more information. Win Win.

I hope you're not implying that there's something wrong with 'cloning' something? I notice a lot of people bandying around the term "POSIX clone" as if it were some horrible, vampish concept. Implementing an interface is not cloning.

Back on topic, do people want info about writing a lexeme and grammar for a simple shell with examples or not? Because I don't want to waste my time.

Nope, I'm not implying that it's a bad thing. POSIX is wonderful as a standard, I use it every day in my userland coding. I'm just saying that even though POSIX is wonderful, there still needs to be experimentation.

As for the wiki article, if you want to start one, I for one would appreciate it. How about 'Shell theory' or something like that for a name?