Linux - DesktopThis forum is for the discussion of all Linux Software used in a desktop context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hi
I have Arch Linux and everything works fine
I have been googling around but i can't figure it out if .xinitrc should have executive rights. My .xinitrc works fine with executive rights or without but i am asking this "stupid" qustion just to be sure and to have a calm sleep
Ok, thank you both for answers. For test i have created a new user and the file in new user's home hasn't got executive permission. So i conclude that doesn't need them
But he Ubuntu page have somewhat confused :
Quote:
Now make your X session script executable. To do this, type the following command into your terminal:
The security contains also the way a script gets executed I think :
In bash any "exit" inside a "source"ed script can make the parent exit , too .
Sourced scripts need a "return" if needed to not kill the parent (xinit) .
I think I read somewhere it would be "canonical" to make such configuration files executable and put a "#!/bin/sh" on top to make it possible to either execute the script or to source it .
I've just had a quick look at .bashrc and that's not executable. The question is, how is the file going to be used? If it just contains information that some script is going to utilise, then it doesn't need to be executable; if it is a script, it does. In general, I think the suffix -rc shows that a file isn't a script. You can't judge by the contents; my .bashrc contains commands like "export EDITOR=nano".
If it just contains information that some script is going to utilise, then it doesn't need to be executable; if it is a script, it does.
By "script" you mean "executed directly by the OS, without explicitly specifying an interpreter"?
Because I always thought that even if you don't give it executable priveleges, and explicitly pass it to an interpreter, than it's still called a script.
It is interesting, because i have copied .xinitrc from the /etc/skel and at the beggining it has #!/bin/sh so i tgought that has to have executive permission.
.xinitrc from skel:
Quote:
#!/bin/sh
#
# ~/.xinitrc
#
# Executed by startx (run your window manager from here)
if [ -d /etc/X11/xinit/xinitrc.d ]; then
for f in /etc/X11/xinit/xinitrc.d/*; do
[ -x "$f" ] && . "$f"
done
unset f
fi
# exec gnome-session
# exec startkde
# exec startxfce4
# ...or the Window Manager of your choice
By "script" you mean "executed directly by the OS, without explicitly specifying an interpreter"?
By a script, I mean a simple program that runs with an interpreter, and that is a utility (or quick fix) rather than an application. Of course, the OS does not execute scripts; if you don't specify an interpreter, it passes them to your default shell interpreter.
By a script, I mean a simple program that runs with an interpreter, and that is a utility (or quick fix) rather than an application.
According to that definition of scripts, the idea that "scripts" need exe permissions and non-scripts don't is wrong.
Executable permissions are needed if the program is a true executable file or if the program is a script with a shebang line and is to be given directly to the OS as if it was an executable file, like this (using the exec system call):
Ehrm... xinitrc is your start-up file for X, as the name says x-init-rc...
But, where does that question come from? And...(more importantly) where do you want to get with that question? It is an init file, something else reads it. Arch uses (or better: the X) it to start up the DE (Gnome, XFCE,...), it is started at startx, in turn nudged by whatever is in inittab, mine is set to init3 - the inittab, however has a last line that starts (and sets it to respawn) the XDM for login. As this goes into "graphical" mode - the subsequent startx makes the info in xinitrc relevant, it gets read out and used to go into the required session, it says "exec gnome-session"
In short, xinitrc is read (not executed - so only read rights are needed, for the processes that need this info) by the X11 server, that gets started up by a line in inittab where a graphical login is requested.
Any X-troubles by the way???
Thor
Last edited by ButterflyMelissa; 07-02-2011 at 01:29 PM.
Hi Thor. It is just a question out of curiousity. I have copied my file from /etc/skel. As you can see above skeleton file has #!/bin/sh so that is why i automatically thought of the need for execution permission.
Beside this i am not experiencing any problem with X.
In short, xinitrc is read (not executed - so only read rights are needed, for the processes that need this info)
I doubt that startx itself reads .xinitrc directly. It's impossible to know if it's read or executed without looking at the startx source code, to see if it's executing .xinitrc or starting a shell instance and passing .xinitrc as an argument to it. Since it works without a shebang line, I bet that the latter is true (and thus executable permissions are not needed).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.