"source" shell commands

"source" shell commands

[Matthew Flaschen]

Is there an elisp function to "source" a shell file; i.e. an alternative
 to:

(shell-command (concat "source \"" (expand-file-name "~/.rc") "\""))

Matthew Flaschen

Re: "source" shell commands

[Tassilo Horn]

Matthew Flaschen <matthew.flaschen@gatech.edu> writes:

> Is there an elisp function to "source" a shell file; i.e. an
> alternative to:
>
> (shell-command (concat "source \"" (expand-file-name "~/.rc") "\""))

Sure.

--8<---------------cut here---------------start------------->8---
(defun mf-source (file)
  (interactive "f")
  (shell-command (concat "source \"" file "\"")))
--8<---------------cut here---------------end--------------->8---

Regards,
Tassilo
-- 
VI VI VI - The Roman Number Of The Beast

Re: "source" shell commands

[David Kastrup]

Tassilo Horn <tassilo@member.fsf.org> writes:

> Matthew Flaschen <matthew.flaschen@gatech.edu> writes:
>
>> Is there an elisp function to "source" a shell file; i.e. an
>> alternative to:
>>
>> (shell-command (concat "source \"" (expand-file-name "~/.rc") "\""))
>
> Sure.
>
> --8<---------------cut here---------------start------------->8---
> (defun mf-source (file)
>   (interactive "f")
>   (shell-command (concat "source \"" file "\"")))
> --8<---------------cut here---------------end--------------->8---

Quoting is always good for trouble.  I'd rather use

(defun mf-source (file)
  (interactive "f")
  (call-process shell-file-name nil nil nil "source" file))

assuming that you don't care about the output.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: "source" shell commands

[Barry Margolin]

In article <85wt16btg5.fsf@lola.goethe.zz>, David Kastrup <dak@gnu.org> 
wrote:

> Tassilo Horn <tassilo@member.fsf.org> writes:
> 
> > Matthew Flaschen <matthew.flaschen@gatech.edu> writes:
> >
> >> Is there an elisp function to "source" a shell file; i.e. an
> >> alternative to:
> >>
> >> (shell-command (concat "source \"" (expand-file-name "~/.rc") "\""))
> >
> > Sure.
> >
> > --8<---------------cut here---------------start------------->8---
> > (defun mf-source (file)
> >   (interactive "f")
> >   (shell-command (concat "source \"" file "\"")))
> > --8<---------------cut here---------------end--------------->8---
> 
> Quoting is always good for trouble.  I'd rather use
> 
> (defun mf-source (file)
>   (interactive "f")
>   (call-process shell-file-name nil nil nil "source" file))
> 
> assuming that you don't care about the output.

First of all, shells don't take a command line to execute as arguments.  
Take a look at what happens if you try it from the command line:

$ bash source .bashrc
source: source: No such file or directory

You can do it with the -c option, but then they expect the command to be 
in a single argument:

(call-process shell-file-name nil nil nil 
              "-c" (format "source '%s'" file))

Second, the point of "sourcing" is to execute the commands in the 
current process's context.  Since call-process and shell-command both 
execute a child process, nothing that occurs in the sourced script will 
have any effect on the emacs process.  So even if you get the syntax 
right, it won't do anything different from executing the script normally.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Re: "source" shell commands

[Matthew Flaschen]

