On Wed, Oct 09, 2024 at 09:52:13 +0700, Max Nikulin wrote:
> On 09/10/2024 07:38, e...@gmx.us wrote:
> >
> > Huh. If I run it from a terminal emulator it looks fine, but if XFCE
> > launches it the text is tiny. Looks like QT_QPA_PLATFORMTHEME isn't being
> > set. Which means something is runni
On 09/10/2024 07:38, e...@gmx.us wrote:
Huh. If I run it from a terminal emulator it looks fine, but if XFCE
launches it the text is tiny. Looks like QT_QPA_PLATFORMTHEME isn't being
set. Which means something is running a not-login shell, something between
startx and xfwm. It's defined in ~
uot;.
pam_env.conf(5) is far more interesting, especially this paragraph:
The /etc/environment file specifies the environment variables to be
set. The file must consist of simple NAME=VALUE pairs on separate
lines. The pam_env(8) module will read the file after the pam_env
Hi,
29 juin 2020 à 17:52 de wool...@eeg.ccf.org:
> The holy grail, for me, would have been a way to specify environment
> variables that are applied to all user logins, whether by console login,
> or ssh, or Display Manager, independent of the user's login shell.
> And tho
On Mon, Jun 29, 2020 at 10:37:49PM +0300, Andrei POPESCU wrote:
> So far I've settled to the snippet below in *both* ~/.profile and
> ~/.xsessionrc (inspired by a similar snippet in /etc/profile):
>
>
> if [ -d "$HOME"/.config/environment.d ]; then
> for i in "$HOME"/.config/environment.d/*.sh
On Lu, 29 iun 20, 11:52:45, Greg Wooledge wrote:
> On Mon, Jun 29, 2020 at 05:19:49PM +0200, l0f...@tuta.io wrote:
> > I'm not sure to understand what you want to achieve exactly, but aren't you
> > supposed to use pam_env for setting/unsetting your environment va
Greg Wooledge wrote:
> The holy grail, for me, would have been a way to specify environment
> variables that are applied to all user logins, whether by console login,
> or ssh, or Display Manager, independent of the user's login shell.
This is more or less what I try to achieve her
Greg Wooledge wrote:
> As far as I've been able to determine, this environment.d stuff does
> *not* work with logins.
D'oh! That didn't occur to me. Re-reading the man pages with that in
mind makes more sense now. As you say, it seems to be implicitly assumed
in several places but not stated expli
On Mon, Jun 29, 2020 at 05:19:49PM +0200, l0f...@tuta.io wrote:
> I'm not sure to understand what you want to achieve exactly, but aren't you
> supposed to use pam_env for setting/unsetting your environment variables?
We can only speculate about the OP's actual goal, but
Hi,
I'm not sure to understand what you want to achieve exactly, but aren't you
supposed to use pam_env for setting/unsetting your environment variables?
Best regards,
l0f4r0
On Mon, Jun 29, 2020 at 10:42:51AM +0100, Thomas Pircher wrote:
> Hi,
>
> I'm experimenting with systemd environment variables. I have a file
> ~/.config/environment.d/50-default.conf where I set a few variables:
>
> > MOZ_ENABLE_WAYLAND=1
> > GDK_BACKEND=wayland
Thomas Pircher wrote:
> I'm experimenting with systemd environment variables.
I forgot to mention that this is on Debian testing/bullseye.
Hi,
I'm experimenting with systemd environment variables. I have a file
~/.config/environment.d/50-default.conf where I set a few variables:
> MOZ_ENABLE_WAYLAND=1
> GDK_BACKEND=wayland
> TESTVAR=test123
However, these variables are not set in my environment when I log in. I
have
d at the "setenv" section which says "A
> comma-separated list of environment variables and values to which they
> are to be set." Then jumped to the bottom to look for examples, of
> which there are zero.
>
> I guess I should have read every single sentence, t
sult fairly trivially.
OK. I confess I only looked at the "setenv" section which says "A
comma-separated list of environment variables and values to which they
are to be set." Then jumped to the bottom to look for examples, of
which there are zero.
I guess I should have read ever
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 vari
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
gt; That's it. Simple, right? But login.conf can't do it. And pam_env.so
> can't do it. They only allow static strings with no substitutions.
> In fact I'm not aware of ANYTHING that can do it.
>
> The closest I've seen is sshd_config which uses %h and %u tokens in
that can do it.
The closest I've seen is sshd_config which uses %h and %u tokens in
some contexts, but only for specific sshd configuration parameters --
not for setting environment variables.
In the real world, today, the only solution is to duplicate that setting
in multiple places, so tha
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
environment variables *first* so they affect everything in
Xfce including services and desktop components. I do not know if this
is documented succinctly in one place, but that is my understanding of
how it works.
Your understanding is correct. A quick Googling gave some helpful
results. Take a
. The last line just tells sh to
source (run) the official /etc/xdg/xfce4/xinitrc , but you get to set
your environment variables *first* so they affect everything in Xfce
including services and desktop components. I do not know if this is
documented succinctly in one place, but that is my unders
export QT_QPA_PLATFORMTHEME=gtk2
export GTK_OVERLAY_SCROLLING=0
umask 007
. /etc/xdg/xfce4/xinitrc
Graphical applications (including xfce4-teminal) and its child bash
inherit these exported environment variables from their parent. (And
note that I assume $PATH and $HOME do not require quoting
environment variables from their parent. (And
note that I assume $PATH and $HOME do not require quoting.)
The file is a script so it must be executable:
chmod 700 ~/.config/xfce4/xinitrc
Kind regards,
--
Ben Caradoc-Davies
Director
Transient Software Limited <https://transient.nz/>
New Zealand
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
On Tue, Oct 03, 2017 at 02:42:08PM +0200, to...@tuxteam.de wrote:
> On Tue, Oct 03, 2017 at 08:31:59AM -0400, Greg Wooledge wrote:
> > On Tue, Oct 03, 2017 at 08:35:43AM +0200, to...@tuxteam.de wrote:
> > > This, dear reader assumes you are reading in monospace (Zenaan, I
> > > know you do, but thi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Oct 03, 2017 at 08:31:59AM -0400, Greg Wooledge wrote:
> On Tue, Oct 03, 2017 at 08:35:43AM +0200, to...@tuxteam.de wrote:
> > This, dear reader assumes you are reading in monospace (Zenaan, I
> > know you do, but think of those poor souls boun
On Tue, Oct 03, 2017 at 08:35:43AM +0200, to...@tuxteam.de wrote:
> This, dear reader assumes you are reading in monospace (Zenaan, I
> know you do, but think of those poor souls bound to a Web interface ;-)
They are already in hell. Nothing I can do to save them.
> > ← ↑ ↓ → ⋱ ⋰ ⇄ ※
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Oct 03, 2017 at 08:25:40AM +1100, Zenaan Harkness wrote:
[...]
> Tomas - I will try your Liberation font suggestion, but xfce term is
> giving me a rock solid "Fixed" experience, AND the fancy character
> dancing... for me, this is peak produ
On Mon, Oct 02, 2017 at 08:41:22AM -0400, Michael Stone wrote:
> On Mon, Oct 02, 2017 at 10:52:11PM +1100, Zenaan Harkness wrote:
> > I'm using font "Fixed SemiCondensed" 8 pt in xfce4-term - and it
> > seems xfce4-terminal has some fallback to either some other font(s?)
> > but in any case, displa
On Mon, Oct 02, 2017 at 10:52:11PM +1100, Zenaan Harkness wrote:
I'm using font "Fixed SemiCondensed" 8 pt in xfce4-term - and it
seems xfce4-terminal has some fallback to either some other font(s?)
but in any case, displays all Unicode chars I've tried to display,
whereas xterm fails on some cha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Oct 02, 2017 at 10:52:11PM +1100, Zenaan Harkness wrote:
> On Mon, Oct 02, 2017 at 01:38:07PM +0200, to...@tuxteam.de wrote:
> > A couple of years ago or five, I switched back to xterm (from a random
> > walk which included gnome-terminal at so
On Mon, Oct 02, 2017 at 01:38:07PM +0200, to...@tuxteam.de wrote:
> A couple of years ago or five, I switched back to xterm (from a random
> walk which included gnome-terminal at some point). Xterm had fixed its
> UTF-8 problems, could use modern fonts and all that.
>
> Reading your accounts remim
h intention is bound to various window manager shortcuts.
[...]
> I'm sure that this use of environment variables is utterly unique and
> has simply --never-- been thought of before. Or something :)
Yikes 8-o
Thanks to you both: you taught me something. I wouldn't have expected
t
> > Oh, oh, oh‼ I'm hopping excited now, it works it works! :D
> >
> > Thanks guys - the fancy arg dancing allows for me to do some fancy
> > arg dancing :)
>
> For the archives.
>
> --disable-server removes xfce4-terminal ability to talk to DBUS, which
>
ce4-terminal ability to talk to DBUS, which
is intended be used, presumably (too lazy to read sources) to force the
existing xfce4-terminal to spawn a new window.
Without this switch defining new environment variable applies only to
"sending DBUS message" part of xfce4-terminal. And of
On Mon, Oct 02, 2017 at 10:19:44AM +0300, Reco wrote:
> Hi.
>
> On Mon, Oct 02, 2017 at 02:58:59PM +1100, Zenaan Harkness wrote:
> > >From terminal A (may be xterm or xfce4-terminal), launch terminals:
> >
> > MYVAR="wow - some text!" xterm &
> > MYVAR="wow - some text!" xfce4-terminal &
Hi.
On Mon, Oct 02, 2017 at 02:58:59PM +1100, Zenaan Harkness wrote:
> >From terminal A (may be xterm or xfce4-terminal), launch terminals:
>
> MYVAR="wow - some text!" xterm &
> MYVAR="wow - some text!" xfce4-terminal &
>
> Now from those terminals, run:
>
> echo $MYVAR
>
>
> In x
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Oct 02, 2017 at 02:58:59PM +1100, Zenaan Harkness wrote:
> >From terminal A (may be xterm or xfce4-terminal), launch terminals:
>
> MYVAR="wow - some text!" xterm &
> MYVAR="wow - some text!" xfce4-terminal &
>
> Now from those terminals, r
>From terminal A (may be xterm or xfce4-terminal), launch terminals:
MYVAR="wow - some text!" xterm &
MYVAR="wow - some text!" xfce4-terminal &
Now from those terminals, run:
echo $MYVAR
In xterm, we get the expected output - evidently MYVAR is correctly
"passed through" - this is how env v
to...@tuxteam.de wrote:
> Yes, all of those! But I don't see how that's an answer to the OP's
> legitimate question: how to keep things that belong together in one
> place, instead of repeating it in every bit of config?
I use always /etc/profile for non user specific or X stuff.
Never had a prob
Le nonidi 9 ventôse, an CCXXV, Teemu Likonen a écrit :
> I moved my variable assignments to ~/.environment.sh and source that to
> ~/.profile and ~/.xsession.
Zsh has a ~/.zshenv that is meant exactly for that. It is sourced by all
zsh instances, even those started as interpreters. It is very
conv
David Wright [2017-02-27 10:56:55-06] wrote:
>> systemctl --user import-enviroment
>
> Is that typo actually in the file?
No. I just (mis)typed those "files" here. In practice they contain quite
a lot more than that.
>> ~/.xsession:
>>
>> . ~/.profile
>
> My profile has side effects. Ca
On Mon 27 Feb 2017 at 15:19:27 (+0200), Teemu Likonen wrote:
> to...@tuxteam.de [2017-02-27 09:12:28+01] wrote:
>
> > On Mon, Feb 27, 2017 at 09:07:19AM +0100, deloptes wrote:
> >> So I do distinguish between settings for X session and for not X
> >> session - at least two places for the variables
to...@tuxteam.de [2017-02-27 09:12:28+01] wrote:
> On Mon, Feb 27, 2017 at 09:07:19AM +0100, deloptes wrote:
>> So I do distinguish between settings for X session and for not X
>> session - at least two places for the variables. Further more there
>> are global and user specific ... etc
>
> Yes, a
On Sun, Feb 26, 2017 at 02:26:08PM +0200, Teemu Likonen wrote:
> I would like to hear some ideas on how to set various environment
> variables (PATH, MANPATH, EDITOR etc.) in one place that would make them
> effective everywhere. My "everywhere" means:
>
> - X sessio
* GiaThnYgeia [2017-02-27 11:38 +]:
[...]
> For a while I've been trying to set the locale but everytime I install a
> package it returns locale not set returning to default C
> I used /etc/environment, and no change.
> I suspect this may be due to some skipped step on the original
> installa
to...@tuxteam.de:
> On Mon, Feb 27, 2017 at 09:07:19AM +0100, deloptes wrote:
>> Stefan Monnier wrote:
>
>>>>> I would like to hear some ideas on how to set various environment
>>>>> variables (PATH, MANPATH, EDITOR etc.) in one place that woul
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Feb 27, 2017 at 09:07:19AM +0100, deloptes wrote:
> Stefan Monnier wrote:
>
> >>> I would like to hear some ideas on how to set various environment
> >>> variables (PATH, MANPATH, EDITOR etc.) in one place that w
Stefan Monnier wrote:
>>> I would like to hear some ideas on how to set various environment
>>> variables (PATH, MANPATH, EDITOR etc.) in one place that would make them
>>> effective everywhere. My "everywhere" means:
>>> - X session started thro
>> I would like to hear some ideas on how to set various environment
>> variables (PATH, MANPATH, EDITOR etc.) in one place that would make them
>> effective everywhere. My "everywhere" means:
>> - X session started through lightdm and ~/.xsession script
>>
Am 26.02.2017 um 13:26 schrieb Teemu Likonen:
> I would like to hear some ideas on how to set various environment
> variables (PATH, MANPATH, EDITOR etc.) in one place that would make them
> effective everywhere. My "everywhere" means:
>
> - X session started throug
I would like to hear some ideas on how to set various environment
variables (PATH, MANPATH, EDITOR etc.) in one place that would make them
effective everywhere. My "everywhere" means:
- X session started through lightdm and ~/.xsession script
- Linux console login (bash)
- user
Rodolfo Medina writes:
> I'm having troubles with ps files generated by Emacs ps-print package -
> footers are partially cut off. Is it possibile that some environment
> variable causes the weird? And how can I know (and work it out)?
The problem is worked out simply changing the font used for
Rodolfo Medina writes:
I'm having troubles with ps files generated by Emacs ps-print package -
footers are partially cut off.
I'm attaching a test file that shows the problem.
Rodolfo
stampa.ps
Description: PostScript document
Curt writes:
> On 2015-03-03, Mark Carroll wrote:
>>
>>> I'm having troubles with ps files generated by Emacs ps-print package -
>>> footers are partially cut off. Is it possibile that some environment
>>> variable causes the weird? And how can I know (and work it out)?
>>
>> I've never used t
On 2015-03-03, Mark Carroll wrote:
>
>> I'm having troubles with ps files generated by Emacs ps-print package -
>> footers
>> are partially cut off. Is it possibile that some environment variable causes
>> the weird? And how can I know (and work it out)?
>
> I've never used that package, but th
Rodolfo Medina writes:
> I'm having troubles with ps files generated by Emacs ps-print package -
> footers
> are partially cut off. Is it possibile that some environment variable causes
> the weird? And how can I know (and work it out)?
I've never used that package, but the first thing I'd ch
Hi all.
I'm having troubles with ps files generated by Emacs ps-print package - footers
are partially cut off. Is it possibile that some environment variable causes
the weird? And how can I know (and work it out)?
Thanks for any help,
Rodolfo
--
To UNSUBSCRIBE, email to debian-user-requ...@
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 09/25/2014 at 11:16 AM, The Wanderer wrote:
> On 09/24/2014 at 04:52 PM, Steve Litt wrote:
>
>> Hi everyone,
>
>> Bash Code Injection Vulnerability via Specially Crafted
>> Environment Variables (CVE-2014-6271)
>
Brian wrote on 09/25/2014 02:08:15 PM:
> From: Brian
> To: debian-user@lists.debian.org
> Date: 09/25/2014 02:08 PM
> Subject: Re: Bash Code Injection Vulnerability via Specially Crafted
> Environment Variables (CVE-2014-6271)
>
> On Thu 25 Sep 2014 at 13:59:40 -040
On Thursday, September 25, 2014 13:59:40 Joe Loiacono wrote:
> By default I have seemingly assumed sysadmin duties for a host running
> Debian 6.0.7 (squeeze). So (not having done a lot of this before) ...
>
>
> 1) the system bash is vulnerable
>
> > env x='() { :;}; echo vulnerable' bash -c "
On Thu 25 Sep 2014 at 13:59:40 -0400, Joe Loiacono wrote:
> By default I have seemingly assumed sysadmin duties for a host running
> Debian 6.0.7 (squeeze). So (not having done a lot of this before) ...
https://wiki.debian.org/LTS/Using
https://wiki.debian.org/LTS
https://wiki.debian.org/LTS/FAQ
By default I have seemingly assumed sysadmin duties for a host running
Debian 6.0.7 (squeeze). So (not having done a lot of this before) ...
1) the system bash is vulnerable
> env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test
2) bash is version 4.1.5
h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 09/24/2014 at 04:52 PM, Steve Litt wrote:
> Hi everyone,
>
> Bash Code Injection Vulnerability via Specially Crafted
> Environment Variables (CVE-2014-6271)
>
> https://access.redhat.com/articles/1200223
>
> My
;:
> Red Hat has become aware that the patch for CVE-2014-6271 is incomplete. An
> attacker can provide specially-crafted environment variables containing
> arbitrary commands that will be executed on vulnerable systems under certain
> conditions. The new issue has been assigne
On Wed, Sep 24, 2014 at 04:25:58PM -0500, John Hasler wrote:
> Mailing list: debian-security-annou...@lists.debian.org
>
> You should be subscribed.
I'd just like to re-iterate this. *EVERY* debian user should subscribe to that
list.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian
According to
<https://secure.dshield.org/forums/diary/Attention+NIX+admins+time+to+patch/18703>:
Red Hat has become aware that the patch for CVE-2014-6271 is incomplete.
An attacker can provide specially-crafted environment variables
containing arbitrary commands that will be execu
On Wed 24 Sep 2014 at 16:52:50 -0400, Steve Litt wrote:
> Bash Code Injection Vulnerability via Specially Crafted Environment
> Variables (CVE-2014-6271)
>
> https://access.redhat.com/articles/1200223
[Snip]
Nearly 50 minutes before your mail we had:
To: debian-user@lists.debia
On Wed, 24 Sep 2014 16:25:58 -0500
John Hasler wrote:
[snip]
> Package: bash
> CVE ID : CVE-2014-6271
>
> Stephane Chazelas discovered a vulnerability in bash,
[snip]
> For the stable distribution (wheezy), this problem has been fixed in
> version 4.2+dfsg-0.1+deb7u1.
[snip]
-
Package: bash
CVE ID : CVE-2014-6271
Stephane Chazelas discovered a vulnerability in bash, the GNU
Bourne-Again Shell, related to how environment variables are
processed. In many common configurations, this
On 24/09/14 21:52, Steve Litt wrote:
Hi everyone,
Bash Code Injection Vulnerability via Specially Crafted Environment
Variables (CVE-2014-6271)
https://access.redhat.com/articles/1200223
My current Debian setup is vulnerable, as shown below
Hi everyone,
Bash Code Injection Vulnerability via Specially Crafted Environment
Variables (CVE-2014-6271)
https://access.redhat.com/articles/1200223
My current Debian setup is vulnerable, as shown below:
==
slitt@mydesq2:~$ env x='() { :;}; \
On 05/13/2010 11:15 AM, Boyd Stephen Smith Jr. wrote:
On Thursday 13 May 2010 10:49:35 Jason Filippou wrote:
What am I doing wrong? Do I need to "export" something?
You did log out and log back in, right? Your ".profile" is only read on
login.
Why not just re-source the file?
$ . .profile
On Thu, 2010-05-13 at 14:48 -0500, Boyd Stephen Smith Jr. wrote:
> On Thursday 13 May 2010 13:16:21 Jason Filippou wrote:
> > > You did log out and log back in, right? Your ".profile" is only read
> > > on login.
> >
> > I actually hadn't done that, and logging in again helped with the PATH
> > v
On Thu, May 13, 2010 at 06:49:35PM +0300, Jason Filippou wrote:
> Hi,
>
> I've been trying to set my PATH and CLASSPATH environment variables so that
> they point to my JDK's bin and some Java source files respectively and this
> is what I've written in my .profile
On Thursday 13 May 2010 13:16:21 Jason Filippou wrote:
> > You did log out and log back in, right? Your ".profile" is only read
> > on login.
>
> I actually hadn't done that, and logging in again helped with the PATH
> variable, but I still get nothing when echoing the value of CLASSPATH. I've
>
On Thursday 13 May 2010 10:49:35 Jason Filippou wrote:
> What am I doing wrong? Do I need to "export" something?
You did log out and log back in, right? Your ".profile" is only read on
login.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
b...@iguanasuicide.net ((_/)o
Hi,
I've been trying to set my PATH and CLASSPATH environment variables so that
they point to my JDK's bin and some Java source files respectively and this
is what I've written in my .profile file:
# PATH should also include the latest jdk "bin" directory
PATH="/u
On Friday 22 January 2010 10:03:07 Vincent Lefevre wrote:
> Is it normal that dpkg-reconfigure can be affected by environment
> variables?
That's pretty normal. Most programs don't go out of their way to ignore your
environment settings.
dpkg-reconfigure also uses things like L
Is it normal that dpkg-reconfigure can be affected by environment
variables?
For instance, I have PERL5LIB set to /home/vlefevre/lib/site_perl,
and when I do a "su", this variable is kept in the environment,
and in the strace output on a dpkg-reconfigure, I could see that
$PERL5LIB wa
On 2010-01-16, Daniel Dalton wrote:
>
> On Sat, Jan 16, 2010 at 12:48:49AM +, Liam O'Toole wrote:
>> > I've just installed lxde and like the concept of it. I must set an
>> > environment variable so I can run orca under the desktop. What file
>> > should I place an export command in to export
On Sat, Jan 16, 2010 at 12:48:49AM +, Liam O'Toole wrote:
> > I've just installed lxde and like the concept of it. I must set an
> > environment variable so I can run orca under the desktop. What file
> > should I place an export command in to export this variable to the lxde
> > desktop, to sa
hat file should I look into for exporting environment variables to
> lxde?
>
I recommend ~/.xsessionrc.
> Thanks very much
> Dan
>
--
Liam O'Toole
Birmingham, United Kingdom
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
am eg.
saving me from having to open a term, export the variable then run the
program from the term, I can just run the program from the desktop as
the var has already been exported at startup.
So what file should I look into for exporting environment variables to
lxde?
Thanks very muc
man start-stop-daemon: "Any arguments given after -- on the command line
are passed unmodified to the program being started."
I mean the environment variables that will be recognized by the invoked
daemon. I have solved this by adding NAME=xxx pairs preceding
start-stop-daemon:
; I'm not sure if you meant environment variables or command line
> arguments for the daemon. Here is an example of how to provide a
> command line arg to the udhcpc daemon. You just put a '--' in front.
man start-stop-daemon: "Any arguments given after -- on the command li
Yuwen Dai wrote:
> A daemon invoked by start-stop-daemon needs some extra enviroment
> variables. How to pass them to the daemon? Thanks in advance.
Typically in Debian start-stop-daemon is called from within the boot
time /etc/init.d/* scripts. Typically those scripts will source
customization
On Fri, 2007-07-13 at 11:13 +0800, Yuwen Dai wrote:
> Dear all,
>
> A daemon invoked by start-stop-daemon needs some extra enviroment
> variables. How to pass them to the daemon? Thanks in advance.
>
> Best regards,
> Yuwen
I'm not sure if you meant environment
Dear all,
A daemon invoked by start-stop-daemon needs some extra enviroment
variables. How to pass them to the daemon? Thanks in advance.
Best regards,
Yuwen
Dear all,
I installed distcc. Distcc is invoked by a script in init.d. In order to
use a cross compiler, the distcc needs to know the path of the cross
compiler and other environment variable. I put lines like:
export VAR=xxx
in the script. Seems no effect. What's the correct method?
Best r
/etc/environment
Thanks very much for the info, i've always been looking for something
like this !
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
1 - 100 of 230 matches
Mail list logo
