vim do not guess $HOME when unavailable

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

vim do not guess $HOME when unavailable

Pierre Habouzit
One of our users reported that with HOME unset vim does not find the
users vimrc, because it only uses $HOME to find the vimrc :

http://bugs.debian.org/349465

Is this intended (and if yes why) ? or shouldn't it use getpwuid to find
the information ?
--
·O·  Pierre Habouzit
··O                                                [hidden email]
OOO                                                http://www.madism.org

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: vim do not guess $HOME when unavailable

A.J.Mechelynck
Pierre Habouzit wrote:
> One of our users reported that with HOME unset vim does not find the
> users vimrc, because it only uses $HOME to find the vimrc :
>
> http://bugs.debian.org/349465
>
> Is this intended (and if yes why) ? or shouldn't it use getpwuid to find
> the information ?

If $HOME is unset, there is a fallback, which can IIUC be set at
compile-time, possibly in an architecture-dependent fashion. It is
mentioned in the ":version" listing as "2nd user vimrc file". For
instance, on many systems (but apparently not on Unix), if $HOME/.vimrc
and $HOME/_vimrc are not found, Vim will look for the same files in the
$VIM directory.

I suppose that on Unix/Linux, $HOME "ought" never to be unset. (What is
the logic behind unsetting it intentionally on Debian?)

About that Debian bug specifically (Vim fails within sudo because $HOME
is unset), is it really "good practice" to call vim within sudo? Or
shouldn't sudo (after you enter the root password) set HOME='/root' or
something like that? Or else leave $HOME unchanged? -- Well, now that it
is known, I suppose that a usable workaround (until the bug is fixed)
would be to login to root rather than use sudo. Of course it is just a
"temporary workaround", not a "permanent solution".


Best regards,
Tony.

Reply | Threaded
Open this post in threaded view
|

Re: vim do not guess $HOME when unavailable

Bram Moolenaar
In reply to this post by Pierre Habouzit

Pierre Habouzit wrote:

> One of our users reported that with HOME unset vim does not find the
> users vimrc, because it only uses $HOME to find the vimrc :
>
> http://bugs.debian.org/349465
>
> Is this intended (and if yes why) ? or shouldn't it use getpwuid to find
> the information ?

Vim only uses $HOME, so that you can specify what home directory to use.
So far I haven't seen a reason to do otherwise.  Not having $HOME set is
likely to cause trouble.

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
 \\\            help me help AIDS victims -- http://www.ICCF.nl         ///
Reply | Threaded
Open this post in threaded view
|

Re: vim do not guess $HOME when unavailable

Pierre Habouzit
In reply to this post by A.J.Mechelynck
Le Lun 23 Janvier 2006 09:51, A. J. Mechelynck a écrit :

> Pierre Habouzit wrote:
> > One of our users reported that with HOME unset vim does not find
> > the users vimrc, because it only uses $HOME to find the vimrc :
> >
> > http://bugs.debian.org/349465
> >
> > Is this intended (and if yes why) ? or shouldn't it use getpwuid to
> > find the information ?
>
> If $HOME is unset, there is a fallback, which can IIUC be set at
> compile-time, possibly in an architecture-dependent fashion. It is
> mentioned in the ":version" listing as "2nd user vimrc file". For
> instance, on many systems (but apparently not on Unix), if
> $HOME/.vimrc and $HOME/_vimrc are not found, Vim will look for the
> same files in the $VIM directory.
if HOME is unset by sudo, it's unlikely that it'let $VIM pass its filter
(and the DSA -- aka Debian Security Alert -- says that it only let
filtered flavours of LC_* and LANG(UAGE)? pass) ...  Note that before
mailing vim-dev I read :he $HOME and :he $HOME-use to see if the
problem was already explained here, and I saw the $VIM thing.

Note that IIUC (reading :he $VIM) setting $VIM will skip the sourcing
of /etc/vim/vimrc which is worse ;)

> I suppose that on Unix/Linux, $HOME "ought" never to be unset. (What
> is the logic behind unsetting it intentionally on Debian?)

debian does not unset HOME. apparently the user that reported the bug
had it unset because of sudo.

