[solved] Wayland: Path has double entries for the jre and perl?

IrvineHimself · 2019-06-27 13:35:24

I am not certain I understand exactly what you mean, but if you meant editing my .bash_profile, like so:

   /usr/bin/date > /tmp/gnome-session.date
   QT_QPA_PLATFORM=wayland XDG_SESSION_TYPE=wayland gnome-session > /dev/null 2>&1

Then the file didn't survive the gnome_session being launched.

I know it was being created, because it took me a couple of attempts to get right, and, to fix things, I had to edit my .bash_profile from the console. As a consequence I was able to check /tmp before rebooting.

If I have misunderstood you, my apologies and I ask for your patience

Irvine

seth · 2019-06-27 13:38:12

No, in the /usr/bin/gnome-session script - it launches a login shell at this point.

The file would certainly not survive a reboot (/tmp is a tmpfs - it exists in your RAM)

IrvineHimself · 2019-06-27 13:58:47

Yep, definitely hit that branch

*$ ls /tmp | grep "date"
gnome-session.date
*$

I placed it like so:

*$ cat /usr/bin/gnome-session
#!/bin/sh

if [ "x$XDG_SESSION_TYPE" = "xwayland" ] &&
   [ "x$XDG_SESSION_CLASS" != "xgreeter" ] &&
   [  -n "$SHELL" ] &&
   grep -q "$SHELL" /etc/shells &&
   ! (echo "$SHELL" | grep -q "false") &&
   ! (echo "$SHELL" | grep -q "nologin"); then
  if [ "$1" != '-l' ]; then
    /usr/bin/date > /tmp/gnome-session.date
    exec bash -c "exec -l '$SHELL' -c '$0 -l $*'"
  else
    shift
  fi
fi

