.bash_history is having .xinitrc appended to its end with each boot

It appears that .bash_history is having .xinitrc appended to its end with each boot. This is occurring on my xfce vanilla desktop. My xfce vanilla laptop does not exhibit this problem. The issue was first noticed by @Orajnam https://archived.forum.manjaro.org/t/stable-update-2016-12-07-systemd-kernels-firefox-thunderbird-mesa-python/13808/75?u=kmartin
I have searched google and the forum of course, with no success. Re installed bash, deleted .bash_history and checked my backup. The backup indicates this started before this last update (2016-12-07) probably with stable update 2016-11-25.

Does anyone else find their .xinitrc appended to their .Bash_history ? :confounded:

#!/bin/sh

#
# ~/.xinitrc
#
# Executed by startx (run your window manager from here)
#

export GTK2_RC_FILES="$HOME/.gtkrc-2.0"

DEFAULT_SESSION=xfce4-session
case $1 in
  xfce) exec dbus-launch xfce4-session ;;
  *) exec dbus-launch  $DEFAULT_SESSION ;;
esac

Here I delete .bash_history.
reboot.
ls -l
reboot...

Yes I typed:
"deleted .bash_history (return)
will now reboot (return)"
at the prompt.

Here is the resulting .bash_history:

deleted .bash_history
will now reboot
#!/bin/sh
#
# ~/.xinitrc
#
# Executed by startx (run your window manager from here)
#
export GTK2_RC_FILES="$HOME/.gtkrc-2.0"
DEFAULT_SESSION=xfce4-session
case $1 in   xfce) exec dbus-launch xfce4-session ;;   *) exec dbus-launch  $DEFAULT_SESSION ;; esac
rebooted
ls -l
#!/bin/sh
#
# ~/.xinitrc
#
# Executed by startx (run your window manager from here)
#
export GTK2_RC_FILES="$HOME/.gtkrc-2.0"
DEFAULT_SESSION=xfce4-session
case $1 in   xfce) exec dbus-launch xfce4-session ;;   *) exec dbus-launch  $DEFAULT_SESSION ;; esac

It looks like some thing is writing .xinitrc to the .bash_history buffer, but what and how is over my head.
Some help would be greatly appreciated. :sweat_smile:
Thank you

1 Like

Can't find it right now but I've seen someone else describing this odd behaviour here recently...
weird!

Thanks for a reply oberon.
As best I can tell .xsesson calls .xinitrc.
.xsession:
#!/bin/sh

#
# ~/.xsession
#
# Executed by xdm/gdm/kdm at login
#

/bin/bash --login -i ~/.xinitrc

Would the -i switch (interactive) cause this write to bash_history? I'm not versed in bash very much sadly.

I also found this article: https://coderwall.com/p/v4dora/execute-xinitrc-under-bash

## Execute .xinitrc under bash

x11 workaround

xinit uses sh to load .xinitrc, which can load incompatible bashisms in .bashrc if the login shell is /bin/bash. Ideally xinit reads something to load /bin/bash but here's a workaround at the top of .xinitrc:

if [[ x"$BASH" != x"/bin/bash" ]]; then
exec /bin/bash "$HOME/.xinitrc"
fi

Written by Tom, Bom

I know that he is talking about .bashrc I am floundering about trying to figure this and other stuff out. :persevere:

At the top of my .xsession-errors file:
bash: cannot set terminal process group (624): Inappropriate ioctl for device
bash: no job control in this shell
gpg-agent[656]: WARNING: "--write-env-file" is an obsolete option - it has no effect
gpg-agent[657]: gpg-agent (GnuPG) 2.1.16 started

Is this an instance of pearls before swine? :fearful:

Anyway I got an eye strain headache going, so punching out for a bit...
Thanks again :smile:

I searched my laptop (it is a newer install of xfce) for .xinitrc and had none not even in /etc/skel/ soooo ------->
I renamed my .xinitrc. Reboot did not append it to bash_history.
Does anyone know of a problem with this? :neutral_face:
@oberon
@Orajnam

Should it be removed from /etc/skel/ as well?

Just a bump to see if anyone has found a fix yet.

My info is in my profile but I use xfce too.

It all seems to function ok in effect removed (renamed .xinitrc ). I've been running this way for 4 days now.

Happy trails...

Sorry if there is a double notice @Orajnam but the reply to you thingiey does not show in my post. :confounded: so I felt that I should add the at Orajnam notifier.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by