Why does it seems like I can't open A executable file created on C++ by double clicking it.

I have a file that I ran from an IDE an I would like to know if there is a Way to set that file to Open the terminal when clicking it just like an .exe file on windows will do.


  • A C++ code I could add to my source code that will allow this.

  • Configure My Pc to open it.

I'm trying to Avoid toolkits as possible I recently compiled an application on Windows (Thanks to my cousin, he has a PC with windows)

And It would be Great if could do the same can be done on Windows on Linux Because we have 2 Release's Folders.

And I would like this simple Terminal based app could run withouth having to be an expert.

I have added this line:


It opens on terminal but just show the file path not the actual program any suggestion?

migrated from stackoverflow.com Jun 14 '11 at 8:28

This question came from our site for professional and enthusiast programmers.

  • @Leandro rather than adding "answers" to add detail or reply to respondents, please either edit the question (to add detail), or use "Add Comment" (to reply to people etc) – Marc Gravell Jun 14 '11 at 9:03

I would expect that you need to set the the "executable" bit on the file that is output by the Linux C++ compiler, I do not think this is done by default for security reasons.

Simply "cd" to the directory that your generated executable is in then

chmod +x myexecutable

Replacing "myexecutable" with the name of your compiler output.

Then try to run it with ./myexecutable

I believe this should also make the program "runnable" using mouse click as well as by console.

Similarly if you need to run a "script" of commands you could try the following in a script file, save this as "myexe.sh" or something similar:


Then again use

chmod +x myexe.sh 

to make it so you can run the script by clicking on it.

  • @Leandro I've edited my answer to clarify, you should be able to run your program in a terminal using a simple script – Mokubai Jun 14 '11 at 9:07
  • the wrapper script is just redundant – Lie Ryan Jun 14 '11 at 9:15
  • @LieRyan I simply was not sure if Linux would automatically open a terminal for a non-gui executable and hence put that in there to make sure... – Mokubai Jun 14 '11 at 9:16
  • well i changed the file extension to sh and worked – Leandro Jun 14 '11 at 9:17
  • @Mokubai you need to use a terminal application to do that. @Leandro this is because the window manager / file manager are configured to run shell script inside a terminal. in a way, such dependent behavior is not exactly the most appropriate way of doing things... – bubu Jun 14 '11 at 9:29

I think the root of your problem is that you don't really understand the distinction between a Terminal Emulator and a Shell and how Linux figure out how to start processes.

First, there is the "Terminal Emulator", in Gnome-based environment this is usually Gnome Terminal.

Then there is the "Shell", in Linux this is usually bash, although other shells are possible.

A "Shell" runs inside a "Terminal Emulator". This distinctions comes from the age of physical terminals, where a physical Terminal is the hardware that takes input, writes text in colors, etc and the Shell is a software that processes user command and manage other processes based on the given commands.

Nowadays, we have a general purpose screen that can display any images, so we no longer use a physical Terminal, but instead have "Terminal Emulators", a software that emulates the job of a physical terminals, and the Shell, which is still the same ole' shell as previously (well, modern shells does take advantage of being in a software terminal emulator such as not being limited by the physical limitation of a paper, etc but the divide remains).

A "Shell" does not always run inside a Terminal Emulator; there are also Graphical Shell, such as Nautilus (hint hint, Nautilus is the name of a marine creature with a big shell) or Windows Explorer (not to be confused with Internet Explorer).

In both a command line shell, e.g. bash, and a graphical shell, e.g. Nautilus, an executable is marked by having its execute bit set.

In a command line shell, you can use ls -l to view a file's permission bits, e.g. rwxrwxrwx means everyone can read/write/execute the program; rwxr-xr-- means the owner have full permission, people in the file's group can read and execute but not write, and other people can only read the file. In Nautilus, you can right click on a file > Properties > Permission tab. In the Permission properties page you can the file's permission similar to in the command line shell.

A file which has their execute bit set are treated as executable, and can be executed by doing ./filename (command line shell) or double clicking (graphical shell).

Last, there are a few other subtleties on how a shell executes a file. In most Linux shell, you can "execute" a script written in python/perl/php/bash that is not a compiled executable. Since these files are not natively compiled executable, they need an interpreter (e.g. python interpreter) to be executed. Unlike in Windows shell (Explorer), which figures out the interpreter to invoke through the file's extension; Linux shells figures out the correct interpreter by looking at the "hashbang" line that looks like this


when a file's execute bit is set and the file has this hashbang line, the shell will invoke the interpreter /usr/bin/python with the current file as the argument.

Nautilus can also recognize when a program is a command-line application, and will offer you to run the application inside a Terminal. When you double click an executable script, Nautilus will ask whether you want to run it in a Terminal, run without Terminal, or edit the file in a Text Editor.


make a script to execute it inside an xterm or something. Make sure your program does interact with the user before ending. (Does it work when you run it inside an xterm? Does it work when you run it inside a typical bash shell?)

xterm -e command [args1 args2]
  • Can you give me some more info on this please – Leandro Jun 14 '11 at 8:59
  • By the bash you mean the Terminal... sorry im not very familiar with bash I just used it once to color the promtp – Leandro Jun 14 '11 at 9:00
  • the command prompt you have, in text mode linux, is a shell. most commonly it is bash. in rare circumstances default shell may be tcsh or zsh as well but again this is rare. in X, you need a program to provide the window to contain the text, thus a terminal window is commonly a e.g. gnome terminal running bash. – bubu Jun 14 '11 at 9:07

In simple words:

  1. Your generated executable binary file may lack the executable bit. Unix based systems use this feature for security reasons. Set it with: chmod +x yourbinary.
  2. The binary may actually be executed, but since linux doesn't run a terminal emulator (which is somewhat like the interface between you and the stdout) to run it by default, you are not able to see anything.

For the latter case you can:

  1. Create an script that runs your executable via a terminal emulator, like:

    exo-open --launch TerminalEmulator -e 'yourbinary'

    To run it on your default terminal (if you have the exo command), or explicitly use one.

  2. Create a desktop file to run it.

  3. Give them a custom, special extension like .exec and configure them to run using the command on suggestion 1. (or similar) on your file extension settings (if your os supports that feature).


If you have compiled it on windows and it is an exe, I see no reason why a terminal should not open on windows when you double-click the executable. Are you sure that the code does not shut down (segfault etc.)? It would be a good idea to make sure that the program does not crash.

  • The one on Windows works perfectly is the one compiled on Linux where i can find a way to open it as if it were an windows .exe On its respectively O.S – Leandro Jun 14 '11 at 8:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.