SETTING=$(G_MESSAGES_DEBUG= gsettings get org.gnome.system.locale region)
REGION=${SETTING#\'}
REGION=${REGION%\'}

if [ -n "$REGION" ]; then
  export LC_TIME=$REGION
  export LC_NUMERIC=$REGION
  export LC_MONETARY=$REGION
  export LC_MEASUREMENT=$REGION
  export LC_PAPER=$REGION
fi

exec /usr/lib/gnome-session-binary "$@"
*$

My apologies for not realising what you meant,. While I like to tinker, editing files in /usr/bin makes me very nervous.

Irvine

seth · 2019-06-27 14:09:05

If you're positive that the file doesn't stem from a previous approach in your bash_profile, there's the cause for the double entry.
I've no idea what's the point of all of this (and esp. why the "shift" call is in the outer condition), but you could replace the entire nonsense block with an unconditional shift and see what happens:

#!/bin/sh

shift

SETTING=$(G_MESSAGES_DEBUG= gsettings get org.gnome.system.locale region)
REGION=${SETTING#\'}
REGION=${REGION%\'}

if [ -n "$REGION" ]; then
  export LC_TIME=$REGION
  export LC_NUMERIC=$REGION
  export LC_MONETARY=$REGION
  export LC_MEASUREMENT=$REGION
  export LC_PAPER=$REGION
fi

exec /usr/lib/gnome-session-binary "$@"

IrvineHimself · 2019-06-27 14:39:15

You are a genius, thank you.

*$ echo $PATH
/usr/local/bin/FjSymlinks:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
*$ sudo -i
[sudo] password for stupidme: 
*#  echo $PATH
/usr/local/bin/FjSymlinks:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
*# exit
logout
*$ echo $PATH
/usr/local/bin/FjSymlinks:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
*$

I think the fact that the root account has double entries is almost certainly a separate issue, relating to it being a new log-on and one I can easily live with. I only ever use sudo -i when absolutely necessary, for example where I need to change directories as root.

I will mark this thread as solved, but should I file a bug report that references this thread?

Irvine

Just as a reference check

*$ cat /usr/bin/gnome-session
#!/bin/sh

shift

SETTING=$(G_MESSAGES_DEBUG= gsettings get org.gnome.system.locale region)
REGION=${SETTING#\'}
REGION=${REGION%\'}

if [ -n "$REGION" ]; then
  export LC_TIME=$REGION
  export LC_NUMERIC=$REGION
  export LC_MONETARY=$REGION
  export LC_MEASUREMENT=$REGION
  export LC_PAPER=$REGION
fi

exec /usr/lib/gnome-session-binary "$@"

seth · 2019-06-27 21:27:32

The background is apparently https://bugzilla.gnome.org/show_bug.cgi?id=736660 but leaving your issue aside the conditional "shift" as well as no apparent approach to test whether this already is a login shell seem fishy enough.
(Unfortunately there's no portable way, see https://unix.stackexchange.com/question … tive-batch )

And

exec bash -c "exec -l '$SHELL' -c '$0 -l $*'"

is kinda wacko - you exec a bash to exec -l (append "-" for a login shell, not a POSIX feature, thus the explicit bash roundtrip) to run this script?
And the bug report explicitly asks for bash_profile, what is nuts - for what reason should the "gnome SHELL" parse the config of the "bourne again SHELL"?

Maybe one should at least clear the environment ("… env -i exec -l '$SHELL' -c '$0 -l $*'") but actually parsing the config of one shell into another is hardly justified

The patch had previously reverted and there's also enough discussion on the bug - feel free to complain

If you decide to follow up, ensure to read the bug, nobody likes debating the same arguments again and again.
Skimming it, "heftig" isn't happy w/ this either (and he's the gnome-session packager) - you could reasonably file a bug against the package to push for a downstream fix (most likely not gonna happen, don't debate it!) to re-raise his awareness and get his current opinion.

My 2¢ are that if a user runs this w/o a bash login but wants a bash login (and evironments) than that user should run "bash -l -c /usr/bin/gnome-session" - *shrug*

IrvineHimself · 2019-06-28 05:34:50

That is one serious read! I have just spent two or three hours going through it, and only just skimmed the surface. My initial take is that any rational fix, downstream/distro-speciffic, or upstream, is likely to make an awful lot of people very unhappy.

On a personal level, it touches on several projects which, (now that I am back on Arch,) I have in mind. There is obviously the whole security angle, where, by trying to maintain backward compatibility, Wayland is inheriting locations in ${HOME} which, (without hardening with a sandbox and/or MAC,) allow unprivileged attackers to plant malicious code. But also, there seems to be a presumption amongst certain contributors that users running a gnome-shell should also run gdm.

As an Arch user, I am quite proud of my customised /etc/issue log-on prompt with it's little text-based throbber, and was thinking of extending the whole idea to allow me to choose between say: Gnome, Weston or just a plain console. As a consequence, I am fairly sure other Arch users can relate to how I feel about being forced to use gdm.

Before I put in a very polite request for the Arch developers to address this issue, I am going to have to re-read the bug-report, and make sure I really understand what is going on.

The reason I like Arch is because it offers users with limited experience the chance to learn about the fundamental building blocks of the modern desktop environment. As such, I have learned an awful lot about the whole log-on process from this thread, and would like to offer my sincerest thanks for your help.

Irvine

ps: Since this is Wayland specific, I have changed the title to reflect this.

Edit1: grammar
Edit2: added ps

Last edited by IrvineHimself (2019-06-28 05:49:47)

Arch Linux

#26 2019-06-27 13:35:24

Re: [solved] Wayland: Path has double entries for the jre and perl?

#27 2019-06-27 13:38:12

Re: [solved] Wayland: Path has double entries for the jre and perl?

#28 2019-06-27 13:58:47

Re: [solved] Wayland: Path has double entries for the jre and perl?

#29 2019-06-27 14:09:05

Re: [solved] Wayland: Path has double entries for the jre and perl?

#30 2019-06-27 14:39:15

Re: [solved] Wayland: Path has double entries for the jre and perl?

#31 2019-06-27 21:27:32

Re: [solved] Wayland: Path has double entries for the jre and perl?

#32 2019-06-28 05:34:50

Re: [solved] Wayland: Path has double entries for the jre and perl?

Board footer