Bug 69439 - Empty lines before #!/bin/sh in startx
Summary: Empty lines before #!/bin/sh in startx
Alias: None
Product: xorg
Classification: Unclassified
Component: App/xinit (show other bugs)
Version: git
Hardware: All All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
Depends on:
Reported: 2013-09-16 21:08 UTC by Leonid Isaev
Modified: 2018-07-25 17:59 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Description Leonid Isaev 2013-09-16 21:08:45 UTC
Since xinit 1.3.3 (but the problem is also present in git), the startx shell script contains lots of empty lines before the shebang. This confuses bash making it start additional login shell ('-bash' in ps(1))... Please remove them if possible.

Comment 1 Alan Coopersmith 2013-09-16 21:30:24 UTC
The shebang is the first line in the source file, and in the output when I
run it here.   Perhaps you're using a cpp that's inserting extra blank lines?

Comment 2 Leonid Isaev 2013-09-16 22:33:21 UTC
To add to my previous post (sorry for forgetting this), the system is archlinux x86_64 with gcc 4.8.1.
Comment 3 Leonid Isaev 2013-09-16 22:36:41 UTC
(In reply to comment #1)
> The shebang is the first line in the source file, and in the output when I
> run it here.   Perhaps you're using a cpp that's inserting extra blank lines?
> http://cgit.freedesktop.org/xorg/app/xinit/tree/startx.cpp

I see. Then it's an issue on the distro side -- I'll look closer at the cpp behavior.

Comment 4 Alan Coopersmith 2013-09-16 22:48:15 UTC
I tested with Solaris cpp & gcc 4.7.3 on Solaris, so it could be a change
between gcc 4.7 & 4.8.
Comment 5 Jan de Groot 2013-11-12 10:06:49 UTC
This also affects xmkmf and makedepend from imake. These projects use cpp to parse cpp files to shellscript.

Looking at the makefiles, this line is used to generate xmkmf:
/usr/bin/cpp -undef -traditional -DCONFIGDIRSPEC='"-I/usr/lib/X11/config"' < ./xmkmf.cpp | /usr/bin/sed -e /^\#/d | /usr/bin/sed -e s/XCOMM/\#/ > xmkmf

Changing it to:
/usr/bin/cpp -undef -traditional -DCONFIGDIRSPEC='"-I/usr/lib/X11/config"'  ./xmkmf.cpp | /usr/bin/sed -e /^\#/d | /usr/bin/sed -e s/XCOMM/\#/ > xmkmf

leads to desired behavior. When cpp 4.8.x reads from stdin, it adds this on top:
# 1 "<stdin>"
# 1 "<command-line>"

# 1 "/usr/include/stdc-predef.h" 1 3 4

# 17 "/usr/include/stdc-predef.h" 3 4
[lots of newlines]
# 1 "<command-line>" 2
# 1 "<stdin>"

Changing it to read from file changes it:
# 1 "./xmkmf.cpp"
# 1 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "<command-line>" 2
# 1 "./xmkmf.cpp"
Comment 6 Alan Coopersmith 2013-11-23 07:07:18 UTC
Submitted patch to xorg-devel for review:

Please test to ensure this works for you too.
Comment 7 Alan Coopersmith 2013-12-06 23:23:24 UTC
Fix pushed to git master:
Comment 8 Alan Coopersmith 2015-07-07 06:46:28 UTC
Fix published in xinit 1.3.4:
Comment 9 Adam Williamson 2018-07-25 17:59:13 UTC
FWIW, I just sort of ran into an odd offshoot of this:


it seems that no-one on this bug or the review threads etc. talked about *why* this change 'fixed' the bug. From some research in #107368 , it seems to me that what's going on is, when passed input via stdin and without any -x parameter, cpp will assume it's C. When passed input as a file with a .cpp extension, cpp assumes it's C++.

For some reason, when it's treating these files as C or assembler, cpp (perhaps only cpp in gcc 4.8+, which is why this suddenly appeared?) adds a bunch of blank lines at the top. When it's treating them as C++, it doesn't.

You can play around with this for yourself by deleting 'startx', running 'make -n' to get the full cpp command that 'make' would run, then renaming the files and modifying the command. For instance, if I leave the input file as 'startx.cpp' but add '-xc' or '-xassembler' to the cpp command (which overrides the file extension-based language detection and just *tells* cpp to treat the file as C or assembler), I get the blank lines. And if I rename the input file to 'startx.foo' but add '-xc++' to the cpp command, I get the file without the blank lines.

So it seems like the 'fix' here was really a sort of slightly odd workaround, and it'd be interesting to figure out why cpp in 4.8 adds these blank lines when treating the code as C whereas cpp in 4.7 perhaps didn't.

I ran across this because the fact that the '.cpp' extension makes cpp treat these files as C++ effectively makes the build depend on gcc-c++, even though there's no C++ code in it at all...

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.