Linux for Windows systems administrators

Understand how to execute applications that run on Linux

Run Linux apps from both the command line and the desktop

Content series:

This content is part # of # in the series: Linux for Windows systems administrators

Stay tuned for additional content in this series.

This content is part of the series:Linux for Windows systems administrators

Stay tuned for additional content in this series.


To get the most from this article, you should have experience working with desktop applications in a Windows environment. I assume readers have a basic understanding of how to use the Linux desktop. It's beneficial to have a working Linux computer to explore the concepts and examples in this article.


Sometimes running an application on Linux for the first time requires a little extra work. Some applications such as server services might not be installed as services, so you need to start those applications from the command line. For the user accounts that start the applications, set the execute permission flag (x)on the application files.

Running user-space applications

Linux runs processes in kernel space or user space. User space is the area of the operating system where applications typically run. Simply put, each user account has its own user space, and applications work within that realm.

Only the root user has access to kernel space by default. The root user is the superuser in Linux, comparable to the administrator account in Windows. Running an application under the root user account can pose a security risk and is not advisable.

Many server services need root permission to start the service. However, after the service is started, the root typically hands it off to a service account. Service accounts in Linux are technically standard user accounts. The primary difference is that service accounts are used only for running a service and aren't intended for anyone to actually log in with them.

Setting the permissions

You can set the execute permissions on a file with the chmod command. The umask setting in Linux typically prevents a downloaded file from being executable, for good reason too because it can help maintain the security of your Linux computer.

Most Linux distributions have a umask setting of 022, which means by default a new file has permission settings of 644. The numeric representation of permissions take the form of read (4), write (2), and execute (1). So an application download with the default permission of 644 means the file owner has read and write permission, while the group owner and other have read-only permission.

For example, to give everyone execute permission on a file, use the chmod a+x command. The a represents all, the plus sign (+) represents add, and x means execute. Likewise, if the application is a server service, you should ensure only authorized accounts have access to execute the service.

If an application is capable of running under standard user account permissions but only those in a particular group need access to use it, you can set the group owner permission to executable and add the users to a group.

Getting even more specific, you can also set access control list (ACL) permissions on an executable file to allow a particular user or group the permission to run the application. Use the setfacl utility to set ACL permissions.

For those applications, such as server services, that need to start the process as root user, you have a few options. Table 1 summarizes various options that allow users to execute server services that require root privileges.

Table 1. Options to run applications that require root privileges
As root userNot recommended for server services. Acceptable for applications when users already know the root password and the compromise of the application is not a primary concern.
SetUIDNot recommended due to security issues. SetUID allows a standard user to execute a file as another user, such as root.
sudoCommonly used and considered a good practice. sudo grants a user or member of a group permission to execute a file that would otherwise require root privileges. The user does not need to know the root password.
Standard user account with file permissionsSet execute permission on a file for the user owner, group owner, or other (everyone). This is a common way to grant users who do not require root privileges permission to execute an application.
Standard user account with ACL permissionsLess commonly used, but a viable solution when you don't want to grant a user sudo access or change the permissions of a file. Using the setfacl command on a file, you can grant a particular user or group of users the right to execute the file.

Running from the command line

Running an application from the command line is an essential task when managing Linux servers. A lot of applications have shell scripts—similar to Windows batch files (.bat)—that start the applications and perform other tasks such as setting variables and assigning processes to other users. For example, an application may need a Java™ Virtual Machine (JVM) to execute. In that case, shell scripts can set the appropriate environment variables and then execute the Java command to run the Java Archive (JAR) or class file. This holds true for applications using Perl, Python, and even C#. (Yes, C# compiled applications can run on Linux!)

You can execute a command from the command line or shell prompt with just the file name if the command is a part of the shell’s built in commands, or if the command’s directory location is included in the PATH variable. Commands such as "ls" and "cd" are examples of commands that are generally included in the PATH by default as they typically reside in the /usr/local/bin or /usr/bin directories. But if the file location is not set in the PATH, you must include the pathname to the file. For example, if the executable myapp resides in the /usr/share/scripts directory, type /usr/share/scripts/myapp to execute the script. You can also use the relative path by adding the dot (.) and slash (/) before the file name and type ./myapp. The dot (.) in the shell specifies the "current directory." (Windows includes the working directory on the execution path and some system administrators have been known to include the dot (.) in the PATH to emulate this, but this is not advisable for security reasons.) Likewise, you can precede the file name with the language environment such as:

  • sh
  • php
  • python
  • perl
  • java

