I decided to follow a UNIX tutorial just to understand my Kubuntu a little bit more, in the tutorial's eighth chapter, I am advised to
WARNING: NEVER put commands that run graphical displays (e.g. a web browser) in your .cshrc or .login file.
I immediately searched for information about why shouldn't I ever do this, however, I didn't find anything about it.
Can anybody tell me what is the problem with running graphical displays in my .cshrc
or .login
files?
By default in Kubuntu, that tutorial's advice about those specific files is not all that relevant, because your default shell--the shell you get when you (a) log in or (b) open a Konsole window or other terminal emulator--isn't a
csh
implementation likebsd-csh
ortcsh
. It is insteadbash
, a Bourne-style shell. You can, of course, still use a shell liketcsh
, though you'll have to install it first--Ubuntu and its official derivatives such as Kubuntu don't even ship with such a shell installed, though they are included in the official repositories. If you put commands in.cshrc
or.login
, you should not actually expect them to run in your Kubuntu system. You could probably configure KDE to do so. But merely switching your login shell would not achieve this--logging in from a graphical display manager doesn't typically cause a shell liketcsh
to run or C Shell configuration files to be read.So in your situation--and that of the vast majority of Ubuntu users--there is an extra reason to avoid putting commands that run graphical programs in those files. They won't run when you want them to. However, the file called
.profile
in your home directory is run by Bourne-style shells likebash
when they are started as login shells, and those commands are also, albeit mostly by tradition, run in most graphical desktop environments when you log in. And the advice in that tutorial scales to.profile
and any other files that aren't specifically meant to contain commands that run in a graphical session that has already been started. It is as glenn jackman says. They will run when you don't want them to. The problem even goes a bit deeper than that.First, the basics: If you put commands that run graphical programs into confiiguration files that run for all login shells, attempts to run the programs will usually be made when you log in, even if you're logging in using a method where they cannot run. If you put the commands in a configuration file that runs every time you run your shell, even when it's not running as a login shell--for
bash
,.bashrc
is such a file--then they'll run whenever you open a new shell. Imagine Firefox running, again and again, every time you opened a Konsole tab, and also giving you errors every time you log in on a virtual console or by SSH or when you simulate a login withsudo -i your-username
orsu - your-username
.The deeper issue is this: If a graphical session is configured to run commands from a file in order to initialize your desktop session, and those commands attempt to run graphical programs before the other things are set up so they work right, you can get unexpected results. If they run early enough you get the same problem as if it's not a graphical session at all. A little later, and the programs might start before UI elements like your panels start, which would be confusing, and might produce incorrect behavior even after everything starts up.
Recent versions of Kubuntu use KDE Plasma Workspaces. If you have graphical programs you want to run every time you log in graphically on your Kubuntu system, you can go to Startup and Shutdown → Autostart and add them. That's how I recommend you do it. Or you can manually place a
.desktop
file, symbolic link, or shell script1 in~/.config/autostart
(where~
stands for your home directory), which is the default autostart folder location. Copying over such a.desktop
file is what the graphical Autostart tool does, though, so most of the time you would not be gaining anything by "doing it yourself." See also the KDE documentation.1 Or any other executable, but those are the most common. You should not usually copy a program into this directory. One reason not to is that, when the program is updated, you'll still be running the old binary (possibly in combination with supporting files particular to newer versions).