OSDev.org

Sandras wrote:

iansjack wrote:

Sandras wrote:As far as I understand, Jezze intends to pass only files as arguments, but no flags or anything. That means you could do cc file.c.

And have a separate filter program to process -mno-red-zone?

I do not know what that option stands for (what does it stand for?), but I agree, that some things may be better left for command line flags. I was talking about what I think Jezze wants, not what gcc needs. For example, he could use a different compiler, which does not take your mentioned option, if he decides to self-host. Whatever that option does, I do not believe it is essential for a self hosting OS.

Don't worry about what the option does (it's 64-bit specific); it's just an example. It is just one of many hundreds of switches that gcc takes, and I can't see any way that filters could deal with options like this. Take a simpler one: -I. How does a filter on the output of gcc tell it where to look for include files? Not every option to a program can be applied as a filter on its output. Not just that, but the option actually conveys other information to the program. Even if you could apply it as a filter you somehow have to supply that information - the path where include files can be found.

I guess you could say that simple programs, like ls, use some sort of filter paradigm whilst more complicated ones, like gcc, use a combination of filters and options file; yet others would probably still need switches. But that's just inconsistent, and plain ugly. A good OS should rely on the least number of simple paradigms, not leave it to the user to remember different ways of working with different programs.

As a general aside, this discussion reminds me, in a roundabout way, of rdos's thread with respect to error codes and APIs. There's often a good reason why long-established ways of working are long-established.

Just because something is well established and proven to work well doesn't mean it can't be improved.

I think arguments have some ugly drawbacks. To start with they only come in one form, as the argc argv couple and sometimes even envp, even if programs might not like it's configuration to be formatted in this way. Each program also has to parse the arguments with is really kind of difficult to get right and that is why most programs require something like the getopts library.

And if I talk outside my comfort zone (i have no substance behind these claims) it prohibits some innovation. I've been considering things like multiple entry points for programs, moving running processes seamlessly between machines, handling protocols like 9p and some other things where arguments really don't fit in well or adds another level of complexity.

It could very well work if you build a command-line utility that handles typical needs of command-line (shell). The "shell" would then take parameters, but those are not passed to external programs, but rather executed internally. Ordinary programs rarely need parameters, but instead could use configuration files and similar.

Jezze wrote:Just because something is well established and proven to work well doesn't mean it can't be improved.

I think arguments have some ugly drawbacks. To start with they only come in one form, as the argc argv couple and sometimes even envp, even if programs might not like it's configuration to be formatted in this way. Each program also has to parse the arguments with is really kind of difficult to get right and that is why most programs require something like the getopts library.

I really don't see the problem here. The program is told how many arguments there are and is given them as a list of strings. What more, or easier, information could it have? To say that arguments come in only one form is akin to saying that there is only one way to run a program - by telling the OS (somehow) the name of the program that you want to run. Certainly do away with envp if you want to, but this is a separate issue. That's a method of telling programs default options without having to specify them every time you run the program; useful but ignore it if you don't like it.

As for parsing arguments, the program has to decide in some way how it is going to implement options; if you want to pass additional information to an executable you have to interpret it somehow. Take my example of the -I option with gcc. Somehow you have to parse the information that is being supplied (the include path) whether it is supplied via a command-line switch, an options file, or magic. How else are you going to convey that information to the program? If you can persuade me of some way of conveying that information other than via a command-line argument or via an options file (which is just a hidden form of argument), and with no additional processing required to use that information, then I'll concede that you have a point.

berkus wrote:

iansjack wrote:Take a simpler one: -I. How does a filter on the output of gcc tell it where to look for include files? Not every option to a program can be applied as a filter on its output.

Of course, it can be supplied as input.

I'm still not sure how an input filter would achieve this functionality. If the "filter" merely supplies information to the following program, which that program has to decipher, it's just a switch in disguise. But, unlike a switch, you are complicating things by creating a chain of interacting processes to do what a single process can easily achieve.

And already it is getting rather more unwieldily than a simple command-line switch. It all seems a little convoluted just to achieve what can be done more simply. It's all very well jumping through all sorts of hoops to avoid a simple "-I", but what's the point?

While I generally agree, that in some cases you can't/shouldn't go without command line arguments, I'd like to see a different way. After all, one of the reasons, why I started making a kernel, is that I wanted to explore the possibilities. And I have to say, that even before this thread, I was looking into Jezze's project Fudge, and he seems to have some interesting ideas there, and those that he has implemented, seem to work for him so far. Not saying that depends on whether you have command line arguments or not, but why make another Windows/OSX/Linux.

I think removing command line arguments from an OS requires a complete different view of the system. Once my brother Quoted Albert Einstein to me. I don't remember the exact quote and could not find it on the net, but it goes something like "Once your mind has moved to another dimension, it cannot see things like it did before.".

Reminds me of stack based machines. One could create files/areas in memory using a text editor and when the command is invoked the OS reads the files. Potentially the shell could hide this and do it automatically. i.e when some one types echo "hello world" the shell could write to a file like /common/commandPass or a specified region in memory. The contents of this file/region are "hello world". When the other side decides to read it the program could call a getArgs() method which would return a string of commands. (Same thing could be applied on syscall level and within c programs using global variables).

