Programs without arguments
Posted: Wed May 02, 2012 4:18 pm
All right. I have just recently started something that I might come to regret but in my world it makes sense somehow but I'm often wrong (hey I don't have an IQ of 160 
) and I like the feedback I get here so I will try to explain the reasoning behind my decision to the best of my ability.
What I've done is that I've removed the possibility to send program arguments to my userspace programs. This means that instead of the usual:
Now all my programs must look like this:
When a program is started by using the system call execute() it will automatically inherit all the open file descriptor from it's parent so it will share STDIN and STDOUT and any other open files the parent has. If it needs another file it can use fopen() just as on any other UNIX operating system but those descriptors will only be local to the child itself.
To illustrate what I mean lets take the program cat. Normally you would give cat some arguments saying what files it should concatenate. My implementation of cat does not have any notion of what files it should work on (it does not get any arguments with the filenames), all it needs to know is that it can read data from some predetermined file descriptor like stdin and print it to stdout. This is pretty much the same as a normal pipe.
An simple implementation could look like this:
This version of cat is very limited in that it only prints the first 0x1000 bytes of it's file descriptors 3 and 4 (and not stdin as you might have noticed).
I like this way of writing programs because it almost forces programs to do one thing and do it well which is what the UNIX philosophy is about (I've heard). If a program does not have options a program can't really do much else than one thing. Many programs on modern UNIXes have a shitload of different parameters and you often don't remember or use half of them anyway. Without arguments you need to have many smaller programs to do all the things one typical program could do but at the same time you only use a subset of that normal program anyway.
Another good thing about not having arguments is that when calling execute() I don't need to copy the arguments from the parent's memory space to the child which I would have to do otherwise. This saves a few lines of code so it's nothing important but it separates the processes even more which I like because now I don't need to add stuff to the stack or the heap or wherever you might store the arguments.
Also it makes the implementation of a shell quite interesting. Given an input string like this:
All it has to do is to call fopen() on "myfile.txt" and "anotherfile.txt" before calling execute("cat") and cat, when started, will automatically print the contents of the supplied files without having any need to know their names. It would be just a little bit more complicated to add pipes and redirects but still pretty simple.
Well... that was all I had. Does it make any sense what so ever?
) and I like the feedback I get here so I will try to explain the reasoning behind my decision to the best of my ability.What I've done is that I've removed the possibility to send program arguments to my userspace programs. This means that instead of the usual:
Code: Select all
unsigned int main(int argc, char **argv)
{
return 0;
}
Code: Select all
void main()
{
}
To illustrate what I mean lets take the program cat. Normally you would give cat some arguments saying what files it should concatenate. My implementation of cat does not have any notion of what files it should work on (it does not get any arguments with the filenames), all it needs to know is that it can read data from some predetermined file descriptor like stdin and print it to stdout. This is pretty much the same as a normal pipe.
An simple implementation could look like this:
Code: Select all
void main()
{
char buffer[0x1000];
unsigned int count;
count = fread(3, 0x1000, buffer);
fwrite(STDOUT, count, buffer);
count = fread(4, 0x1000, buffer);
fwrite(STDOUT, count, buffer);
}
I like this way of writing programs because it almost forces programs to do one thing and do it well which is what the UNIX philosophy is about (I've heard). If a program does not have options a program can't really do much else than one thing. Many programs on modern UNIXes have a shitload of different parameters and you often don't remember or use half of them anyway. Without arguments you need to have many smaller programs to do all the things one typical program could do but at the same time you only use a subset of that normal program anyway.
Another good thing about not having arguments is that when calling execute() I don't need to copy the arguments from the parent's memory space to the child which I would have to do otherwise. This saves a few lines of code so it's nothing important but it separates the processes even more which I like because now I don't need to add stuff to the stack or the heap or wherever you might store the arguments.
Also it makes the implementation of a shell quite interesting. Given an input string like this:
Code: Select all
$ cat myfile.txt anotherfile.txt
Well... that was all I had. Does it make any sense what so ever?