Barry Margolin wrote:
> In article <85wt16btg5.fsf@lola.goethe.zz>, David Kastrup <dak@gnu.org> 
> wrote:
> 
>> Tassilo Horn <tassilo@member.fsf.org> writes:
>>
>>> Matthew Flaschen <matthew.flaschen@gatech.edu> writes:
>>>
>>>> Is there an elisp function to "source" a shell file; i.e. an
>>>> alternative to:
>>>>
>>>> (shell-command (concat "source \"" (expand-file-name "~/.rc") "\""))
>>> Sure.
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> (defun mf-source (file)
>>>   (interactive "f")
>>>   (shell-command (concat "source \"" file "\"")))
>>> --8<---------------cut here---------------end--------------->8---
>> Quoting is always good for trouble.  I'd rather use
>>
>> (defun mf-source (file)
>>   (interactive "f")
>>   (call-process shell-file-name nil nil nil "source" file))
>>
>> assuming that you don't care about the output.
> 
> First of all, shells don't take a command line to execute as arguments.  
> Take a look at what happens if you try it from the command line:
> 
> $ bash source .bashrc
> source: source: No such file or directory
> 
> You can do it with the -c option, but then they expect the command to be 
> in a single argument:
> 
> (call-process shell-file-name nil nil nil 
>               "-c" (format "source '%s'" file))
> 
> Second, the point of "sourcing" is to execute the commands in the 
> current process's context.  Since call-process and shell-command both 
> execute a child process, nothing that occurs in the sourced script will 
> have any effect on the emacs process.  So even if you get the syntax 
> right, it won't do anything different from executing the script normally.

Thanks.  I realized this after I asked the question.  Is there any way I
could import the variables after?  I found
shell-copy-environment-variable but I reall want to copy *all* of them
(for when I start emacs from outside the shell).

Matt Flaschen

Re: "source" shell commands

[Matthew Flaschen]

Matthew Flaschen wrote:
> Thanks.  I realized this after I asked the question.  Is there any way I
> could import the variables after?  I found
> shell-copy-environment-variable but I reall want to copy *all* of them
> (for when I start emacs from outside the shell).

Since I only really need JAVA_HOME, I'm just setting that manually with
setenv.

Matt Flaschen

Re: "source" shell commands

[Tim X]

Matthew Flaschen <matthew.flaschen@gatech.edu> writes:

> Is there an elisp function to "source" a shell file; i.e. an alternative
>  to:
>
> (shell-command (concat "source \"" (expand-file-name "~/.rc") "\""))
>
> Matthew Flaschen
>
>

Hi Matt,

just wondering why you would want this? The point of sourcing a shell file is
to allow for the file to execute in the current (callers) shell environment.
For example, to allow all subsequent sub-shells to inherit from that parent -
useful for setting envrionment variables etc. 

However, I cannot see this being of any real use from inside emacs. No matter
what way you call it, emacs will spawn a sub process to execute the command.
Once it exits, everything is lost. However, I'll readily admit I may be missing
some application/reason and am just curious. 

To answer your question, there are no existing commands that I know of which
will do what you want. However, it wold only take about 5 lines of elisp to
create your own. 

Tim

-- 
tcross (at) rapttech dot com dot au

Re: "source" shell commands

[Tim X]

Matthew Flaschen <matthew.flaschen@gatech.edu> writes:

> Barry Margolin wrote:
>> In article <85wt16btg5.fsf@lola.goethe.zz>, David Kastrup <dak@gnu.org> 
>> wrote:
>> 
>>> Tassilo Horn <tassilo@member.fsf.org> writes:
>>>
>>>> Matthew Flaschen <matthew.flaschen@gatech.edu> writes:
>>>>
>>>>> Is there an elisp function to "source" a shell file; i.e. an
>>>>> alternative to:
>>>>>
>>>>> (shell-command (concat "source \"" (expand-file-name "~/.rc") "\""))
>>>> Sure.
>>>>
>>>> --8<---------------cut here---------------start------------->8---
>>>> (defun mf-source (file)
>>>>   (interactive "f")
>>>>   (shell-command (concat "source \"" file "\"")))
>>>> --8<---------------cut here---------------end--------------->8---
>>> Quoting is always good for trouble.  I'd rather use
>>>
>>> (defun mf-source (file)
>>>   (interactive "f")
>>>   (call-process shell-file-name nil nil nil "source" file))
>>>
>>> assuming that you don't care about the output.
>> 
>> First of all, shells don't take a command line to execute as arguments.  
>> Take a look at what happens if you try it from the command line:
>> 
>> $ bash source .bashrc
>> source: source: No such file or directory
>> 
>> You can do it with the -c option, but then they expect the command to be 
>> in a single argument:
>> 
>> (call-process shell-file-name nil nil nil 
>>               "-c" (format "source '%s'" file))
>> 
>> Second, the point of "sourcing" is to execute the commands in the 
>> current process's context.  Since call-process and shell-command both 
>> execute a child process, nothing that occurs in the sourced script will 
>> have any effect on the emacs process.  So even if you get the syntax 
>> right, it won't do anything different from executing the script normally.
>
> Thanks.  I realized this after I asked the question.  Is there any way I
> could import the variables after?  I found
> shell-copy-environment-variable but I reall want to copy *all* of them
> (for when I start emacs from outside the shell).
>