More often though, packaged applications have shell scripts that set the environment variables and provide the runtime executable path of the language with the #! symbol, such as #!/usr/bin/python. You should become familiar with this approach as well.

Listing 1 uses the default script to start the Apache Tomcat application server using the ./ approach. Then it starts the server using the sh approach. Since the default port is 8080, no special modifications are required to start the service as a standard user.

Listing 1. Executing an application from the command line
$ ./ start 
Using CATALINA_BASE:   /opt/apache-tomcat-7.0.26
Using CATALINA_HOME:   /opt/apache-tomcat-7.0.26
Using CATALINA_TMPDIR: /opt/apache-tomcat-7.0.26/temp
Using JRE_HOME:        /usr
Using CLASSPATH:   /opt/apache-tomcat-7.0.26/bin/bootstrap.jar:
$ ./ stop

$ sh start 

Using CATALINA_BASE:   /opt/apache-tomcat-7.0.26
Using CATALINA_HOME:   /opt/apache-tomcat-7.0.26
Using CATALINA_TMPDIR: /opt/apache-tomcat-7.0.26/temp
Using JRE_HOME:        /usr
Using CLASSPATH:   /opt/apache-tomcat-7.0.26/bin/bootstrap.jar:

Consider starting a typical Hypertext Transfer Protocol (HTTP) web server. In Linux, any port less than port 1024 is considered a privileged port, and only root can open privileged ports. Because web servers by default run on port 80, root needs to start the process. As noted, however, it is considered insecure to run a service as the root user. The correct procedure is to start the service as root and then hand it off to a standard user or service account.

Fortunately, a lot of server services have the scripts in place to do just that. If you build the Apache web server from source, you find it starts as root and then hands off the httpd threads to the apache user.

Listing 2 starts a default compilation of the Apache 2 web server. The install process does a few things, including making the apachectl command executable. Because this process requires use of port 80, it starts with root user privileges. However, the ps command reveals the httpd processes are running under the apache user account.

Listing 2. Starting the Apache web server
# cd /usr/local/apache2/bin
# apachectl start
#ps aux | grep httpd
apache   23094  0.0  0.3  11784  1912 ?        S    10:41   0:00 /usr/sbin/httpd -k start
apache   23095  0.0  0.3  11784  1912 ?        S    10:41   0:00 /usr/sbin/httpd -k start
apache   23096  0.0  0.3  11784  1912 ?        S    10:41   0:00 /usr/sbin/httpd -k start
apache   23097  0.0  0.3  11784  1912 ?        S    10:41   0:00 /usr/sbin/httpd -k start
apache   23098  0.0  0.3  11784  1912 ?        S    10:41   0:00 /usr/sbin/httpd -k start

Running applications in the background

Some installed software might not be as user friendly as the Apache web server. Unless you are troubleshooting or otherwise want to see exactly what is going on with an application, you probably want to run it in the background after the process starts. If you don't, the application terminates when the shell is closed. When running server services, it's not desired behavior for the service to stop every time you close the terminal shell or otherwise log out!

If you run an application in the background, it continues to work even if you close the shell window. You can start an application in the background by appending an ampersand (&) at the end of the execute command. For example, you can open a file with the vi editor and run it in the background with the vi /etc/sysconfig/network & command because & opens the /etc/sysconfig/network file and keeps it in the background. You can use the nohup utility to allow the process to continue even after you logout. For example, nohup vi /etc/sysconfig/network &.

Listing 3 opens a file for editing in the Vim editor and places it in the background.

Listing 3. Running an application in the background
# vi /etc/sysconfig/network &
[1] 24940
# jobs
[1]+  Stopped   vi /etc/sysconfig/network

You can type the jobs command to see all the applications you have running in the background. Each job running in the background is assigned a sequential number, starting at 1. The job in Listing 3 is job number 1. 24940 is the process ID (PID). You can bring an application to the foreground with the fg command and the specific job number. In this example, the process is not in use by the user, so it displays as Stopped. However, the command fg 1 opens the terminal back to the active process of editing the file.

