When poking around in some source code trees, sometimes I encounter files with extension "*.in", typically for non-compiled files that belong somewhere under /etc or /usr/share.

For example, in openwsman source code, I can see file:


which by content corresponds to


when deployed from RPM (RHEL7), save for some variable references.

I assume files like this are used in building process to finally appear in the mentioned path. But why are they named originalname.in instead of originalname? What usually happens with files like this before they land?

How are such files called? Can anybody point me to the right documents?

Note that Openwsman also has etc/owsmangencert.sh.cmake, which is similar case.

  • Those are input for pkgconfig.
    – devnull
    Apr 4, 2014 at 18:20
  • 1
    .in just stands for input, as in input files. A common place to find them in the context of autotools - autoconf, automake, libtool. See for example en.wikipedia.org/wiki/GNU_build_system. These files, at least in the autotools setting, are typically templates of some kind that are transformed by some procedure to produce a final version of the file. Apr 4, 2014 at 18:24
  • They're just templated/parameterized versions of a file that will get generated during compilation/build time.
    – slm
    Apr 4, 2014 at 20:57

3 Answers 3


As far as I know, there is no single program that is meant to use use .in files, but using the suffix .in does hint at the fact that it's not the final file. Instead, the .in file will serve as a kind of template or input to generate the file with the same name but without the .in suffix.

In the case of openwsman, an example you'll often find in packages that you can compile from source, is the configure.in file. This is processed by autoconf/automake and results in a file called configure. This new version is an actual shell script that you can execute on the command line.

In turn, the configure script itself can also process certain .in files. As an example, take the file called openwsman.pc.in. There, you'll see lines like

Version: @VERSION@

The thing between the @ symbols is a variable used by the configure script. In the resulting openwsman.pc.in` the value of this variable will be filled in, for example:

Version: 2.4.5

This @(variablename)@ syntax is also recognized by the CMake build system. So running CMake will also transform the openwsman.pc.in file to openwsman.pc. It does this because of the following line in the CMakeLists.txt file:

configure_file(${CMAKE_CURRENT_SOURCE_DIR}/openwsman.pc.in ${CMAKE_CURRENT_BINARY_DIR}/openwsman.pc)

The etc/owsmangencert.sh.cmake is transformed in the same way, but based on the extension I would assume that only the CMake build system does this and not the configure script. In this case, the relevant line is found in the etc/CMakeLists.txt file:

configure_file(${CMAKE_CURRENT_SOURCE_DIR}/owsmangencert.sh.cmake ${CMAKE_CURRENT_BINARY_DIR}/owsmangencert.sh)

So in conclusion, there's no one single piece of documentation that explains this, but it's often used in build scripts like configure scripts or CMakeLists.txt files from CMake.


There files are templates, take look inside owsmangencert.sh.in


@SYSCONFDIR@ will be replaced actual path

After automake's configure, will be config.status generated, which will replace tokens with actual values, during make process. So thats automake templates. For deeper knowledge.

  • @brm explained that better
    – MolbOrg
    Apr 4, 2014 at 18:32

the only *.in files I have come across are config.in for specifying .configure steps with autoconf and automake.

In this sense the *.in is a variables file. It keeps your script clean of variables, so you can have edit access to a variables file and run access on the script but not edit access on the script.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .