An xinitrc failure on boot-up

Problem:
This involves .xinitrc. We like to have two terminal Windows created and opened during our boot. Been doing that since version 6.2. This occurred in RC2 -but- went away by a strange ‘fix’. We have a Triple boot system and prior to this day, 11.4 was our main system. We booted up into it by accident and immediately exited and re-booted into 12.2 RC2. The xterms appeared -and- in the correct size -and- positions. We can not duplicate this ‘fix’ cause we replaced the 11.4 with this new 12.2.

During Start-up we will see the xterms flash on the screen in the correct positions and sizes. This happens just before the march of the devices. First one being a Hard Disk -and- for the life of me can’t remember what the others are!! Anyway, that is not important. What is … is that when the Desktop finally appears… both xterm windows are plastered against the top of the screen and about 9 lines to short. Looks like they have take on the ‘Failsafe’ values.

We can close out both windows and click on the .xinitrc inside of a Dolphin widow and the terminal windows will get created in the correct positions and the correct sizes. -But- this same code fails to produce the correct result during boot-up.

Anyone have any ideas as to what might be the cause for this .xinitrc problem??? We are using the supplied .xintrc template as a base to create our .xinitrc and only adding the following lines: (in the spot where it says ‘Add your own lines here…’)

xterm -geometry 100x35+385+180
-fg Black -bg NavajoWhite -sb
-rightbar
-title NavajoWhite
-fn 8x13 &

xterm -geometry 100x35+165+390
-sb
-rightbar
-title For_coding
-fn 8x13 &

Take care and thanks in advance for any and all help or suggestions,
Chuck

Are you trying to do this for a user, or system-wide? If the former, do the above commands represent the entirety of your ~/.xinitrc? You’re supposed to incorporate your commands within your custom xinitrc as per the ~/.xinitrc.template

Alternatively, just create an executable script within your ‘Autostart’ directory

For example, with KDE, I tested with

#!/bin/bash
xterm -geometry 100x35+385+180 \
-fg Black -bg NavajoWhite -sb \
-rightbar \
-title NavajoWhite \
-fn 8x13 &

xterm -geometry 100x35+165+390 \
-sb \
-rightbar \
-title For_coding \
-fn 8x13 &

and the x-terms open as expected on login.

You may need to clarify further…

First thing to do is to just run this script (in another terminal) and see how the xterm windows look like.

Yes but it’s not that easy with KDE. You might have to exclude xterm from the session, so that it doesn’t get both autostarted and restarded if you don’t want to end up with 20 xterm windows.

You should use this in the .desktop file (if you create one) to prevent the script to be restarted by the session manager:

X-KDE-autostart-phase=2

However - at least last time I tried - it will only work in the file is placed in ~/kde4/Autostart but not in ~/.config/autostart.

A little bit out of topic …
What’s bothers me with autostarted xterm under KDE is that no matter where you merge the system wide or user Xresource (as you would normally do from xinitrc or an Xsession script), the settings won’t apply to terminal windows restarted by the session manager (chances are that they’ll get restarted after all). This include colors, size, bitmap fonts, etc. I should say that I understand why the OP passes the resources as command line arguments to xterm. KDE must reset the Xresource somewhere to an absolutely ugly default. I’ve tried to solve this issue in quite many ways - don’t remember all details. I ended up merging my system wide Xresource one more time in autostart, and it works for any xterm (whether autostarted or not) … except those restarted by the session manager.

Generally speaking, autostarting anything in KDE which needs either Xresource (such as xterm terminals) or compositing (such as conky for transparency) is just no fun at all.

OP, if you put something in autostart, also make sure it gets started after the plasma desktop:

X-KDE-autostart-after=plasma-desktop

It might help.

Hopefully, that all means more to the OP than it does to me. :slight_smile: All I know is that two x-terms opened up for me, and I’m not sure how various scenarios with X-sessions might affect this behaviour.

@chucktr: Clarify/discuss a little further and I’m sure @please_try_again will lead you to the required outcome.

BTW, (for my own interest), are there any advantages with using x-term over KDE’s native konsole? (I like the fact that one instance of konsole can have multiple tabs if/as required.)

If you’re already in KDE, probably not. konsole is a KDE application which uses and requires dbus. To the outside world, it presents itself as “xterm”. You can set the TERM variable to something else if needed.

This is what I use to allow (most) terminal applications to use 256 colors, based on the value of TERM:


    if  "$TERM" != "rxvt" ] ; then
               case $COLORTERM in
                       Terminal) export TERM=xterm-256color ;;         # this is XFCE Terminal
                       gnome-terminal) export TERM=xterm-256color ;;   # this is gnome-terminal
                       wterm-xpm) export TERM=xterm ;;                 # this is wterm
                       Eterm) export TERM=Eterm ;;                     # this is Eterm
                       1) export TERM=xterm-256color ;;                # this is lxterminal, **konsole**, yakuake, uxterm, Mac OSX terminal, putty ...
               esac
     fi

