Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#48704 - [gdm] perl items in /etc/profile.d not being sourced without specifying login-shell

Attached to Project: Arch Linux
Opened by Britt Yazel (brittyazel) - Saturday, 26 March 2016, 19:14 GMT
Last edited by Gerardo Exequiel Pozzi (djgera) - Tuesday, 29 March 2016, 02:01 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Jan Alexander Steffens (heftig)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I am not sure if this bug report falls within the purview of the Archlinux project, but I thought it would be worth at least a mention. Right now, in order to execute commands from the shell in perl, without first telling the terminal to launch bash as a "login shell", you must explicitly add perl to the path each and every time as the /etc/profile.d scripts are not being sourced.

A real manifestation of this can be seen in the AUR in the packages Cower and Pacaur, where hundreds of complaints have been filed that these packages fail to build as they error once they evoke Perl commands. Now, this is easily remedied by telling the terminal to "launch as login shell", in which case /etc/profile.d is sourced and all of the paths are added, but this is not the default, and it still tripping up hundreds of users as this is not well documented.

I don't know if there is any possible fix for this, but it is a concern that took me a few hours over a few days to figure out the root cause of.
This task depends upon

Closed by  Gerardo Exequiel Pozzi (djgera)
Tuesday, 29 March 2016, 02:01 GMT
Reason for closing:  Not a bug
Comment by Doug Newgard (Scimmia) - Saturday, 26 March 2016, 19:29 GMT
I'm guessing you use some kind of display manager that's screwing things up here.
Comment by Britt Yazel (brittyazel) - Saturday, 26 March 2016, 19:32 GMT
GDM if you were wondering. I am not sure if it is or is not screwing things up, but it wouldn't be unusual. In the latest versions GDM opens up under one tty session and gnome itself opens up under a different tty, could this be what is causing it?
Comment by Doug Newgard (Scimmia) - Saturday, 26 March 2016, 19:41 GMT
So this is either a GDM problem, or you have something else that's overriding $PATH.
Comment by Britt Yazel (brittyazel) - Saturday, 26 March 2016, 19:44 GMT
I don't believe I have something overriding $PATH, as this has manifested itself on all of my computers since around Gnome 3.18 was released (though I didn't draw a parallel between GDM and this issue until you just brought it up). Even fresh installs are plagued from this issue, and looking at the volumes of people on the AUR similarly having this issue, I would probably attribute it to a global issue rather than a local one.

If it is in fact a GDM issue, that sucks, as it essentially screws all of us out of performing any actions that aren't housed within the default $PATH variable.

The good news is that they already confirmed that they will be reverting their GDM changes (though no timetable, nor am I 100% certain this is the cause of this issue)
Comment by Doug Newgard (Scimmia) - Saturday, 26 March 2016, 19:54 GMT
"The good news is that they already confirmed that they will be reverting their GDM changes (though no timetable, nor am I 100% certain this is the cause of this issue)"

Link?
Comment by Britt Yazel (brittyazel) - Saturday, 26 March 2016, 19:58 GMT
https://bugzilla.gnome.org/show_bug.cgi?id=747339#c75

The last few comments
Comment by Doug Newgard (Scimmia) - Saturday, 26 March 2016, 20:00 GMT
Yeah, I have no idea if that's related.
Comment by Jan Alexander Steffens (heftig) - Saturday, 26 March 2016, 20:27 GMT
/etc/gdm/Xsession loads /etc/profile.
Comment by Britt Yazel (brittyazel) - Saturday, 26 March 2016, 20:30 GMT
However, GDM is loaded on tty1 whereas the shell is actually started on a different tty (as per the comments above), is it possible that this is messing it up? That /etc/profile is loaded but on the wrong session, and the session that actually matters (where the shell is), does not have it loaded?
Comment by Britt Yazel (brittyazel) - Monday, 28 March 2016, 18:47 GMT
Weird, I am unable to replicate this issue on Gnome-Terminal any longer. I have been using Terminix for the last while which DOES experience this issue, but Gnome-Terminal doesn't seem to have the problem. I swear I had this issue well before Terminix even existed, but perhaps it was fixed upstream and Terminix just has not adopted the change.

Please close this bug, as it does not seem to be an issue anymore and was rather localized to my Terminix client. I have reported this bug to them.

Loading...