On Mon, Sep 6, 2010 at 5:47 PM, Vin Shelton <acs(a)alumni.princeton.edu> wrote:
Dear Sam,
On Sat, Sep 4, 2010 at 3:56 PM, Sam <naesten(a)gmail.com> wrote:
> ================================================================
> When I try to run the package manager in an account with no ~/.xemacs/
> yet (e.g. by typing M-x list-packages), first xemacs tells me that
> there's no package database yet, and would I like it to create one in
> ~/.xemacs/? When I say "yes", it proceeds to fail because ~/.xemacs
> doesn't exist yet either.
>
> This doesn't seem very smooth to me.
Me either. What does
(getenv 'HOME")
evaluate to?
My guess is "/home/Administrator". Does that directory exist? My
guess is it doesn't. My next guess would be that if we forced the
parent directory of $HOME/.xemacs to be created that this bug would go
away.
Actually, each time something like this has happened to me, "~"
already existed -- once in Cygwin, at least once in the native ICC
build. All I had to do was manually create ~/.xemacs, and XEmacs would
succeed at writing whatever it wanted to write: either custom.el or
the package list, at least, and I ran into a similar issue with a
missing mule-packages directory.
Also, note that Cygwin seems to (by default) create a $HOME for any
user when they first start a login shell, which is what all the
convenient ways of starting a shell do: Cygwin.bat (which is where the
"Cygwin" start menu and desktop shortcuts point) does it, and so
do(es) the mintty shortcut(s).
(Does that mean that I can create arbitrary directories under /home
(C:\cygwin\home) even as my usual limited user, I wonder?)
Native XEmacs seems to have a tendency to try to use C:\.xemacs, which
is certainly unfortunate, but if you set HOME to point to where you
want, it works well enough. And whatever you might do to that logic,
please:
1. Make it easy to override by environment variable, e.g. for an
installation on a USB drive, so that you can keep .xemacs on the USB
drive as well. I have a batch file named \XEmacs\xemacs.bat on mine
that uses NT's extended parameter expansion syntax to add some stuff
on the same drive to PATH, set HOME to point to \XEmacs on that drive,
and then runs the xemacs executable (again using parameter expansion
to specify a path based on the scripts' own).
The parameter expansion syntax for this can be seen by running "help
call" under the "cmd.exe" shell, or on the page
http://ss64.com/nt/syntax-args.html
2. Be careful that your conditionals don't also apply to the Cygwin
port, since such changes to the logic would be most unwelcome there.
Cygwin ports of *nix tools are *not* supposed to mess with
%UserProfile% ;-)
Of course, the %UserProfile% environment variable is not the correct
approach for a real application to take in any case -- I assume the
facility exists primarily for batch scripts. I believe the cygpath(1)
manpage can point you towards the correct facility.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta