CVS-Emacs not reading bash environments?

CVS-Emacs not reading bash environments?

[Sven Bretfeld]

[-- Attachment #1.1: Type: text/plain, Size: 914 bytes --]

Hi

I have a strange problem. I'm running Emacs 23.0.50.1 from CVS
(Debian-Snapshot) on a Debian Etch notebook with KDE.

Somehow Emacs doesn't recognize my default CVS repository (CVSROOT)
which is set in ~/.bashrc. 

M-x cvs-update aborts with the message:

Repository: ?????
Module:
Working dir: ~/somedir/

No CVSROOT specified! Please use the `-d' option.

The problem occurs when I start Emacs using an icon or the KDE
Startmenue or via Alt-F2. However, it works alright when I start Emacs
directly from the shell ($ emacs RET) or within the shell ($ emacs -nw
RET).

It's also working perfectly on my other two machines which have the
same setup but run an older Emacs snapshot (22.1.50.1).

How is it possible that Emacs doesn't read environments set in .bashrc
when started in the usual way programs are started in X? And how can I
solve the problem?

Thanks for help

Sven

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 152 bytes --]

_______________________________________________
help-gnu-emacs mailing list
help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs

Re: CVS-Emacs not reading bash environments?

[Andrea Vettorello]

On Dec 18, 2007 8:49 PM, Sven Bretfeld <sven.bretfeld@gmx.ch> wrote:

[...]

> It's also working perfectly on my other two machines which have the
> same setup but run an older Emacs snapshot (22.1.50.1).
>
> How is it possible that Emacs doesn't read environments set in .bashrc
> when started in the usual way programs are started in X? And how can I
> solve the problem?

FWIK, ~/.bashrc is run for (interactive) invocation of bash, you
should put env variables on ~/.profile, or eventually in ~/.xsession
(GDM needs to be explicitly configured to source users xsession files,
don't know about KDM)...


-- 
Andrea

Re: CVS-Emacs not reading bash environments?

[Tim X]

Sven Bretfeld <sven.bretfeld@gmx.ch> writes:

> Hi
>
> I have a strange problem. I'm running Emacs 23.0.50.1 from CVS
> (Debian-Snapshot) on a Debian Etch notebook with KDE.
>
> Somehow Emacs doesn't recognize my default CVS repository (CVSROOT)
> which is set in ~/.bashrc. 
>
> M-x cvs-update aborts with the message:
>
> Repository: ?????
> Module:
> Working dir: ~/somedir/
>
> No CVSROOT specified! Please use the `-d' option.
>
> The problem occurs when I start Emacs using an icon or the KDE
> Startmenue or via Alt-F2. However, it works alright when I start Emacs
> directly from the shell ($ emacs RET) or within the shell ($ emacs -nw
> RET).
>
> It's also working perfectly on my other two machines which have the
> same setup but run an older Emacs snapshot (22.1.50.1).
>
> How is it possible that Emacs doesn't read environments set in .bashrc
> when started in the usual way programs are started in X? And how can I
> solve the problem?
>
> Thanks for help
>
> Sven

At a guess, I'd say that your X session scripts are not running as login
scripts and therefore are not sourcing your .bash_profile, but KDE is
configured to open shells as a login shell (and hence they do source
.bash_profile).

There are numerous ways to change this -

1. Change your Xsession script to be a login shell
2. Change the command executed when you click on the icon to call a wrapper
script that first sources .bash_profile and then does an exec to emacs

I'm running gdm and normally change the first line of the gdm Xsession
script to be -login so that i know every program I execute via an icon or
menu (I run sawfish, not KDE) will inherit my environment. Some will advise
against this and there probably are good reasons not to do it, but I've
done it this way for nearly 20 years (originally, most Xsession scripts
were setup to be a login shell - not sure why/when this changed). Its
possible there may be security reasons, but as most people running Linux
these days are really running it as a desktop with just a single user, I
don't think you need to worry about some of the so called security concerns
quite as much (compared to a multi-user system with real multiple users).

Tim

-- 
tcross (at) rapttech dot com dot au