Re: [Help-bash] Current working directory echoed to the terminal

[Chris Jones]

On Wed, Apr 11, 2012 at 04:04:23PM EDT, Bob Proulx wrote:
> Chris Jones wrote:
> > Bob Proulx wrote:

[..]

> Okay.  So you want shell aliases to be available to "scripts".  I use
> "scripts" here because I am not sure how vim invokes :! commands.  I
> imagine it is using something similar to '$SHELL -c "cmd"' there when
> there are shell metacharacters present and testing seems to confirm this.

It's not even that technical:

I just want to be able to issue single ‘shell commands’ from Vim as if
I was at the bash prompt. This means everything that's available at the
shell prompt, including aliases and functions. 

[..]

> The part I don't like about setting BASH_ENV is that it forces an
> overhead upon every script.  It can be a noticeable slowdown if every
> script must source the environment file.  (Of course if you haven't
> noticed then you would argue that it wasn't noticeable.)

It's not so much the overhead, which in my case is negligible. The part
I don't like is that it's just not right to systematically source bash
aliases and functions where you don't need them. For all I know, there
could even be corner cases where this might lead to hard-to-track-down
bugs.

[..]

> > That's actually a Vim faq of sorts - pops up now and again on
> > vim_user.

> I think this may be a difference of philosophy.  If you embrace
> aliases then you want the aliases to be active everywhere which means
> loading them into the shell environment.  On the other hand you
> believe that aliases are trouble for many reasons and using real
> scripts to implement the behavior avoids those problems and is more
> reliable for many reasons.  These two philosophies will push people in
> different directions.  It may be a vim faq but I would be on the
> opposing viewpoint for it.  (shrug)

I think that aliases are fine in interactive shells as long as you use
them in moderation. I use 3-4 aliases very frequently and a few others
less frequently. More than that would be useless because I'd need
a cheat sheet. My aliases all point to one single command (no pipelines,
no control structures.. etc.).. just a bunch of flags that are a pain to
type & memorize. For anything more involved than the examples I gave
in an earlier post, I use functions or scripts.

> For example for your alias example above 'l | b' I would have created
> two shell scripts named 'l' and 'b' that implemented that behavior.
> It would have been exactly the same for your muscle memory.  But it
> would not have required BASH_ENV to load the aliases.

Ah.. But scripts add the overhead of creating extra processes while
aliases are only a syntax substitution hack that remains local to the
parent shell.

> Note that patch for sshd and bash above?  Same thing.  When running a
> remote command over ssh onto a remote host it won't be an interactive
> shell and won't have loaded any aliases.  If the commands were scripts
> then the behavior would work without problem remotely.  But if trying
> to use shell aliases over a remote shell then special configuration is
> needed to cause them to be loaded and available.

That's not alias-specific: it would happen anyway because my custom bash
functions or even scripts (not to mention my Vim rcfile) are not going
to be available on all remote systems either unless I do some special
configuration.

> I am not a vim person but if I were, and I were embracing aliases, I
> would try to limit the scope of BASH_ENV by only setting it from
> within vim.  

I've come to the conclusion that Vim doesn't handle temporarily escaping
to a shell as gracefully as it should, but I'm not sure there's anything
I can do about it.

Here is the dilemma:

By default, Vim's shell escape mechanism causes a non-interactive shell
to be launched, which proceeds to run the command that the user entered
at the Vim command line. Since the shell is not an interactive shell, no
bashrc user-controlled customization of the environment takes place and
bash aliases and functions are not available.

As far as I can tell, there are two ways you can work around this:

1. Customize Vim to force the escape shell to be interactive: this
   causes the  ~/.bashrc file to be sourced and aliases & functions
   become available.

2. Customize bash via the BASH_ENV variable to force the sourcing of
   aliases & functions for all non-interactive shells including scripts
   run outside the Vim context.

The nice thing about the first solution is that it is local to Vim but
it has one annoying drawback¹: for reasons I do not fully understand,
control is never returned to Vim.. I either have to manually issue an
'fg' or an 'exit' to wake up my Vim session. This can get nasty when Vim
is invoked by another program such as mutt: I issued a ‘wc’ command to
check the size of my vimrc.. and I was unable to get control back. So,
I had to kill my mutt/Vim session & re-type the better part of this
message. :-(

As to the second solution, I realize it is not really satisfactory but
at least it does the job, so it looks like I'll have to stick with it
for the time being..

I could report this issue to the Vim user list, but I have a feeling
that s/o will tell me that a simple workaround is to convert my aliases
& functions to scripts.. :-)  

> I think Greg's suggested improvement to your environment script to
> avoid the cd calls entirely was a really good improvement.  

His ‘improvement’ left me rather speechless, I must say.. and a little
pissed at not having found the solution myself..

Thanks for your comments, helps clarify the issue.

CJ

¹ Incidentally there is another aspect, especially on debian: when the
  shell is interactive, there is a noticeable slowdown due to all the
  debian-specific function code that gets sourced: I issued a ‘:! set
  | wc’ after changing the Vim ‘shell’ option to ‘/bin/bash -i’ and the
  output was almost 10,000 lines..! Not much of a problem in normal
  circumstances where you start an interactive shell and proceed to
  issue hundreds of commands, but here all this sourcing happens every
  time you run a command from Vim... On underpowered hardware, this
  could be annoying..

-- 
ALL YOUR BASE ARE BELONG TO US!