Re: "source" shell commands

[Tim X <timx@nospam.dev.null>]

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