> About that Debian bug specifically (Vim fails within sudo because
> $HOME is unset), is it really "good practice" to call vim within
> sudo? Or shouldn't sudo (after you enter the root password) set
> HOME='/root' or something like that? Or else leave $HOME unchanged?
> -- Well, now that it is known, I suppose that a usable workaround
> (until the bug is fixed) would be to login to root rather than use
> sudo. Of course it is just a "temporary workaround", not a "permanent
> solution".

sure, that's more ore less what I'll answer the user when all of this
would be sorted out. My only question was that I was surprised that
when HOME is not set, vim does not even try to read the login_dir field
of getpwuid, it's a simple guess, that can save a lot of trouble.
That's all.

I only asked if there was a rationale behind this, or if it was just
`not done' and that a patch would be accepted.
--
·O·  Pierre Habouzit
··O                                                [hidden email]
OOO                                                http://www.madism.org

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: vim do not guess $HOME when unavailable

A.J.Mechelynck
Pierre Habouzit wrote:
> [...] My only question was that I was surprised that
> when HOME is not set, vim does not even try to read the login_dir field
> of getpwuid, it's a simple guess, that can save a lot of trouble.
> That's all.
>
> I only asked if there was a rationale behind this, or if it was just
> `not done' and that a patch would be accepted.

IIUC, getpwuid() is Unix-specific; the equivalent on Windows would not
exist or be very different, wouldn't it? (not that I know what it would
be; $HOMEDRIVE$HOMEPATH maybe, i.e., in Windows notation,
%HOMEDRIVE%%HOMEPATH%). So if such a solution were to be implemented, I
guess that (considering ":help design-multi-platform") there would have
to be in some source file something similar (but probably not identical) to:

        [set homepath to $HOME]
        if ( homepath == '' )
        {
#IFDEF UNIX
                homepath = getpwuid().login_dir
#ELSEIF DEFINED(WIN3264)
                ...
#ELSE
                ...
#ENDIF
        }

But if $HOME is unset on Unix, wouldn't there be a lot of other things
which would fail? And if there would, wouldn't it be a better solution
to solve the problem across the board (by keeping $HOME defined in some
sensible manner) rather than for one software package (Vim)?


Best regards,
Tony.

Reply | Threaded
Open this post in threaded view
|

Re: vim do not guess $HOME when unavailable

Stefano Zacchiroli-2
In reply to this post by Bram Moolenaar
On Mon, Jan 23, 2006 at 10:32:23AM +0100, Bram Moolenaar wrote:
> > Is this intended (and if yes why) ? or shouldn't it use getpwuid to find
> > the information ?
> Vim only uses $HOME, so that you can specify what home directory to use.
> So far I haven't seen a reason to do otherwise.  Not having $HOME set is
> likely to cause trouble.

Agreed.

But why not falling back to getpwuid() (or the correct brother) if $HOME
is unavailable && the target OS supports that function? It wont cause
any harm AFAICT.

Cheers.

