On Mon 09 Apr 2018 at 08:32:00 (-0400), Greg Wooledge wrote:
> On Sat, Apr 07, 2018 at 11:47:19AM +0100, Jonathan de Boyne Pollard wrote:
… a post that doesn't seem to have made it to the archives.
https://lists.debian.org/debian-user/2018/04/author.html
> >
> >
>
> Really? :-(
>
> >
> >
On Sat, Apr 07, 2018 at 11:47:19AM +0100, Jonathan de Boyne Pollard wrote:
>
>
Really? :-(
>
>
> The $ metacharacter is documented in the FreeBSD
> manual page that I pointed to before, alongside a ~
> metacharacter which yields your desired result fairly trivially.
OK
On Fri, Mar 30, 2018 at 12:57:23PM -0700, Don Armstrong wrote:
> See
> https://github.com/linux-pam/linux-pam/blob/master/modules/pam_env/pam_env.c#L668
Oh, look, a pam_syslog call. I didn't think to check logs.
Mar 30 15:45:01 wooledg CRON[28166]: pam_env(cron:session): Unknown PAM_ITEM:
Mar
On Fri, 30 Mar 2018, Greg Wooledge wrote:
> On Fri, Mar 30, 2018 at 12:11:18PM -0700, Don Armstrong wrote:
> > That's why you need @{HOME}, not ${HOME}.
>
> Same result.
>
> $ tail -2 /etc/security/pam_env.conf
> FOO DEFAULT=@{HOME}/bar
> LANG DEFAULT=en_US.UTF-8 OVERRIDE=$
On Fri, Mar 30, 2018 at 12:11:18PM -0700, Don Armstrong wrote:
> On Fri, 30 Mar 2018, Greg Wooledge wrote:
> > 1) ${HOME} is in fact NOT available to pam_env.conf at least for the
> > ssh "application" of PAM, despite being used in the documentation.
>
> That's why you need @{HOME}, not ${HOME}.
On Fri, 30 Mar 2018, Greg Wooledge wrote:
> 1) ${HOME} is in fact NOT available to pam_env.conf at least for the
> ssh "application" of PAM, despite being used in the documentation.
That's why you need @{HOME}, not ${HOME}.
[...]
> In conclusion, pam_env.so still can't do either of the two thing
My domain is slsware.*, and I run bash.
Therefore I created /etc/sls/ and wrote a little script in that
directory called slswaredefs.sh and sourced it near the bottom of
everybody's .bashrc.
For more/other shells, write in Perl/Python and switch on shell in the
list of of environment variables go
Well, bad news. The /etc/security/pam_env.conf stuff is just as
useless as /etc/environment.
I tested two things. I placed the following two lines in the file:
FOO DEFAULT=${HOME}/bar
LANGDEFAULT=en_US.UTF-8
Then I did an "ssh localhost". The resulting login shell had
On Fri, Mar 30, 2018 at 10:09:48AM -0700, Don Armstrong wrote:
> On Fri, 30 Mar 2018, Greg Wooledge wrote:
> > I have an extremely simple real-world litmus test which every system
> > I've ever seen so far has failed:
> >
> > How do I set MAIL=$HOME/Maildir/ in the login environment of every
> >
On Fri, 30 Mar 2018, Greg Wooledge wrote:
> I have an extremely simple real-world litmus test which every system
> I've ever seen so far has failed:
>
> How do I set MAIL=$HOME/Maildir/ in the login environment of every
> user, regardless of their shell, or how they log in (console, ssh,
> X
> I have an extremely simple real-world litmus test which every system
> I've ever seen so far has failed:
>
> How do I set MAIL=$HOME/Maildir/ in the login environment of every
> user, regardless of their shell, or how they log in (console, ssh,
> X Display Manager, GNOME Display Manager, et
On Fri 30 Mar 2018 at 09:59:22 (-0400), Greg Wooledge wrote:
> On Thu, Mar 29, 2018 at 09:42:34PM +0100, Jonathan de Boyne Pollard wrote:
> > I think that login.conf is a step in the right direction, and I'm planning
> > on making tools that support it. Or, rather, on making the tools that
> > alr
On Thu, Mar 29, 2018 at 09:42:34PM +0100, Jonathan de Boyne Pollard wrote:
> I think that login.conf is a step in the right direction, and I'm planning
> on making tools that support it. Or, rather, on making the tools that
> already support it on the BSDs also support it on Linux operating system
Greg Wooledge:
If there existed a single, universal, simple answer, don't you think
we would have put it on the wiki page?
I think that login.conf is a step in the right direction, and I'm
planning on making tools that support it. Or, rather, on making the
tools that already support it on
Hello Ben,
Your login manager invokes the correct script based on the selected
desktop, and your personal one in ~/.config/xfce4/xinitrc takes
precedence over /etc/xdg/xfce4/xinitrc . The last line just tells sh
to source (run) the official /etc/xdg/xfce4/xinitrc , but you get to
set your env
On 20/03/18 16:13, Subhadip Ghosh wrote:
Hi Ben,
Under XFCE, I have ~/.config/xfce4/xinitrc something like this:
#!/bin/sh
export LC_COLLATE=C
export PATH=$HOME/bin:$PATH
export QT_QPA_PLATFORMTHEME=gtk2
export GTK_OVERLAY_SCROLLING=0
umask 007
. /etc/xdg/xfce4/xinitrc
Thanks for telling me thi
Hi Ben,
Under XFCE, I have ~/.config/xfce4/xinitrc something like this:
#!/bin/sh
export LC_COLLATE=C
export PATH=$HOME/bin:$PATH
export QT_QPA_PLATFORMTHEME=gtk2
export GTK_OVERLAY_SCROLLING=0
umask 007
. /etc/xdg/xfce4/xinitrc
Thanks for telling me this. Since I also use Xfce, it makes sense
On 20/03/18 07:59, Subhadip Ghosh wrote:
While it was very informative, it was not evident from it that what
the standard or preferred place is for setting an environment variable
if I want it to be available from both graphical applications as well as
from terminal (bash).
Under XFCE, I have ~
On Tue, Mar 20, 2018 at 12:29:53AM +0530, Subhadip Ghosh wrote:
> I went through the below link:
>
> https://wiki.debian.org/EnvironmentVariables
>
> While it was very informative, it was not evident from it that what
> the standard or preferred place is for setting an environment variable
> if I
Hi,
I went through the below link:
https://wiki.debian.org/EnvironmentVariables
While it was very informative, it was not evident from it that what
the standard or preferred place is for setting an environment variable
if I want it to be available from both graphical applications as well as
fro
20 matches
Mail list logo