I doubt shell-copy-environment-variable will work either. As soon as the sub
process that executes the "source file" has exited, I think that envrionment is
gone. 

I'm curious, how are you starting emacs "from outside the shell"? Are you
setting your login shell to be /usr/bin/emacs or are you doing an exec emacs in
your .Xsession? I'm having problems understanding how you could start outside
the shell - you could replace the shell with exec, but I cannot see how you
would be starting outside a shell of some description. 

The only thing I can think of is that your executing emacs from a menu or
something similar within X windows and you are finding none of your basic
environment settings are taking effect. If this is the case, there are a couple
solutions. The first and easiest is to change the shell that executes your
.Xsession (or equivalent) to a login shell. Different systems do this slightly
differently, but it generally isn't hard to track down. This is what I tend to
do as it means the root of all other shells (including xterms) that are spawned
from that shell will have my login environment settings. 

You could probably just put a source blah in your .Xsession (or equivalent),
though I've not tried this an am not sure what impace the 'exec' would have -
hsould be fine.

You could wrap your call to emacs inside a shell script and source the file
prior to executing emacs. Emacs will then inherit that envrionment. You would
then bind that script instead of emacs itself into any menus or 'run'
mechanisms.

Tim

-- 
tcross (at) rapttech dot com dot au

Re: "source" shell commands

[Matthew Flaschen]

Tim X wrote:
> However, I cannot see this being of any real use from inside emacs. No matter
> what way you call it, emacs will spawn a sub process to execute the command.
> Once it exits, everything is lost. However, I'll readily admit I may be missing
> some application/reason and am just curious. 

It's JDE.  I described the apparent problem earlier onlist, but just
figured out the real issue.  The full JDE will only work with Classpath
if the JAVA_HOME variable is set to "/usr/lib/jvm/java-gcj" .  I decided
to just manually use setenv .

Matthew Flaschen

Re: "source" shell commands

[Matthew Flaschen]

Tim X wrote:
> Matthew Flaschen <matthew.flaschen@gatech.edu> writes:
> 
>> Barry Margolin wrote:
>>> In article <85wt16btg5.fsf@lola.goethe.zz>, David Kastrup <dak@gnu.org> 
>>> wrote:
>>>
>>>> Tassilo Horn <tassilo@member.fsf.org> writes:
>>>>
>>>>> Matthew Flaschen <matthew.flaschen@gatech.edu> writes:
>>>>>
>>>>>> Is there an elisp function to "source" a shell file; i.e. an
>>>>>> alternative to:
>>>>>>
>>>>>> (shell-command (concat "source \"" (expand-file-name "~/.rc") "\""))
>>>>> Sure.
>>>>>
>>>>> --8<---------------cut here---------------start------------->8---
>>>>> (defun mf-source (file)
>>>>>   (interactive "f")
>>>>>   (shell-command (concat "source \"" file "\"")))
>>>>> --8<---------------cut here---------------end--------------->8---
>>>> Quoting is always good for trouble.  I'd rather use
>>>>
>>>> (defun mf-source (file)
>>>>   (interactive "f")
>>>>   (call-process shell-file-name nil nil nil "source" file))
>>>>
>>>> assuming that you don't care about the output.
>>> First of all, shells don't take a command line to execute as arguments.  
>>> Take a look at what happens if you try it from the command line:
>>>
>>> $ bash source .bashrc
>>> source: source: No such file or directory
>>>
>>> You can do it with the -c option, but then they expect the command to be 
>>> in a single argument:
>>>
>>> (call-process shell-file-name nil nil nil 
>>>               "-c" (format "source '%s'" file))
>>>
>>> Second, the point of "sourcing" is to execute the commands in the 
>>> current process's context.  Since call-process and shell-command both 
>>> execute a child process, nothing that occurs in the sourced script will 
>>> have any effect on the emacs process.  So even if you get the syntax 
>>> right, it won't do anything different from executing the script normally.
>> Thanks.  I realized this after I asked the question.  Is there any way I
>> could import the variables after?  I found
>> shell-copy-environment-variable but I reall want to copy *all* of them
>> (for when I start emacs from outside the shell).
>>
> 
> I doubt shell-copy-environment-variable will work either. As soon as the sub
> process that executes the "source file" has exited, I think that envrionment is
> gone. 
> 
> I'm curious, how are you starting emacs "from outside the shell"?

Maybe I'm missing something big.  I'm using KDE.  Sometimes I start
emacs from an xterm (Konsole actually), but sometimes I just click a
shortcut.

> The first and easiest is to change the shell that executes your
> .Xsession (or equivalent) to a login shell.

Any idea how I would do that in Ubuntu (gNewSense really)?

Matthew Flaschen

Re: "source" shell commands

[Peter Dyballa]

Am 25.03.2007 um 01:08 schrieb Matthew Flaschen:

> Since I only really need JAVA_HOME, I'm just setting that manually  
> with
> setenv.

All you need to do, is to make sure that when you log-in this  
environment variable gets set. In case of (t)csh it's simple: /etc/ 
csh.login is probably read, otherwise ~/.login. In case of bash it is  
more complicated since bash also checks whether this shell is  
interactive or not, to be a login shell is not the only criterion.  
You could think of putting JAVA_HOME into /etc/.profile or into / 
etc/.bashrc or both – or into your private versions ~/.profile and/or  
~/.bashrc.

JAVA_HOME probably is an environment variable that is not specific to  
some user but is of system-wide meaning.

You can check with ps or better pstree (pstree -p $$) how you logged in.

You can put some shell script into some menu, that just prints the  
environment it sees. When you make this script start with

	#!/bin/csh -f

then this csh does not read in or source any RC files, it really only  
sees the existing environment and report this to some file.


You can also put

	echo "something specific"

or

	echo "something specific" > some specific file or /dev/console

to be informed which RC files are used during a particular action, or  
menu driven event.

--
Greetings

   Pete

If you're not confused, you're not paying attention.

Re: "source" shell commands

[Matthew Flaschen]

Peter Dyballa wrote:
> 
> Am 25.03.2007 um 01:08 schrieb Matthew Flaschen:
> 
>> Since I only really need JAVA_HOME, I'm just setting that manually with
>> setenv.
> 
> All you need to do, is to make sure that when you log-in this
> environment variable gets set. In case of (t)csh it's simple:
> /etc/csh.login is probably read, otherwise ~/.login. In case of bash it
> is more complicated since bash also checks whether this shell is
> interactive or not, to be a login shell is not the only criterion. You
> could think of putting JAVA_HOME into /etc/.profile or into /etc/.bashrc
> or both – or into your private versions ~/.profile and/or ~/.bashrc.
> 
> JAVA_HOME probably is an environment variable that is not specific to
> some user but is of system-wide meaning.
> 
> You can check with ps or better pstree (pstree -p $$) how you logged in.

Apparently bash.  However, ~/.bashrc already sources ~/.rc , which
includes JAVA_HOME .  It was my impression that bash *always* read
~/.bashrc .  Should I source ~/.rc in ~/.profile instead?

Matthew Flaschen

Re: "source" shell commands

[Tim X]

Matthew Flaschen <matthew.flaschen@gatech.edu> writes:

>
>> The first and easiest is to change the shell that executes your
>> .Xsession (or equivalent) to a login shell.
>
> Any idea how I would do that in Ubuntu (gNewSense really)?
>
> Matthew Flaschen
>
>