Here’s konsole Changelog: Konsole Terminal - Changelog

OP, what’s the ouput of

$ resize

in your xterm windows?

Would not simply saving session with 2 open xterms as default session work? That is what I did in the past when using KDE. Does not require editing any file at all.

Yes, it would reopen the xterm, but it won’t apply the Xresource to the reopened xterm. I could never figure out how to do this (and I don’t give up easily). If you know a solution, I’m interested. I guess I’ll post a screenshot, so that you guys can see what I mean:

I log in in KDE and open an xterm. It looks like this.

http://desmond.imageshack.us/Himg546/scaled.php?server=546&filename=xtermbefore.png&res=crop](http://img546.imageshack.us/img546/4752/xtermbefore.png)

The session manager is set up to restore the previous session - which is the default.

I log out, without closing the xterm and re-log in. xterm gets restarted … but this time looks like this:

http://desmond.imageshack.us/Himg217/scaled.php?server=217&filename=xtermafter.png&res=crop](http://img217.imageshack.us/img217/7385/xtermafter.png)

As you can see the font size is smaller in my case, but it could be larger too and then, you would have less line of text, just like the OP in this thread.
The problem is that:

  • xterm uses Xresource (you wouldn’t have this problem witch konsole, gnome-terminal or xfce-terminal)
  • kde overwrites the Xresource merged before it starts (in xinitrc or Xsession)
  • if you merge the Xresource after kde start, it doesn’t help because the applications get restarted before this happens.
  • KDE actually lacks an option:
X-KDE-autostart-phase=0

OK, I did use konsole being under KDE. Thank you for detailed explanation.

Wow…:open_mouth: thought that we had put in enough info -but- some of you are like us… don’t read everything or have another way of interpreting what we said.:shame: Anywho, we will try to clarify the first posting: (thishas created and interesting discussion.):stuck_out_tongue:

Problem:
This involves .xinitrc. We like to have two terminal Windows created and opened during our boot. Been doing that since version 6.2. Please notice that we are stating that we have done this same thing ever since SuSE 6.2. What?? Including two -or- more terminal windows in our .xinitrc. We used to do a lot of work in text/command line mode.

This occurred in RC2 -but- went away by a strange ‘fix’. Please notice that we are including RC2… it happened there -BUT- as stated we had a strange fix so we ignored it for the time. What strange fix?? We have a Triple boot system and prior to this day, openSuse 11.4 was our main system. We booted up into it by accident How?? It was our Main System and it was the default and we weren’t paying attention at boot time and let it slip thru to 11.4 instead of 12.2 RC2. and immediately exited and re-booted into * 12.2 RC2*.

Please notice the strange 'fix’. This was AFTER the ‘accidental’ attempted boot into openSuSE 11.4. The xterms appeared -and- in the correct size -and- positions. We can not duplicate this ‘fix’ cause we replaced the 11.4 with this new 12.2.

During Start-up This ‘during’ is AFTER the new Grub2 fancy selection screen. *(Which, IF any developers are reading this, we would like to praise and thank you for. It found and used -for the first time since we have been using this- the correct multi-boot partitions. We DID NOT -for the first time- have to edit the Partitions after the Install. Thanks.) *
we will see the xterms flash on the screen in the correct positions and sizes.
Please notice when this happens -and- notice that they are the correct size and in the correct position on the screen.
This happens just before the march of the devices. First one being a Hard Disk -and- for the life of me can’t remember what the others are!! Anyway, that is not important.

What is … is that when the Desktop finally appears.… both xterm windows are plastered against the top of the screen and about 11 lines to short. Looks like they have take on the ‘Failsafe’ values. Please notice in the code below that we have specified 35 lines -and- these two terms that appear are only 24 and their tops are at the top of the screen. They appear to be correct in width and Horizontal position -but- NOT the vertical position NOR the height.

We can close out both windows Please notice this… we understand that we can create a script and execute it AFTER the logon -but- that is NOT how it is supposed to work. Hasn’t for over 10 years… or more. -And- as a matter of fact with have some functions and aliases that do open other terminals in various colors.

and click on the .xinitrc inside of a Dolphin widow and the terminal windows will get created in the correct positions and the correct sizes. -But- this same code fails to produce the correct result during boot-up.

Anyone have any ideas as to what might be the cause for this .xinitrc problem??? Please notice that we have stated that we are using the supplied template. We “used to” just copy our old one over. -BUT- with this version it did not work -and- now we are finding the “correct” one doesn’t work either. We are using the supplied .xintrc template as a base to create our *** .xinitrc*** and only adding the following lines: (in the spot where it says ‘Add your own lines here…’)

