run/load a lisp script before user init file

run/load a lisp script before user init file

[Jarek Czekalski]

Hi

My specific problem is about Emacspeak. It has a file emacspeak-setup.el 
and the manual says it should be loaded before user init script.

The goal is achieved by probing for a user file in a shell script 
(emacspeak) which later runs the command:

emacs -q -l $path/emacspeak-setup.el -l $userInitFile

It's not perfect, because -q switch causes customizing variables impossible.

The other suggestion from the manual is to append the "load" command at 
the top of the user script. I'm not choosing this solution, because I 
prepare an installer for Windows version of Emacspeak and such action 
would affect only one user.

After the installation the user should be able to choose whether he 
wants to run emacs with or without emacspeak. Having a script that runs 
emacs with emacspeak seems to be the right solution.

What would you advice to resolve the issue?

Thanks,
Jarek

Re: run/load a lisp script before user init file

[Eli Zaretskii]

> Date: Mon, 07 Oct 2013 17:24:38 +0200
> From: Jarek Czekalski <jarekczek@poczta.onet.pl>
> 
> My specific problem is about Emacspeak. It has a file emacspeak-setup.el 
> and the manual says it should be loaded before user init script.
> 
> The goal is achieved by probing for a user file in a shell script 
> (emacspeak) which later runs the command:
> 
> emacs -q -l $path/emacspeak-setup.el -l $userInitFile
> 
> It's not perfect, because -q switch causes customizing variables impossible.
> 
> The other suggestion from the manual is to append the "load" command at 
> the top of the user script. I'm not choosing this solution, because I 
> prepare an installer for Windows version of Emacspeak and such action 
> would affect only one user.
> 
> After the installation the user should be able to choose whether he 
> wants to run emacs with or without emacspeak. Having a script that runs 
> emacs with emacspeak seems to be the right solution.
> 
> What would you advice to resolve the issue?

Site init file looks like what you want.  Read about it in the "Init
File" node of the Emacs User Manual.

Re: run/load a lisp script before user init file

[Jarek Czekalski]

W dniu 10/07/2013 06:43 PM, Eli Zaretskii pisze:
> Site init file looks like what you want. Read about it in the "Init 
> File" node of the Emacs User Manual. 

I read the startup procedure. However it still does not seem a clean 
approch. You suggest that I should add a line

(load "emacspeak-loder")

to the site-start, right? But when someone removes emacspeak from 
system, emacs will stop to load correctly. Not nice.

So should I place some multi-line code in site-start, so that it be safe 
to execute? But this is not so easy to do from installer. So this may be 
dangerous too.

What looks interesting is site-start.d directory in Debian. Placing a 
file there could be what I am looking for. But I guess this is not emacs 
solution, but Debian solution. Nothing about site-start.d in emacs 
startup info.

What someone was trying before is to start a script from a command line. 
But we don't have a possibility to specify custom site-start file there. 
What a pity...

Again, does there exist any clean solution? Is there something that I 
could place instead of "load" to make the loading safe in case of a 
missing file? Is there something we could introduce to emacs to make 
things more comfortable?

Jarek

Re: run/load a lisp script before user init file

[Eli Zaretskii]

> Date: Mon, 07 Oct 2013 20:42:43 +0200
> From: Jarek Czekalski <jarekczek@poczta.onet.pl>
> 
> W dniu 10/07/2013 06:43 PM, Eli Zaretskii pisze:
> > Site init file looks like what you want. Read about it in the "Init 
> > File" node of the Emacs User Manual. 
> 
> I read the startup procedure. However it still does not seem a clean 
> approch. You suggest that I should add a line
> 
> (load "emacspeak-loder")
> 
> to the site-start, right? But when someone removes emacspeak from 
> system, emacs will stop to load correctly. Not nice.

If that's the problem, you can detect the presence of emacspeak first,
or wrap the load in ignore-errors or some such.

IOW, this is a problem that is much easier to solve in any number of
ways.

> So should I place some multi-line code in site-start, so that it be safe 
> to execute? But this is not so easy to do from installer. So this may be 
> dangerous too.

I don't see why would this be dangerous, especially on Windows.
Chances of such a file to exist on Windows are nil.

> Again, does there exist any clean solution?

AFAICS, what I suggest above is clean.

Re: run/load a lisp script before user init file

[Jarek Czekalski]