Well, I've never really run KDE, but all the different window managers pretty
much follow a similar pattern AFAIK. I'm not running Ubuntu, but plain Debian,
so I'll assume they are pretty similar. However, I do know that KDE does have
some 'quirks' that make life a bit more tricky in some situations (for example,
setting app colours and/or geometry is not as easy as just setting values in
.Xdefaults/Xresources - you have to do some settings inside the KDE 'control
panel'. 

The trick is to identify which of the startup scripts are the one which spawns
the window manager - normally this is done with a 'exec window_manager'.
Unfortunately, I can't rmember which one it is just now (and I've heavily
customized my startup on my home machine). From memory it is one of

/etc/gdm/Xsession (if your running gdm)
/etc/X11/xdm/Xsession (if your running xdm)

If you change one of these to run as a login shell, then your .bash_profile (or
whatever) will be executed. This script then sources the client startup scripts
(i.e. at its most basic, this could be just starting an xterm, but normally it
will start a window manager.). As the window manager is started as a subprocess
of your login shell, its environment inherits your login environment and as all
the processes it starts (such as emacs) is a subprocess of that, they will also
inherit your environment settings. 

If you can't work out which file it is, let me know and I'll have a look at my
work machine (which has not been 'customized' - I may even be able to look at
one of my co-workers machines as quite a few of them run Ubuntu. 

HTH 

Tim

P.S. Back in the bad old days when I use to do java development and was using
JDE, this is exactly what I did to ensure I could just start emacs from the
window manager (without first starting an xterm and sourcing .bash_profile. In
those days I was running RH, but from memory, that was when I first had to work
this out)

PPS - now, I don't have to struggle with that horrible java stuff. Now I really
appreciate the simple environment of perl and ruby (and for fun CL). The only
constant over the past 12 years has been emacs!


-- 
tcross (at) rapttech dot com dot au

Re: "source" shell commands

[Peter Dyballa]

Am 25.03.2007 um 12:55 schrieb Matthew Flaschen:

> Apparently bash.  However, ~/.bashrc already sources ~/.rc , which
> includes JAVA_HOME .  It was my impression that bash *always* read
> ~/.bashrc .

As I recommended: put an

	echo " Hi, Matt! It's me, your ~/.bashrc. Remember me, still?" > / 
dev/console

into your ~/.bashrc and see what you'll see.


What is pstree showing? For me, on Mac OS X, and launched from some  
menu, I get:

	pete 123 /\ pstree -p $$
	-+= 00001 root /sbin/launchd -v
	\-+- 01695 pete -bin/tcsh -i -c /usr/local/bin/emacs-23.0.0 - 
geometry  100x57+666+44
	   \-+- 01700 pete /usr/local/bin/emacs-23.0.0 -geometry 100x57+666+44
	     \-+= 01701 pete -bin/tcsh -i
	       \-+= 04001 pete pstree -p 1701
	         \--- 04002 root ps -axwwo user

An interactive tcsh stands at my beginning.


'Man bash,' in GNU Emacs, will reveal:

	• when invoked as a login shell, it will read /etc/profile,  
~/.bash_profile, ~/.bash_login, ~/.profile in that sequence;

	• when invoked as an interactive shell, that is no login shell, it  
will read ~/.bashrc;

	• when invoked with the name sh, it mimics the Bourne shell reading / 
etc/profile and ~/.profile, in that order;

	• when a login shell is finished, ~/.bash_logout is read.

There are constraints with environment variables like ENV or  
BASH_ENV. So even a non-interactive non-login bash can read (and  
execute) some RC files.

When the login bash hits the first of the many personal RC files, it  
only executes the first one. So, IMO, it's best to put everything  
personal in Bourne shell syntax into ~/.profile, which a Bourne shell  
or Bourne shell bash will read (and execute) also.

And read, not entirely, you have C-s, the *Man bash* buffer a few times!


> Should I source ~/.rc in ~/.profile instead?

No. Keep it simple, let bash do its job right.

--
Greetings

   Pete

Math illiteracy affects 7 out of every 5 Americans.

Re: "source" shell commands

[Tim X]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> Am 25.03.2007 um 12:55 schrieb Matthew Flaschen:
>
>> Apparently bash.  However, ~/.bashrc already sources ~/.rc , which
>> includes JAVA_HOME .  It was my impression that bash *always* read
>> ~/.bashrc .
>
> As I recommended: put an
>
> 	echo " Hi, Matt! It's me, your ~/.bashrc. Remember me, still?" > /
> dev/console
>
> into your ~/.bashrc and see what you'll see.
>

Better still, lets go back to basics and trace what exactly is getting
run/sourced and where. The reason I say this is that *most* GNU Linux systems
(and many Unix varieties) actually use /bin/sh to run the X session login/setup
scripts. This is why the values Matt has in his ~/.bashrc are not being
executed. 

The simplest solution I've found is to change the Xsession script that sets up
your session to be a bash login shell - then ~/.bash_profiel (or ~/.profile)
will get sourced prior to the window manager being started and everything that
is then spawned by the window manager (using menus, 'run' boxes or start icons)
will inherit the users login env. 

The point Pete mentioned about JAVA_HOME being a site wide variable is quite
valid. It would be reasonable to stick the JAVA_HOME environment in
/etc/profile as long as all the paths are also site wide/readable (i.e. java
classpath does not have user directories in it.)

Tim

-- 
tcross (at) rapttech dot com dot au

Re: "source" shell commands

[Matthew Flaschen]

Peter Dyballa wrote:
> 
> Am 25.03.2007 um 12:55 schrieb Matthew Flaschen:
> 
> What is pstree showing? For me, on Mac OS X, and launched from some
> menu, I get:
> 
>     pete 123 /\ pstree -p $$
>     -+= 00001 root /sbin/launchd -v
>     \-+- 01695 pete -bin/tcsh -i -c /usr/local/bin/emacs-23.0.0
> -geometry  100x57+666+44
>        \-+- 01700 pete /usr/local/bin/emacs-23.0.0 -geometry 100x57+666+44
>          \-+= 01701 pete -bin/tcsh -i
>            \-+= 04001 pete pstree -p 1701
>              \--- 04002 root ps -axwwo user
> 
> An interactive tcsh stands at my beginning.

All I get from that (run from a VT) is

bash(12773)--pstree(12790)

Clearly, it's not showing the initial shell.

> When the login bash hits the first of the many personal RC files, it
> only executes the first one. So, IMO, it's best to put everything
> personal in Bourne shell syntax into ~/.profile, which a Bourne shell or
> Bourne shell bash will read (and execute) also.

I moved ~/.bashrc to ~/.bash_profile .  I primarily use zsh , so I don't
want to use generic profile.

>> Should I source ~/.rc in ~/.profile instead?
> No. Keep it simple, let bash do its job right.

That's not desirable, because ~/.rc is supposed to be usable by multiple
shells.

Thanks,

Matt Flaschen

Re: "source" shell commands

[Matthew Flaschen]

Tim X wrote:
> The simplest solution I've found is to change the Xsession script that sets up
> your session to be a bash login shell - then ~/.bash_profiel (or ~/.profile)
> will get sourced prior to the window manager being started and everything that
> is then spawned by the window manager (using menus, 'run' boxes or start icons)
> will inherit the users login env. 

I'm sorry.  I don't understand what you mean here.  Exactly what would I
have to modify to do this?

Matt Flaschen

Re: "source" shell commands

[Tassilo Horn]

Matthew Flaschen <matthew.flaschen@gatech.edu> writes:

Hi Matthew,

>> I'm curious, how are you starting emacs "from outside the shell"?
>
> Maybe I'm missing something big.  I'm using KDE.  Sometimes I start
> emacs from an xterm (Konsole actually), but sometimes I just click a
> shortcut.

KDE executes all files in ~/.kde/env/ on startup, so this is the place
to hook on for setting up an environment. I have a file ~/.profile for
doing that, and in ~/.kde/env/ theres:

,----
| heimdall@baldur ~> cd .kde/env/
| heimdall@baldur ~/./env> ls
| gpg-agent.sh*  source-profile.sh*
| heimdall@baldur ~/./env> cat source-profile.sh 
| #!/bin/sh
| 
| source ~/.profile
| heimdall@baldur ~/./env>
`----

Bye,
Tassilo
-- 
People sometimes  ask me if it  is a sin in  the Church of  Emacs to use
vi. Using a free  version of vi is not a sin; it  is a penance. So happy
hacking. (Richard M. Stallman)

Re: "source" shell commands

[Peter Dyballa]

Am 26.03.2007 um 02:44 schrieb Matthew Flaschen:

> I moved ~/.bashrc to ~/.bash_profile .  I primarily use zsh , so I  
> don't
> want to use generic profile.

What is your login shell? Is the shell you work in different from  
your login shell? Can you prepare your login shell to have an  
environment that contains, just after the moment in which you've  
input your password, all valuable and necessary environment variables?

>
>>> Should I source ~/.rc in ~/.profile instead?
>> No. Keep it simple, let bash do its job right.
>
> That's not desirable, because ~/.rc is supposed to be usable by  
> multiple
> shells.

OK. Can distinguish between interactive and non-interactive goodies?  
I mean: has the shell interpreter, that executes a shell script, to  
know all the shell functions and shell aliases you need for your more  
or less interactive doing?

--
Greetings

   Pete

The day Microsoft makes something that doesn't suck
is the day they start selling vacuum cleaners.
                                     Ernest Jan Plugge

Re: "source" shell commands

[Matthew Flaschen]

Tassilo Horn wrote:
> Matthew Flaschen <matthew.flaschen@gatech.edu> writes:
> 
> Hi Matthew,
> 
>>> I'm curious, how are you starting emacs "from outside the shell"?
>> Maybe I'm missing something big.  I'm using KDE.  Sometimes I start
>> emacs from an xterm (Konsole actually), but sometimes I just click a
>> shortcut.
> 
> KDE executes all files in ~/.kde/env/ on startup, so this is the place
> to hook on for setting up an environment. I have a file ~/.profile for
> doing that, and in ~/.kde/env/ theres:

Thanks!  I created a file ~/.kde/env/.kde_rc with just:

source ~/.rc

Then I removed that from everywhere else.  I think that will work fine.

Matthew Flaschen

Re: "source" shell commands

[Tassilo Horn]

Matthew Flaschen <matthew.flaschen@gatech.edu> writes:

Hi Mathew,

> Thanks!  I created a file ~/.kde/env/.kde_rc with just:
>
> source ~/.rc
>
> Then I removed that from everywhere else.  I think that will work
> fine.

I wouldn't be too sure. I think .kde_rc has to be executable and I
wouldn't omit the shebang.

So do 

  $ chmod a+x ~/.kde/env/.kde_rc

and add "#!/bin/sh" as first line of the file.

Bye,
Tassilo
-- 
My opinions may have changed, but not the fact that I am right.

Re: "source" shell commands

[Matthew Flaschen]

Tassilo Horn wrote:
> Matthew Flaschen <matthew.flaschen@gatech.edu> writes:
> 
> Hi Mathew,
> 
>> Thanks!  I created a file ~/.kde/env/.kde_rc with just:
>>
>> source ~/.rc
>>
>> Then I removed that from everywhere else.  I think that will work
>> fine.
> 
> I wouldn't be too sure. I think .kde_rc has to be executable and I
> wouldn't omit the shebang.
> 
> So do 
> 
>   $ chmod a+x ~/.kde/env/.kde_rc
> 
> and add "#!/bin/sh" as first line of the file.

Thank you very much.  I think I've got it figured out now.

Matt Flaschen

Re: "source" shell commands

[Matthew Flaschen]

Peter Dyballa wrote:
>> That's not desirable, because ~/.rc is supposed to be usable by multiple
>> shells.
> 
> OK. Can distinguish between interactive and non-interactive goodies?

I figured that out the hard way just before your email.  What I did is
break out the "interactive code" (aliases and function definitions) from
the environment variables.  The interactive stuff is now in ~/.rc , and
loaded by each shell (.bashrc and .zshrc).  The environment exports are
in ~/.env , which is sourced by ~/.kde/env/kde.sh

 I
> mean: has the shell interpreter, that executes a shell script, to know
> all the shell functions and shell aliases you need for your more or less
> interactive doing?

No it doesn't, as I've now grasped.  Nor does emacs or the rest of the
GUI apps, so it's better of separate.

Best,

Matthew Flaschen

Re: "source" shell commands

[Tim X]

Matthew Flaschen <matthew.flaschen@gatech.edu> writes:

> Tim X wrote:
>> The simplest solution I've found is to change the Xsession script that sets up
>> your session to be a bash login shell - then ~/.bash_profiel (or ~/.profile)
>> will get sourced prior to the window manager being started and everything that
>> is then spawned by the window manager (using menus, 'run' boxes or start icons)
>> will inherit the users login env. 
>
> I'm sorry.  I don't understand what you mean here.  Exactly what would I
> have to modify to do this?
>

Its difficult to be precise as things differ depending on the setup you have
and the display manager you are using. However, essentially, xdm and gdm, two
of the main display managers, have a script called (usually) Xsession. On many
systems, including Debian (and I therefore suspect Ubuntu) this script is not
run as a login script and is normally a /bin/sh script rather than /bin/bash. 

As it is not run as a login script, it doesn't source your ~/.profile (or
~/.bash_profile. This script also usually sources the client startup scripts
(either the system default ones or a 'customized' one which is usuallyy called
~/.Xsession or ~/.xsession. Under debian, if you have a .Xsession script, that
will be executed instead of the system defaults. (What determines exactly what
is executed is usually selected from a menu on the display manager login
screen. Common entries are "Failsafe", "Default", "Gnome", "Last Session" etc). 

Usually the last entry in the client script sourced by the system Xsession
script is something like

exec window_manager

which means the window manager process inherits the process the Xsession script
was running in. Once the window manager process exits, your X session exits and
control returns to the display manager. 

If the Xsession script is not running as a login shell and it has not sourced
your environment settings in ~/.profile (or whatever), none of these settings
are in effect for the window manager or any processes it spawns (such as when
you start an aplication from a menu). To fix this problem, you need to have
your .profile sourced *before* the window manager starts. The easiest way to do
this is to change the Xsession script to run as a login shell. On Debian, this
can easily be achieved by changing the first line from

/bin/sh

to

/bin/bash --login

The script will then source yor startup files before it starts executing and
the window manager will inherit this environment. As environment variables are
exported to sub shells, etc, anything that is started from within the window
manager will inherit all of these environment variables. 

As mentioned in an earlier post, my system is heavily customized, so I'm
working from memory a bit regarding exactly which file to change. It also
depends on the display manager and I'm not familiar with KDE, so I can't be
precise as to exactly which file it would be, but the basic principle is the
same - find the script that sources the session setup scripts and/or runs the
window manager and make it a login shell rather than just a normal shell. 

For xdm I think the file is in /etc/X11/xdm/Xsession and for gdm I think the
file is /etc/gdm/Xsession. (Note that Debian also has an /etc/X11/Xsession and
an /etc/X11/Xsession.d directory of files. These are *not* the ones you need to
change. 

HTH

Tim

P.S. Years ago, when I first started using X windows (late 80s), things were
somewhat simpler. The user would have an .Xsession file that contained all the
startup stuff they wanted done and then do an exec at the end to start the wm.
Then things changed to make it easier to maintain a default setup rather than
require the user to manage it. At this time, the default was to run things as a
login shell. This later changed and I've never really found out why. There is
probably a god reason and possibly there are some issues with doing this, but
I've never had a problem in 20 years (maybe I'm just lucky). 

PPS Another thing you could try which may work is if your system has a
/etc/X11/Xsession.d directory, you could try dropping a new file in there which
just sources the user's ~/.bash_profile or ~/.profile. While this may work
fine on a single user box, it could cause issues on a multi-user system as not
everyone runs bash as their login shell. 
-- 
tcross (at) rapttech dot com dot au