xterm -geometry 100x35+385+180
-fg Black -bg NavajoWhite -sb
-rightbar
-title NavajoWhite
-fn 8x13 &

xterm -geometry 100x35+165+390
-sb
-rightbar
-title For_coding
-fn 8x13 &

Ok. Hope this clarifies it all. We are also investigating it. Seems to be somehow “failing” and using part of the ‘Failsafe’ values. IF one of you would like to try — edit the xinitrc.template and copy/paste the above terminal values in it and save it as your .xinitrc. Then restart your system and see what happens. The details of my system are listed in the signature below.

Thanks and have fun,:slight_smile:
Chuck

I unterstand that you wanted to show us that we didn’t read your first post carefully enough … but the use of colors just makes this one unreadable.

Our apologies to all. Got a little upset… more with ourselves than anyone else… cause we couldn’t get across just what the problem was/still is. Went off and pouted and played with Android on our cell phone. We learned (and in case anyone reading this didn’t know) that Android is really Linux underneath. So, we learned how to ‘root’ our phone.

Now back to the Problem… if we may:
As stated in the beginning, this involves .xinitrc. We like to have two terminal Windows created and opened during our boot. Been doing that since version 6.2. Please notice that we are stating that we have done this same thing ever since SuSE 6.2. (Also in UNIX) What?? Including two -or- more terminal windows in our .xinitrc. We used to do a lot of work in text/command line mode. To keep track of things we used different colored backgrounds on the teminals.

This “problem” occurred in RC2 -but- went away by a “strange fix”. Please notice that we are including RC2… it happened there -BUT- as stated… we had a “strange fix” so we ignored it for the time. What strange fix?? We have a Triple boot system (Windows, Current Stable SuSE, and the latest developement SuSE) and prior to this day, openSuse 11.4 was our main system. We booted up into it by accident How?? It was our Main System and it was the default and we weren’t paying attention at boot time and let it slip thru to 11.4 instead of 12.2 RC2. We immediately exited the 11.4 and re-booted into * 12.2 RC2*.
AFTER re-booting into RC2 the terminals appeared in the correct location -and- the correct size. So, since the “problem went away” we just ignored it as a possible fluke and figured that it would be correct in the Released Version. Unfortunately, it was not.

Please notice the strange 'fix’. This was AFTER the ‘accidental’ attempt to boot into openSuSE 11.4. The xterms appeared -and- in the correct size -and- positions. We can not duplicate this ‘fix’ cause we replaced the 11.4 with this new 12.2.

During Start-up AFTER the new Grub2 fancy selection screen we will see the xterms flash on the screen in the correct positions and sizes.
Please notice when this happens -and- notice that they are the correct size and in the correct position on the screen. This happens just before the march of the devices. First one being a Hard Disk, second the Tools -and- for the life of me can’t remember what the others are!! Anyway, that is not important.

What is important … is that when the Desktop finally appears.… both xterm windows are plastered against the top of the screen and about 11 lines to short. Looks like they have take on the ‘Failsafe’ values. Please notice in the code below that we have specified 35 lines -and- these two terms that appear are only 24 and their tops are at the top of the screen. They appear to be correct in width and in the correct Horizontal position -but- NOT the vertical position NOR the height (wrong number of rows).

We understand that we can create a script and execute it AFTER the logon -but- that is NOT how it is supposed to work. Hasn’t for over 10 years… or more. IF this is NOT the way the system works anymore … could someone please tell us what changed.

Now we can close out both of the INCORRECT windows… and click on the .xinitrc inside of a Dolphin widow, get a warning about the window manager already running… -but- the terminal windows will get created and in the correct positions and the correct sizes. -But- this same code fails to produce the correct result during boot-up.

We are using the supplied template. We “used to” just copy our old one over. -BUT- with this version it did not work -and- now we are finding the “correct” one doesn’t work either. We are using the supplied .xintrc template as a base to create our *** .xinitrc*** and only adding the following lines: (in the spot where it says ‘Add your own lines here…’)

xterm -geometry 100x35+385+180
-fg Black -bg NavajoWhite -sb
-rightbar
-title NavajoWhite
-fn 8x13 &

xterm -geometry 100x35+165+390
-sb
-rightbar
-title For_coding
-fn 8x13 &

Ok. Hope this clarifies it all. We are also investigating it. Seems to be somehow “failing” and using part of the ‘Failsafe’ values. IF one of you would like to try — edit the xinitrc.template and copy/paste the above terminal values in it and save it as your .xinitrc. Then restart your system and see what happens. The details of my system are listed in the signature below.

Thanks and have fun,:slight_smile:
Chuck