W dniu 10/07/2013 09:00 PM, Eli Zaretskii pisze:
>> So should I place some multi-line code in site-start, so that it be safe
>> to execute? But this is not so easy to do from installer. So this may be
>> dangerous too.
> I don't see why would this be dangerous, especially on Windows.

Appending to the end of the file is a piece of cake. But I have to 
consider also a reinstallation case. A case that the file was edited and 
then reinstallation happens. So I need to find my previous code, erase 
it. What a complicated process. And this complication makes a lot of 
error opportunities. Any error in this file makes emacs not start at 
all. That's dangerous.

> Chances of such a file to exist on Windows are nil.

Does that mean I should overwrite the file not caring who used it and 
what for? That's what you call a "clean solution"? :)

Jarek

Re: run/load a lisp script before user init file

[Eli Zaretskii]

> Date: Mon, 07 Oct 2013 21:37:40 +0200
> From: Jarek Czekalski <jarekczek@poczta.onet.pl>
> 
> Appending to the end of the file is a piece of cake. But I have to 
> consider also a reinstallation case. A case that the file was edited and 
> then reinstallation happens.

What's a "reinstallation"?

> So I need to find my previous code, erase it.

No, you don't.  You could use 'require' instead of 'load'.

> What a complicated process. And this complication makes a lot of 
> error opportunities. Any error in this file makes emacs not start at 
> all. That's dangerous.

Once again, if you wrap this with ignore-errors, Emacs will always
start.  No danger here.

> Does that mean I should overwrite the file not caring who used it and 
> what for? That's what you call a "clean solution"? :)

I suggested what I could.  If you want something else, perhaps others
could suggest something you will like.

Re: run/load a lisp script before user init file

[Stefan Monnier]

> What's a "reinstallation"?

Installing his package a second time.

>> So I need to find my previous code, erase it.
> No, you don't.  You could use 'require' instead of 'load'.

He's talking about adding the "(load ...)" string into the site-load.el
file.  He clearly doesn't want to add it a second time if it's already
present due to some pre-existing installation.  But using "(require
...)" makes no difference to the problem.  Especially because he want to
be able to *replace* the string added by a previous install.

>> What a complicated process. And this complication makes a lot of
>> error opportunities. Any error in this file makes emacs not start at
>> all. That's dangerous.
> Once again, if you wrap this with ignore-errors, Emacs will always
> start.  No danger here.

If the removal/replacement messes things up, the site-load.el might end
up syntactically invalid.  No amount of `ignore-errors' in there will help.

IOW he simply needs to add the simplest code possible (e.g. a single
`load' or `require' line, with the `noerror' arg set to non-nil), so
it's easy to remove.


        Stefan

Re: run/load a lisp script before user init file

[Jarek Czekalski]

Guys, thank you for the attention. During the night I came up
with a new idea, the change in Emacs:

**Execute all site-start files, not the first one on the path**

Pros:

- There is no single universal location for site-start file. Different
   developers may choose different locations, which would result in
   ignoring the file of one of them. Add to that the fact that subdir
   execution may change the load path. This problem that would be removed.

- Developers would have an easy way to append some code to the
   site-start code (my case).

- Some installation manuals advices: "insert the following lines into
   your init file" could be replaced with an elegant install procedure

Cons:

- If there is a mess on a system and it contains more than 1
   site-start file, there may be surprising effects after Emacs
   upgrade.

Is it acceptable? Are there any other cons I don't see? This one
doesn't look serious.

Jarek

Re: run/load a lisp script before user init file

[Kevin Rodgers]

On 10/7/13 1:00 PM, Eli Zaretskii wrote:
>> Date: Mon, 07 Oct 2013 20:42:43 +0200
>> From: Jarek Czekalski<jarekczek@poczta.onet.pl>
>>
>> W dniu 10/07/2013 06:43 PM, Eli Zaretskii pisze:
>>> Site init file looks like what you want. Read about it in the "Init
>>> File" node of the Emacs User Manual.
>>
>> I read the startup procedure. However it still does not seem a clean
>> approch. You suggest that I should add a line
>>
>> (load "emacspeak-loder")
>>
>> to the site-start, right? But when someone removes emacspeak from
>> system, emacs will stop to load correctly. Not nice.
>
> If that's the problem, you can detect the presence of emacspeak first,
> or wrap the load in ignore-errors or some such.
>
> IOW, this is a problem that is much easier to solve in any number of
> ways.

E.g.

(when (not (load "emacspeak-loader" t))
   (display-warning 'initialization "Emacspeak not loaded"))

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: run/load a lisp script before user init file

[Stephen J. Turnbull]

Jarek Czekalski writes:

 > **Execute all site-start files, not the first one on the path**

 > Cons:

It doesn't actually solve any problems, and makes some of them harder
to solve (eg, uninstall).  It's ugly (why should the site-start
library be treated differently from any other?[1])  It's not general
(I suspect that at the point where site-start is run, the load-path is
very short.)

What's wrong with the obvious solution?  Like this:

1. Install your script on the load-path in some application-specific file.
2. Compile it.
3. Find site-start.  If it doesn't exist yet, create an empty one.
4. Check for the presence of "(require 'my-script-file)" in
   site-start.  If it's there, you're done.  (This can be done
   accurately by using the Lisp reader to read site-start.)
5. If it's not there, append it to site-start.

Footnotes: 
[1]  Yes, I know about the package-specific auto-autoloads and
custom-load files in XEmacs.  Lesser of two uglies but still ugly.

Re: run/load a lisp script before user init file

[Harald Hanche-Olsen]

["Stephen J. Turnbull" <stephen@xemacs.org> (2013-10-08 06:27:04 UTC)]

> Jarek Czekalski writes:
> 
>  > **Execute all site-start files, not the first one on the path**
> 
>  > Cons:
> 
> It doesn't actually solve any problems, and makes some of them harder
> to solve (eg, uninstall).  It's ugly (why should the site-start
> library be treated differently from any other?[1])

If one were to think along these lines, wouldn't it make more sense to
have a directory "site-start.d" where packages can put their own
initialization code, each in its own file? It makes uninstalling
trivial, for one thing.

- Harald

Re: run/load a lisp script before user init file

[Jarek Czekalski]

W dniu 2013-10-08 08:27, Stephen J. Turnbull pisze:
> It doesn't actually solve any problems, and makes some of them harder
> to solve (eg, uninstall).

I thought it makes uninstall easier. Just erase the file you added. I 
mean that during install I add the file site-lisp/emacspeak/site-start.el.

>    It's ugly (why should the site-start
> library be treated differently from any other?[1])

I don't think of site-start as of a library. Rather as a start-up 
script. Let's go back to Debian Emacs. Why did they invent site-start.d 
directory? To circumvent the lack of the feature I describe. So let's 
call site-start a script and the problems gone :)

>    It's not general
> (I suspect that at the point where site-start is run, the load-path is
> very short.)

No. On Debian it already contains dozens of paths.

> What's wrong with the obvious solution?  Like this:
>
> 1. Install your script on the load-path in some application-specific file.
> 2. Compile it.
> 3. Find site-start.  If it doesn't exist yet, create an empty one.

Easy to say: "Find site-start". How? Let's have a difficult example: 
Debian. It places site-start.el file in /etc/emacs. It is a template, 
empty file with comments. When I inspect the load-path at site-start 
moment, the beginning of load-path is as follows: /etc/emacs23 
/etc/emacs. So which place should I choose for *my* site-start? And what 
if the next dev chooses /etc/emacs23, because he would somehow know how 
to locate this better place.

> 4. Check for the presence of "(require 'my-script-file)" in
>     site-start.  If it's there, you're done.  (This can be done
>     accurately by using the Lisp reader to read site-start.)
> 5. If it's not there, append it to site-start.
>

The solution you suggest is not bad. I'll fallback to it :)

Jarek

Re: run/load a lisp script before user init file

[Stephen J. Turnbull]

Harald Hanche-Olsen writes:

 > If one were to think along these lines, wouldn't it make more sense to
 > have a directory "site-start.d" where packages can put their own
 > initialization code, each in its own file? It makes uninstalling
 > trivial, for one thing.

site-start is a Lisp file; you can already have that if you want.

Also, in XEmacs and SXEmacs you can just put the needed code in an
autoload cookie in the package itself, and it automatically gets
executed when loading the auto-autoloads.  I don't know if there is a
similar feature for ELPA packages, but I imagine there is.  (In
XEmacs, this code actually gets executed before site-start IIRC.)

Jarek Czekalski writes:

 > W dniu 2013-10-08 08:27, Stephen J. Turnbull pisze:
 >> It doesn't actually solve any problems, and makes some of them harder
 >> to solve (eg, uninstall).

 > I thought it makes uninstall easier. Just erase the file you
 > added. I mean that during install I add the file
 > site-lisp/emacspeak/site-start.el.

A complete uninstall, yes, but how about disable (you can't remove the
site-start file if it contains much code) or uninstall-but-leave-conf
(you don't want to leave the site-start file behind because it will
cause startup errors)?  You could probably make it work, but really,
there are better approaches.

 >> It's ugly (why should the site-start library be treated differently
 >> from any other?[1])

 > I don't think of site-start as of a library.

It's not your choice, and it's not really Emacs's, either.  site-start
is an ancient interface, and sufficiently well-established that
changing it would very likely surprise people.  It would also be a
PITA: you can't use locate-library to find the file you want.  The
site-start.d approach is much better, as is the auto-autoloads
approach.  (Note that although the name "auto-autoloads" is shared by
all packages and core in XEmacs, it's always a generated file, so you
don't want to edit it anyway.  The right appropriate is to put the
initialization code in a function, and then call that.  To find that
code you use find-function.)

 >> It's not general (I suspect that at the point where site-start is
 >> run, the load-path is very short.)

 > No. On Debian it already contains dozens of paths.

Debian already has site-start.d, so who cares about Debian?  You're
proposing a change to the upstream Emacs, which is a different matter.
And on the upstream Emacs, I would guess there are only 5-10 paths,
and they wouldn't be appropriate locations for a 3rd-party start file.

 >> What's wrong with the obvious solution?  Like this:
 >>
 >> 1. Install your script on the load-path in some application-specific file.
 >> 2. Compile it.
 >> 3. Find site-start.  If it doesn't exist yet, create an empty one.

 > Easy to say: "Find site-start". How? Let's have a difficult
 > example:  Debian.

Again, forget Debian.  Debian has its own Emacs Policy, and you'd want
to conform to that rather than try to override it from upstream.

In any case, it's easy to find the right site-start:

  emacs -batch -q -no-site-file -eval '(prin1 (locate-library "site-start"))'

should do the trick if it exists.

Re: run/load a lisp script before user init file

[Jarek Czekalski]

W dniu 2013-10-08 15:09, Stephen J. Turnbull pisze:
> In any case, it's easy to find the right site-start:
>
>    emacs -batch -q -no-site-file -eval '(prin1 (locate-library "site-start"))'
>
> should do the trick if it exists.
>

And where to place the file if it does not exist? (In a platform 
independent way.)

Re: run/load a lisp script before user init file

[Jarek Czekalski]

W dniu 2013-10-08 15:09, Stephen J. Turnbull pisze:
> In any case, it's easy to find the right site-start:
>
>    emacs -batch -q -no-site-file -eval '(prin1 (locate-library "site-start"))'
>
> should do the trick if it exists.
>

What to do if it exists and is an elc file? AFAIK the library may be 
compiled.

Re: run/load a lisp script before user init file

[Jarek Czekalski]

My attempts to establish a portable way to do that may be annoying. I 
can understand that. So I finish this thread. My conclusion is:

The site-start design is a mistake. That's why all installers say: add 
"..." to your init file. That's the way I'm going to choose too. Until 
someone revises the design and comes up with something comfortable. 
Debian folks would do that, but apparently they decided that it's easier 
to create own solution, than to fight for the improvement in core.

Thank you for the discussion and advices. They are helpful in general.

Jarek

Re: run/load a lisp script before user init file

[Stephen J. Turnbull]

Jarek Czekalski writes:

 > My attempts to establish a portable way to do that may be annoying.

As far as I know, an automatically recognized autoload cookie *is*
portable source code.  The XEmacs package system automatically
extracts those cookies and loads them when XEmacs starts.  I suppose
that ELPA/package.el-style packages do, too.

If there are two types of sites, those that should have emacspeak
automatically started and those that shouldn't, you can create a
trivial emacspeak-autostart package that contains only a single cookie
like:

;;;###autoload
(progn (load 'emacspeak-init t) (emacspeak-autostart) (fmakunbound 'emacspeak-autostart))

where emacspeak-init is a library that does nothing but defun the
emacspeak-autostart script (could be part of emacspeak proper, or
could be a separate file in emacspeak-autostart package).  Then
installing that package causes emacspeak to autostart.

(The fmakunbound call is intended to ensure that the autostart
function only gets invoked once, but that may be more paranoid than
necessary.)

Re: run/load a lisp script before user init file

[Glenn Morris]

Jarek Czekalski wrote:

> I don't think of site-start as of a library. Rather as a start-up
> script. Let's go back to Debian Emacs. Why did they invent
> site-start.d directory? 

I find what Red Hat did was better:

http://lists.gnu.org/archive/html/emacs-devel/2013-05/msg00328.html

Just make your site-start.el contain something like:

;; load ".el" files in "/usr/share/emacs/site-lisp/site-start.d/" on startup
(mapc 'load
      (directory-files "/usr/share/emacs/site-lisp/site-start.d" t "\\.el\\'"))


That's the only change you ever need to make to site-start.el.
For everything else, add and delete to site-start.d.
Emacs does not need to change for this to work.

Re: run/load a lisp script before user init file

[Tom Tromey]

GM> I find what Red Hat did was better:
GM> http://lists.gnu.org/archive/html/emacs-devel/2013-05/msg00328.html

GM> That's the only change you ever need to make to site-start.el.
GM> For everything else, add and delete to site-start.d.
GM> Emacs does not need to change for this to work.

FWIW a long term goal I had for package.el was to have it also manage
site-lisp.  The idea was to move various built-in Emacs packages to
package.el-style activation, so that users could install a newer version
in site-lisp and have Emacs DTRT.

Distros could easily take advantage of this by ensuring that elisp
installed into site-lisp follows the package.el installation rules.
This is easy to do...

Tom

Re: run/load a lisp script before user init file

[Josh]

[-- Attachment #1: Type: text/plain, Size: 3644 bytes --]

On Tue, Oct 8, 2013 at 7:50 AM, Jarek Czekalski <jarekczek@poczta.onet.pl>
wrote:
> My attempts to establish a portable way to do that may be
> annoying. I can understand that. So I finish this thread. My
> conclusion is:
>
> The site-start design is a mistake. That's why all installers say:
> add "..."  to your init file. That's the way I'm going to choose
> too. Until someone revises the design and comes up with something
> comfortable. Debian folks would do that, but apparently they
> decided that it's easier to create own solution, than to fight for
> the improvement in core.

If you choose to use init files alone, you may be able to take advantage
of the order in which Emacs searches for init files.  The manual[0]
documents three init files that are checked, but _not_ the order in which
Emacs looks for them (this is arguably a documentation bug, but be aware
that this order could change since the documentation currently makes no
promises about it).  For the moment though, a quick command-line
experiment here in Bash[1] showed that Emacs looks first for ~/.emacs.el,
then for ~/.emacs, and finally for ~/.emacs.d/init.el.  You could place a
minimal bootstrap init file in ~/.emacs.el which would do nothing but
load Emacspeak if possible and then immediately try to load the main init
file where users' configuration would be stored.  By making an
appropriate assignment to user-init-file it preserves users' ability to
store customization settings in their own init files where your package
need never touch them.  It is perfectly safe to create and remove this
bootstrap file when installing and uninstalling your package so long as
you verify that it does not yet exist before creating it and that its
contents remain unchanged before deleting it.  After uninstallation of
your package and removal of the bootstrap code in ~/.emacs.el, all of the
contents of your users' ~/.emacs and/or ~/.emacs.d/init.el will remain
intact and Emacs will find them normally after failing to find the
deleted ~/.emacs.el.  Here is an example of what I'm suggesting (lightly
tested):

;; add emacspeak to `load-path' here if necessary
(message "Loading Emacspeak...%s"
         (if (load "emacspeak-loader" :noerror) "success!" "FAILED!"))