iansjack wrote:

berkus wrote:

iansjack wrote:Take a simpler one: -I. How does a filter on the output of gcc tell it where to look for include files? Not every option to a program can be applied as a filter on its output.

Of course, it can be supplied as input.

I'm still not sure how an input filter would achieve this functionality. If the "filter" merely supplies information to the following program, which that program has to decipher, it's just a switch in disguise. But, unlike a switch, you are complicating things by creating a chain of interacting processes to do what a single process can easily achieve.

And already it is getting rather more unwieldily than a simple command-line switch. It all seems a little convoluted just to achieve what can be done more simply. It's all very well jumping through all sorts of hoops to avoid a simple "-I", but what's the point?

Personally, simplification is reason enough.

For example (not trying to answer your question here, just giving out a though), I would separate compiler into a few smaller modules, which can be used independently of each other, but can also be used to achieve what a simple compiler would:
* preprocessor - handles #include, #define and friends;
* C to assembly converter (this could also be separated into several smaller modules);
* assembler.
Now you can write a script called cc.sh: I have to add that for a human being it would be simpler to understand just the stream redirection in comparison to stream redirection + flags.

But you can use, C to asm directly, if you want to hand optimize your program at lower level, or you could use pre-processor in entirely different scenario, even as you would use sed for changing certain word for others - that's not as convenient as sed, but it's just a nice side effect, which may one day come to be useful.

Personally, I'd either not use the "change header directory" flag at all, or make it a compile time option. Note that my compiler would not be gcc, which takes I'm not sure how many years to compile. Besides, it would not be the one executable, as I said, so it would take even less time to compile, if someone's worried about that.

Also I was thinking of something along the lines of what I think ACcurrent is trying to say. This is similar in concept to the stdout>stdin argument passing approach. Remember /proc/pid/cmdline in Linux? There're your arguments without argc + **argv, everything's a file, everything's a text stream. What should pid be equal to? /env/pid. Though this is really quite inefficient, but it is one more kind of way to pass arguments.

There is a lot of bagage in *nix in regards to program execution and similar that should be abandonded. And it is not retained "because it is useful", but for legacy / compability reasons.

Examples:
1. The idea that keyboard input, (terminal) output, serial ports and files are equivalent.
2. The idea that environment blocks should be passed between processes.
3. The idea of fork, and that a new process should share everything with it's parent.

These are not "superior" design-ideas. They are bagage, nothing else.

@sandras: What I like is that instead of dismissing an idea entirely you actually spend time pondering how a system implementing the idea would look like. Creds for that.

@rdos: I think if we start talking about all of those aspects of UNIX this thread will get out of hand.

@iansjack: I feel I haven't had time thinking about your very good and valid arguments.

Regarding the problem with the -I flag. To begin with it is a special case in the sense that what you are supplying to the program is a directory (which is a file in itself yes but stay with me) where the include files are stored. In some way a directory can be seen as a group, something that puts a label on a set of files so I think of that as something you could expand sort of like something you do when you use * in bash. So /include/ would become /include/* which in turn would become /include/file1.h /include/file2.h.

Ok... *pauses to think*

I need to give it more thought. Let me get back to you on this one.

Most current programs (especially unix-like utilities) are of the format: take input (possibly multiple inputs), convert via some mechanism to output (usually one) with the possibility of specifying some various different ways of modifying the underlying transformation (usually specified as command-line switches).

Your method of having the operating system (or perhaps shell?) providing the various inputs as streams to the program provides the benefit of simplifying the input process in that each program does not have to parse the command line itself and then attempt to locate and load each input, but rather rely on the OS to do that for you. This means that you reduce code duplication (and the potential for errors) and can also do things like specify other protocols for accessing the files (e.g. pipe the output from a revision control system to gcc). Perhaps you could do the same with the output too, and allow multiple output streams? This potentially has applications in, for example, image/video processing, where one process could split a video into separate frames, pipe it to a second process which performs some modification on them (e.g. sharpen/resize etc) and then pipes each frame back as inputs to a further program which combines them back to a video file.

However, as has previously been pointed out it is difficult to do away with some sort of command line arguments when dealing with complicated programs e.g. gcc. I agree that the current method of each program parsing its own command line to determine which is an input file and which is a switch and then deciding what to do with it could be improved. It is particularly difficult to pass arguments to gcc in a gui environment without starting a terminal shell. What if in your OS (non Windows/posix based) each application could be queried by the operating system to see what options it supports and the types of those, e.g. your c compiler would report something along the lines of: accepts one or more files of type text, produces one file of type binary, accepts one option called 'red-zone' of type bool, one option called 'arch' with several selectable options (e.g. i586, x86_64, arm), none one or more option called 'I' of type 'directory'. Then it would accept options specified on the command line or in another way in the gui (either by dragging and dropping or a context menu that provides various drop downs or check boxes for the options and directory pickers for the include directories). This reporting could either be provided by an external function required in each program, or by metadata distributed either within the executable or alongside it.

Regards,
John.

Jezze wrote:@sandras: What I like is that instead of dismissing an idea entirely you actually spend time pondering how a system implementing the idea would look like. Creds for that.

Thanks! : )