command not found
dv1...@wayne.edu
-G
Ben Schmidt
It'll be because MacVim starts up with a different environment to console Vim
because it doesn't start from a shell with all its initialisation files and when
it starts a new shell, it's a non-login shell. I'd just make it start a login
shell with
:set shell=/bin/bash\ -l
(presuming if you do :set shell? you get /bin/bash to start with). That'll
probably fix it.
Ben.
Send instant messages to your online friends http://au.messenger.yahoo.com
dv1...@wayne.edu
Yes, that worked. Thank you, thank you, thank you!
-G
Ben Schmidt
Björn, do you think perhaps this could/should form part of the default .gvimrc
with MacVim? I suspect a lot of people will be confused when they find things work
differently (or don't work!) in MacVim to how they work if you simply open a
window in Terminal.app.
björn
I can't say I understand these issues well enough to know if it would
cause any problems if 'shell' was changed in $VIM/gvimrc. What
happens if the user is running another shell? Can the '-l' switch
cause other problems? etc.
For those who haven't modified their 'shell' I could do something like
if &shell == "/bin/bash"
let &shell = "/bin/bash -l"
endif
in $SYS/gvimrc, but is this safe or not?
/Björn
Ben Schmidt
> I can't say I understand these issues well enough to know if it would
> cause any problems if 'shell' was changed in $VIM/gvimrc. What
> happens if the user is running another shell? Can the '-l' switch
> cause other problems? etc.
Basically what -l does is tells bash to read /etc/profile and ~/.bash_profile,
~/.bash_login or ~/.profile (first it finds) as it starts, rather than just
~/.bashrc (which it will read for an interactive non-login shell) and $BASH_ENV
(any non-interactive shell, I believe). It doesn't really do anything else.
In practice this means it will have all the environment changes and possibly one
or two other settings a user will be expecting, because ordinarily anything a user
does on the commandline or that actually makes real use of the environment is
started in a login context.
This is because ordinarlly the first shell that is started for a terminal session
is a login shell, and commands started from there inherit that environment. This
includes, e.g., gVim, or an X server started from the commandline. Later shells
started by these programs then needn't be login shells, because the environment
changes, etc., have been inherited. However, because MacVim starts via a .app
bundle, it goes via LaunchServices or something, and as such, skips that initial
login shell. This means to get that initialisation that the user will be expecting
(and experiencing if they use gVim on other platforms, started from the
commandline, etc.) MacVim needs to start login shells.
I could only imagine problems being caused if somebody has put something they
shouldn't have in their ~/.profile (and friends). If a person is brave enough to
hack their shell startup files, though, they kinda deserve what they get if they
mess it up, and they should have the skills to fix it, too.
> For those who haven't modified their 'shell' I could do something like
>
> if &shell == "/bin/bash"
> let &shell = "/bin/bash -l"
> endif
>
> in $SYS/gvimrc, but is this safe or not?
It should be safe enough, and yes, definitely it should only be done if the shell
hasn't been set by the user already.
But there would be a better solution, actually, and I wonder whether it would
work. I think it would. It would be worth a try, IMHO. Ordinarily gvim itself runs
in a login environment, which means that environment variables and such are
available within Vim itself. Changing the shell option doesn't solve this, but
only solves the problem for processes Vim spawns.
However, given that MacVim starts vim processes itself, there is a unique
opportunity for it to start them in the correct environment. Would you be able to
change the command you use internally to start Vim processes from
/path/to/Vim args
to
/bin/bash -l -c "exec /path/to/Vim args"
It would start the vim subprocesses via an login shell, then, and thus Vim would
get all the environment people are expecting, but the 'exec' will mean it doesn't
fork, so only one process is started--the shell just becomes Vim after
initialising. Perhaps make it an option we can set via defaults write, a candidate
for a future preference pane. Default should be on, IMHO.
Cheers,
Ben Schmidt
Actually, the more correct way to do this would be to execute
"$SHELL" -c "exec /path/to/Vim args"
but set argv[0] to '-' followed by the basename of $SHELL, so that it looks to
$SHELL as if it has been invoked as something such as '-bash'. This is what the
'login' utility does, and what Terminal.app does, so all shells should work with
it. From what I can gather, pretty much all shells support the -c option and exec
command, too, so it should be pretty robust.
There is one issue I discovered, though...If MacVim is started from a terminal via
open, i.e. with
open MacVim.app
it inherits the environment of that terminal, i.e. it is started from a login
shell, and then it passes that environment on to the Vims it spawns too. So if
MacVim is started in this way, we don't need to start login shells...It is
possible, though unlikely, that in some cases you could get some odd effects by
having two login shells, so this could become an issue. But I can't think of any
reliable way to tell whether it's needed or not...yet...
I think the best option would be to get MacVim to start its vim instances via a
login shell by default, and if at some future stage we find a reliable way to
discover the times it isn't necessary, we can make MacVim smarter and skip it in
those cases.
björn
I have updated the Git repo with a "fix" along these lines. However,
I am not completely sure that it does what you suggested...so can you
(Ben) have a look at it and tell me if it is ok? Also, I am not sure
if sourcing the user profile will increase startup time.
This patch also fixes problems with dropping files containing spaces.
/Björn
George Harker
likes -c and -l together.
Oddly I looked at the code and used
defaults write org.vim.MacVim MMLoginShellKey -bool NO
as it looked like it should revert back the old behaviour, but it was
not respected over a Vim restart...
Does that key definitely work?
Cheers
George
björn
> This does not work if tcsh is your default shell. I don't think tcsh
> likes -c and -l together.
OK. Does anybody have any ideas on how to fix this?
> Oddly I looked at the code and used
>
> defaults write org.vim.MacVim MMLoginShellKey -bool NO
>
> as it looked like it should revert back the old behaviour, but it was
> not respected over a Vim restart...
>
> Does that key definitely work?
Yeah, it works. The user default is called MMLoginShell, without
"Key"... MMLoginShellKey is the name of a variable inside MacVim. So
try
defaults write org.vim.MacVim MMLoginShell 0
I guess it should be disabled by default now that we know it doesn't
work with all shells...
/Björn
Ben Schmidt
> On 18/11/2007, George Harker <george...@googlemail.com> wrote:
>> This does not work if tcsh is your default shell. I don't think tcsh
>> likes -c and -l together.
>
> OK. Does anybody have any ideas on how to fix this?
Yes.
And sorry I haven't got around to looking at this yet, Björn. I haven't managed to
bother to sort out git yet...perhaps now is the time...gotta dig up those
instructions that were sent around earlier...
> I guess it should be disabled by default now that we know it doesn't
> work with all shells...
Probably best to disable it for now with the plan to enable it by default once
it's undergone a bit more testing/fixing!
björn
>
> björn wrote:
> > On 18/11/2007, George Harker <george...@googlemail.com> wrote:
> >> This does not work if tcsh is your default shell. I don't think tcsh
> >> likes -c and -l together.
> >
> > OK. Does anybody have any ideas on how to fix this?
>
> Yes.
>
> And sorry I haven't got around to looking at this yet, Björn. I haven't managed to
> bother to sort out git yet...perhaps now is the time...gotta dig up those
> instructions that were sent around earlier...
Check the build instructions:
http://code.google.com/p/macvim/wiki/Building
If you do not have MacPorts to install Git, then it should be possible
to use Fink, or even to build from the source code tar-ball. I've
tried the latter on Linux with no problems...haven't tried on Mac
though, and I also haven't tried Fink (but that should be no problem).
>
> > I guess it should be disabled by default now that we know it doesn't
> > work with all shells...
>
> Probably best to disable it for now with the plan to enable it by default once
> it's undergone a bit more testing/fixing!
Agreed.
/Björn
Tim Allen
> > And sorry I haven't got around to looking at this yet, Björn. I haven't managed to
> > bother to sort out git yet...perhaps now is the time...gotta dig up those
> > instructions that were sent around earlier...
>
> Check the build instructions:
>
> http://code.google.com/p/macvim/wiki/Building
>
> If you do not have MacPorts to install Git, then it should be possible
> to use Fink, or even to build from the source code tar-ball. I've
> tried the latter on Linux with no problems...haven't tried on Mac
> though, and I also haven't tried Fink (but that should be no problem).
or two ago I used Fink exclusively, and I built Git from a tarball
(well, I built it from a tarball once, then used it to checkout the
repository and built from *that* :)
After that, I realised how tiny and antiquated Fink's packages were
compared to MacPorts, so I trashed Fink and switched to MacPorts
exclusively. Apart from the tedium of compiling every little thing,
and the fact that some obscure packages have broken ports, it's been
pretty sweet.
George Harker
I guess for tcsh you shouldn't really rely on .login having run. It's
bad practice anyway. But .tcshrc would still have been sourced (which
is where you should put env vars and stuff anyway).
Not really sure what to suggest. But obviously it's rather wierd
because MacVim is trying to launch /bin/tcsh -l -c which is erroring
to console. So you never get any windows up at all!
To me, .login etc should be used _only_ to set up login related
things, like whether to run a session under screen. I code in bash,
but hate it for interactive use, so I don't really know exactly which
circumstances .profile vs .bashrc would be run or if the situation is
like tcsh's rc scripts.
Cheers
George
George Harker
impressed with fink - not for the bleeding edge nature of the
packages, but because things just seem to work well and are tested.
I tried MacPorts years ago - so I don't have any idea how good it is these days.
But fink does have git.
Cheers
George
dv1...@wayne.edu
-G
Thus spake George Harker [11/18/07 @ 20.33.48 +0000]:
> FInk definitely has git.
George Harker
mean that - it generally means less thoroughly tested / source only.
The fink package tracker is down or else I'd check and post the link,
but you can check here:
http://pdb.finkproject.org/pdb/index.php?phpLang=en
Use which you please - ports fink or whatever, I have my preference
but it may or may not equate to what's really best.
Cheers
George
Ben Schmidt
> FInk definitely has git. That's how I installed it. In general I'm
> impressed with fink - not for the bleeding edge nature of the
> packages, but because things just seem to work well and are tested.
>
> I tried MacPorts years ago - so I don't have any idea how good it is these days.
I'm in the reverse situation! I tried Fink years ago, and MacPorts more recently,
and was significantly more impressed with MacPorts.
At any rate, I did find the older email about how to clone/pull MacVim and have
done so, so it's all good. I had already installed git, so that wasn't a
bottleneck! I might install the +svn variant at some stage when I have a bit more
time to invest into it, though.
Cheers,
Ben Schmidt
> bad practice anyway.
Bad practice or not, there are tools which modify the login files to set ENV vars
and so on when they are installed, and people get caught out when they aren't sourced.
> But .tcshrc would still have been sourced (which
> is where you should put env vars and stuff anyway).
No it wouldn't, actually. Under Aqua the login shell is loginwindow, not actually
your login shell, which is the main problem here. Most commandline apps don't know
about installing environment variables via ~/.MacOSX/environment.plist and use
/etc/profile or ~/.profile (and often just ignore shells other than (ba)sh
actually!). So if MacVim doesn't start Vim via a shell, basically nothing is
sourced--no shell login files, no shell rc files, nothing. That's OK for most GUI
apps, but Vim is different, as many of its users will want to use the commandline
within Vim one way or another, and have the environment properly set up for this,
without them having to tinker with all their shell configuration files.
> Not really sure what to suggest. But obviously it's rather wierd
> because MacVim is trying to launch /bin/tcsh -l -c which is erroring
> to console. So you never get any windows up at all!
This is a bit of an issue. Perhaps something should be done about this...set some
timeout or something after which point if MacVim hasn't heard back from the child
process it attempted to start, it gives at least some kind of error message,
directing you to the console if nothing else.
Matt Tolton
George Harker
> and so on when they are installed, and people get caught out when they aren't sourced.
I don't doubt this, but my understanding with tcsh at least is that
tchrc gets sourced, but .login only for login shells. Maybe bash is
different.
> No it wouldn't, actually. Under Aqua the login shell is loginwindow, not actually
> your login shell, which is the main problem here. Most commandline apps don't know
> about installing environment variables via ~/.MacOSX/environment.plist and use
> /etc/profile or ~/.profile (and often just ignore shells other than (ba)sh
> actually!). So if MacVim doesn't start Vim via a shell, basically nothing is
> sourced--no shell login files, no shell rc files, nothing. That's OK for most GUI
> apps, but Vim is different, as many of its users will want to use the commandline
> within Vim one way or another, and have the environment properly set up for this,
> without them having to tinker with all their shell configuration files.
I agree we should start via a shell, I'm just not so sure it should be
a login one.
But in honesty, I don't know what can be relied upon between different
shells. Normally, the only portable thing you can rely on the that a
subshell for a command will be a sh derivative shell.
> This is a bit of an issue. Perhaps something should be done about this...set some
> timeout or something after which point if MacVim hasn't heard back from the child
> process it attempted to start, it gives at least some kind of error message,
> directing you to the console if nothing else.
It'd be good to understand whether rc files are run for a non login
shell for each different shell.
I'm a developer so my login files are crammed full - I get how
frustrating it can be when aliases and the like are not available.
But if Vim doesn't start, that's also rather frustrating.
Cheers
George
Tim Allen
wrote:
> > and so on when they are installed, and people get caught out when they aren't sourced.
>
> I don't doubt this, but my understanding with tcsh at least is that
> tchrc gets sourced, but .login only for login shells. Maybe bash is
> different.
at work, so I know the answer. From bash(1):
# When bash is invoked as an interactive login shell, or as a non-
inter-
# active shell with the --login option, it first reads and executes
com-
# mands from the file /etc/profile, if that file exists. After
reading
# that file, it looks for ~/.bash_profile, ~/.bash_login, and
~/.profile,
# in that order, and reads and executes commands from the first one
that
# exists and is readable.
...and:
# When an interactive shell that is not a login shell is started,
bash
# reads and executes commands from ~/.bashrc, if that file exists.
In summary, a login shell reads /etc/profile, an interactive shell
reads .bashrc, and a non-interactive non-login shell executes nothing.
It looks like there's no universal way to make a shell read the user's
startup files and then go on to execute a command.