;; Fall back to this file if neither ~/.emacs nor ~/.emacs.d/init.el
;; could be found, though creating one of those may be preferable to
;; avoid the possibility of user customization ending up here and
;; complicating uninstallation of your package.
(let ((fallback-user-init-file user-init-file))
  (if (string-equal user-init-file (expand-file-name "~/.emacs.el"))
      (unless (load (setq user-init-file
                          (expand-file-name "~/.emacs"))
                    :noerror nil :nosuffix)
        (unless (load (setq user-init-file
                            (expand-file-name "~/.emacs.d/init.el"))
                      :noerror nil :nosuffix)
          (setq user-init-file fallback-user-init-file)))
    (error "init bootstrap code found in %s but must reside in ~/.emacs.el"
           user-init-file)))

;; (message "final user-init-file: %s" user-init-file)
;; -> /path/to/HOME/.emacs, or if not found
;;    /path/to/HOME/.emacs.d/init.el, or if not found
;;    /path/to/HOME/.emacs.el (this file)

HTH,
Josh

[0] (info "(elisp) Init File")
[1] ( fakehome="/tmp/fakehome"; if [ -d $fakehome ] ; then echo "$fakehome
exists, aborting" ; exit 1 ; else export HOME="$fakehome"; mkdir -p
${HOME}/.emacs.d && cd && for f in .emacs .emacs.el .emacs.d/init.el ; do
echo "(message \"$f\")" >$f ; done ; emacs -nw --eval '(message
"user-init-file: %s" user-init-file)' ; fi )

