Why open a terminal to execute a.out?

[Avichal]

I use ubuntu for programming. I am learning C and till now all the programs I have made require me to open a terminal, compile using gcc and then execute the a.out file.

Why can't I just click the a.out and run it? Why do I have to open a terminal and then execute it?
Basically all the programs do is to take some input, manipulate it and produce an output. Input is taken through stdin and output through stdout. Is terminal the only way to connect to stdin and stdout?

Does my question make sense?

 

[D H]

Why can't I just click the a.out and run it? Why do I have to open a terminal and then execute it?

Because there's more to a desktop app than just the thing that is executed underneath the hood. The thing that is executed underneath the hood, in this case your a.out, still needs to exist as an entity of its own. Creating that executable file is (in this case) the job of the compiler. All the other stuff that collectively form a desktop app -- those are the job of other tool(s), not the compiler.

 

[jtbell]

Why can't I just click the a.out and run it? Why do I have to open a terminal and then execute it?

Without a terminal, where would the input to stdin come from, and where would the output to stdout go to?

 

[Avichal]

Because there's more to a desktop app than just the thing that is executed underneath the hood. The thing that is executed underneath the hood, in this case your a.out, still needs to exist as an entity of its own. Creating that executable file is (in this case) the job of the compiler. All the other stuff that collectively form a desktop app -- those are the job of other tool(s), not the compiler.

Are the other tool(s) called drivers? So when a terminal starts it calls the other tool(s) to do the other stuff?

 

[Mark44]

Are the other tool(s) called drivers? So when a terminal starts it calls the other tool(s) to do the other stuff?

I wouldn't call drivers "tools". Drivers are extensions of the operating system so that it can send and receive data from the devices that are connected to the computer. There are drivers for the keyboard, mouse, display adaptor, hard drives, USB ports, network cards, and so on.

 

[Avichal]

I wouldn't call drivers "tools". Drivers are extensions of the operating system so that it can send and receive data from the devices that are connected to the computer. There are drivers for the keyboard, mouse, display adaptor, hard drives, USB ports, network cards, and so on.

So what are the other things required for a desktop app?

 

[jim mcnamara]

Answer: Windowing. It is a large app. Windows runs explorer.exe which is the same idea.

You are confusing interface with terminal. The terminal has a simple interface - /dev/tty with stdin stdout, stderr.
Windowing works on events processing - from the mouse and the keyboard, for example.. Keyup, keydown, mouse over, Window focus etc.

I don't get your issue here. It's like saying why do I have to turn on my computer and type? Why it this a problem? Do you have to create a terminal everytime you run code? Can you not leave the terminal open and minimized.

 

[Avichal]

Answer: Windowing. It is a large app. Windows runs explorer.exe which is the same idea.

You are confusing interface with terminal. The terminal has a simple interface - /dev/tty with stdin stdout, stderr.
Windowing works on events processing - from the mouse and the keyboard, for example.. Keyup, keydown, mouse over, Window focus etc.

I don't get your issue here. It's like saying why do I have to turn on my computer and type? Why it this a problem? Do you have to create a terminal everytime you run code? Can you not leave the terminal open and minimized.

I have no problem leaving my terminal open and minimized!
I was just curious to know what is actually happening in the back-end.

 

[jtbell]

About 20 years ago, I did some programming in Fortran, C++ etc. under "classic" Mac OS, before the Unix-like OS X with its Terminal application came into being. The programming system had an option to generate either a normal Mac OS application, in which case the programmer had to write code for windows, I/O, etc.; or a "console application", in which case your compiled code was linked with pre-compiled library code for a simple terminal-like application that could be double-clicked in order to run it. This console window did not have a command line like the Unix/Linux xterm, but only provided for standard input via the keyboard and standard output via the window.

I've never seen this done under *nix, but it ought to be possible in principle.

 

[rcgldr]

Why can't I just click the a.out and run it?

Is there some way in *nix to associate a *.out file as a runnable console program?

under "classic" Mac OS, before the Unix-like OS X with its Terminal application came into being. The programming system had an option to generate either a normal Mac OS application, in which case the programmer had to write code for windows, I/O, etc.; or a "console application", in which case your compiled code was linked with pre-compiled library code for a simple terminal-like application that could be double-clicked in order to run it. This console window did not have a command line like the Unix/Linux xterm, but only provided for standard input via the keyboard and standard output via the window.

You could have used Macintosh Programmer's Workshop (MPW), wiki article:

wiki_mpw.htm

I always thought it was strange that MPW, used to create GUI programs for the Mac, ran under a dos console like window with a conventional command line interface. There were other GUI based compilers, like Think C, and even a 4th generation language, Prototyper (the programmer created a user interface via a drag and drop GUI interface, and Prototype would generate the code), and both of these had "proper" GUI interfaces, similar to the IDE's of current tool sets.