--
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
zack@{cs.unibo.it,debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-
Reply | Threaded
Open this post in threaded view
|

Re: vim do not guess $HOME when unavailable

Matthew Winn
On Mon, Jan 23, 2006 at 11:26:04AM +0100, Stefano Zacchiroli wrote:
> But why not falling back to getpwuid() (or the correct brother) if $HOME
> is unavailable && the target OS supports that function? It wont cause
> any harm AFAICT.

Should it use the real or the effective user ID?  (In other words, when
running in a setuid environment should it use the directory of the user
the process came from or the one it's currently using?)

--
Matthew Winn ([hidden email])
Reply | Threaded
Open this post in threaded view
|

Re: vim do not guess $HOME when unavailable

Ciaran McCreesh
In reply to this post by Bram Moolenaar
On Mon, 23 Jan 2006 10:32:23 +0100 Bram Moolenaar <[hidden email]>
wrote:
| Vim only uses $HOME, so that you can specify what home directory to
| use. So far I haven't seen a reason to do otherwise.  Not having
| $HOME set is likely to cause trouble.

Although unfortunately, some of the Gnome stuff to which Vim links
ignores $HOME and only uses getpwuid, which means that the Vim build
process has to have write access to the real ~/.gnome2* when generating
the NLS things or running tests...

--
Ciaran McCreesh : Gentoo Developer (King of all Londinium)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: vim do not guess $HOME when unavailable

Bram Moolenaar

Ciaran McCreesh wrote:

> On Mon, 23 Jan 2006 10:32:23 +0100 Bram Moolenaar <[hidden email]>
> wrote:
> | Vim only uses $HOME, so that you can specify what home directory to
> | use. So far I haven't seen a reason to do otherwise.  Not having
> | $HOME set is likely to cause trouble.
>
> Although unfortunately, some of the Gnome stuff to which Vim links
> ignores $HOME and only uses getpwuid, which means that the Vim build
> process has to have write access to the real ~/.gnome2* when generating
> the NLS things or running tests...

That's weird.  I mean, how would you get the result from getpwuid() in a
shell script (in a Makefile)?

Also note that "~/.gnome2" is short for "$HOME/.gnome2".  At least,
that's how I have aways seen it.  A simple test confirms it:

        sh
        % cat ~/somefile
        [file is displayed]
        % unset HOME
        % cat ~/somefile
        cat: ~/somefile: No such file or directory

Perhaps it's better to consider the Gnome stuff to be the problem...

--
hundred-and-one symptoms of being an internet addict:
130. You can't get out of your desk even if it's time to eat or time
     to go to the bathroom.

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
 \\\            help me help AIDS victims -- http://www.ICCF.nl         ///
Reply | Threaded
Open this post in threaded view
|

Re: vim do not guess $HOME when unavailable

Ciaran McCreesh
On Mon, 23 Jan 2006 22:32:20 +0100 Bram Moolenaar <[hidden email]>
wrote:
| > Although unfortunately, some of the Gnome stuff to which Vim links
| > ignores $HOME and only uses getpwuid, which means that the Vim build
| > process has to have write access to the real ~/.gnome2* when
| > generating the NLS things or running tests...
|
| That's weird.  I mean, how would you get the result from getpwuid()
| in a shell script (in a Makefile)?

Vim is invoked via the Makefile for various things, so if you're
building with --with-vim-name=gvim the Gnome code gets called.

| Also note that "~/.gnome2" is short for "$HOME/.gnome2".  At least,
| that's how I have aways seen it.  A simple test confirms it:

Sorry, should've been clearer. I mean that the real (from passwd) home
directory is used, and the environment variable is ignored.

| Perhaps it's better to consider the Gnome stuff to be the problem...

Probably, yes. I only noticed this because Gentoo builds are done in a
sandbox that disallows writes outside of the build directory, and the
usual workaround (setting ${HOME} to a temporary directory) weren't
working. No big deal, since we can selectively allow writes or just hack
the Makefile to make a buildvim -> gvim symlink and use that inside the
Makefile instead...

--
Ciaran McCreesh : Gentoo Developer (King of all Londinium)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: vim do not guess $HOME when unavailable

Bram Moolenaar

Ciaran McCreesh wrote:

> On Mon, 23 Jan 2006 22:32:20 +0100 Bram Moolenaar <[hidden email]>
> wrote:
> | > Although unfortunately, some of the Gnome stuff to which Vim links
> | > ignores $HOME and only uses getpwuid, which means that the Vim build
> | > process has to have write access to the real ~/.gnome2* when
> | > generating the NLS things or running tests...
> |
> | That's weird.  I mean, how would you get the result from getpwuid()
> | in a shell script (in a Makefile)?
>
> Vim is invoked via the Makefile for various things, so if you're
> building with --with-vim-name=gvim the Gnome code gets called.

Sorry, I wasn't clear.  I meant: If we are supposed to use the directory
that getpwuid() returns, how would you do such a thing in a shell script
or Makefile?  The point is that almost everywhere $HOME is used.

> | Also note that "~/.gnome2" is short for "$HOME/.gnome2".  At least,
> | that's how I have aways seen it.  A simple test confirms it:
>
> Sorry, should've been clearer. I mean that the real (from passwd) home
> directory is used, and the environment variable is ignored.
>
> | Perhaps it's better to consider the Gnome stuff to be the problem...
>
> Probably, yes. I only noticed this because Gentoo builds are done in a
> sandbox that disallows writes outside of the build directory, and the
> usual workaround (setting ${HOME} to a temporary directory) weren't
> working. No big deal, since we can selectively allow writes or just hack
> the Makefile to make a buildvim -> gvim symlink and use that inside the
> Makefile instead...

The suggestion that Gnome is doing something wrong appears to be
supported by this.

--
hundred-and-one symptoms of being an internet addict:
132. You come back and check this list every half-hour.

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
 \\\            help me help AIDS victims -- http://www.ICCF.nl         ///