[-- Attachment #2: Type: text/html, Size: 4271 bytes --]

Re: run/load a lisp script before user init file

[Jarek Czekalski]

W dniu 10/08/2013 06:22 PM, Glenn Morris pisze:
> That's the only change you ever need to make to site-start.el.
> For everything else, add and delete to site-start.d.
> Emacs does not need to change for this to work.

Glenn, that's quite an idea! I will create a directory 
emacs-admins-do-not-support-site-start-directory-and-want-us-to-workaround-forever 
and link it from site-start.el the way you suggested. That will be robust!

Jarek

Re: run/load a lisp script before user init file

[Stephen J. Turnbull]

Tom Tromey writes:

 > FWIW a long term goal I had for package.el was to have it also manage
 > site-lisp.

XEmacs has had an option to have no site-lisp for more than 10 years,
and it's become default several years ago.

The preferred alternative is to put your code in
.../site-packages/my-stuff/library.el, decorate entry points with
autoload cookies, add a simple Makefile and package-info.in (mostly
complete skeletons provided for easy cases), and run make; make
bindist.

 > Distros could easily take advantage of this by ensuring that elisp
 > installed into site-lisp follows the package.el installation rules.
 > This is easy to do...

Social engineering-wise, we didn't find it so.  That's why we changed
the name when we changed the interface.

Re: run/load a lisp script before user init file

[Barry OReilly]

[-- Attachment #1: Type: text/plain, Size: 455 bytes --]

> emacs -q -l $path/emacspeak-setup.el -l $userInitFile
>
> It's not perfect, because -q switch causes customizing variables
> impossible.

I'm not sure what you mean. I tried 'emacs -q -l ~/.emacs.d/init.el'
and it seemed to set my customized variables correctly. I also tried
defining a defcustom in /tmp/foo.el, adding it to the
custom-set-variables form of init.el, and 'emacs -q -l /tmp/foo.el -l
~/.emacs.d/init.el'. The variable was set correctly.

[-- Attachment #2: Type: text/html, Size: 553 bytes --]

Re: run/load a lisp script before user init file

[Josh]

On Thu, Oct 10, 2013 at 6:52 AM, Barry OReilly <gundaetiapo@gmail.com> wrote:
>> emacs -q -l $path/emacspeak-setup.el -l $userInitFile
>>
>> It's not perfect, because -q switch causes customizing variables
>> impossible.
>
> I'm not sure what you mean. I tried 'emacs -q -l ~/.emacs.d/init.el'
> and it seemed to set my customized variables correctly. I also tried
> defining a defcustom in /tmp/foo.el, adding it to the
> custom-set-variables form of init.el, and 'emacs -q -l /tmp/foo.el -l
> ~/.emacs.d/init.el'. The variable was set correctly.

As they stand both of these leave user-init-file set to nil, so users'
later attempts to save changes for future sessions with the
customization UI would fail due to the check by the `custom-file'
function in cus-edit.el.  This could be avoided by assigning
".../init.el" to user-init-file, performing that assignment either in
.../init.el itself (which seems a bit silly) or in foo.el, in which case
it would be simpler to omit the -q and have foo.el go ahead and
load init.el.  This is the scheme I described in my previous
message except that instead of foo.el I specified ~/.emacs.el,
because this approach does not require invoking Emacs with
any particular flags (i.e. neither -q nor -l) and preserves users'
ability to safely store arbitrary configuration in ~/.emacs and/or
~/.emacs.d/init.el.