Running applications from the desktop

Running graphical user interface (GUI) applications from the desktop in Linux isn't much different from doing so in Windows. Mostly, you need to understand how applications are grouped in menus in your particular desktop environment. Linux has an abundance of desktop applications available for various tasks. Some are native to Linux, while others might be cross-platform applications developed with C# using a common runtime environment, just like .NET Framework applications. You might find that you can even run your favorite Windows application on Linux using a virtual environment such as Wine.

Native Linux applications

It's quite possible you'll find an alternative Linux application for your favorite Windows-based application. Running native Linux applications on the desktop is straightforward. Similar to Windows, you typically find these applications organized in menus, and you simply click and run as you would a Windows application.

For those applications that require root privileges, you are prompted to enter the root password before proceeding. This is similar in concept to the Run as Administrator option in Windows. Otherwise, all applications you run are in the user space of the account you are logged in to.

In Windows, you can create desktop shortcuts. Linux has similar shortcuts called launchers that you can place on the panel or desktop. When you click the launcher, it executes the program.

Figure 1 displays two launchers for the Mozilla Firefox web browser on the GNOME Desktop. One launcher is located on the panel, and the other is on the desktop.

Figure 1. Viewing launchers on the desktop and panel
Screen capture of icons for Computer, Firefox and tbosts home
Screen capture of icons for Computer, Firefox and tbosts home


Many Windows applications are developed using the .NET Framework. Mono is an open source implementation of .NET that runs on many platforms, including Linux. In fact, the Mono website describes it as an implementation of C# and the Common Language Runtime (CLR) that is binary compatible with .NET. The project is currently supported by Xamarin.

On Linux, you execute applications developed with the .NET framework (or Mono) the same as you do on Windows. However, remember the Linux umask and default file permissions. You still need to provide execute permissions to the file so Linux will allow the executable to perform.

Some cross-platform applications developed in Mono that you can install on your Linux GNOME desktop, such as F-Spot, reside on the menu with the native GNOME applications. F-Spot is an open source application for managing photos. Even though it is a C# application, it appears as a native application on the GNOME desktop. After you create a launcher for an application, you can click and run just like in Windows.

Figure 2 demonstrates the location of the Mono-based application, F-Spot, and how you can create desktop or panel launchers for it.

Figure 2. Creating a launcher for F-Spot
Screen capture of how to open the menu to create a launcher
Screen capture of how to open the menu to create a launcher


Wine lets you run Windows software on Linux and other operating systems. With Wine, you can install and run those applications just like you do in Windows. Wine is still under active development, and not all Windows programs work with Wine. If your application is compiled for a Windows operating system and you find it can run adequately using Wine, chances are it is a desktop application as opposed to a server application. Be sure to check the Wine documentation about the possibility of running the application on Linux because Wine doesn't fully support all applications.

When you use Wine with Linux, you have a hidden folder in your account home directory that emulates a Windows environment, as in Listing 4.

Listing 4. Wine's hidden folder that emulates a Windows environment
$ cd /home/tbost/.wine/drive_c/windows

After you install an application using Wine, you can typically find it on the desktop menu and run it the same way you would in Windows.

For example, Camstudio is an open source tool for recording and managing screen videos. Currently, there isn't a release for the Linux operating system. However, using Wine, I installed the Windows version on a Linux desktop. Wine-related applications are typically grouped under Applications > Wine > Programs, as in Figure 3.

Figure 3. Running a Windows application on Linux using Wine
Screen capture of running a Windows application on Linux using Wine
Screen capture of running a Windows application on Linux using Wine


While managing a Linux server, you are sure to encounter software that executes from the desktop and the command line. When you understand how to set the appropriate permissions and user accounts, you can securely run those applications. With long-running processes such as server services, you can execute from the command line and appropriately set in the background. If you have applications that are geared for running from the desktop, you can do that too—sometimes even Windows applications!

Downloadable resources

Related topics

Zone=Linux, Open source
ArticleTitle=Linux for Windows systems administrators: Understand how to execute applications that run on Linux