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

[Bob Proulx]

Chris Jones wrote:
> Bob Proulx wrote:
> > Why is the BASH_ENV variable set?  The easiest and best solution would
> > seem to be to find where that is getting set and remove it so that it
> > isn't ever set.
> 
> Oh, I can answer that, since I set it myself..  ;-)

:-)  Good!  "The buck stops here."

> The reason being that I want my personal collection of aliases and
> functions to be available from the vi/Vim command line.
> 
> As an example.. when in Vim, I type:
> 
> | :! l | b 
> 
> .. instead of:
> 
> | !ls -alh -F --full-time --color=always | less -M -R -c -i -J -~ -N'

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.

> That's a lot less keystrokes and a lot less to remember, naturally.. but
> even _more importantly_ it is consistent with my bash working habits: in
> other words I don't have to _think_ I am in Vim or in bash and choose
> a different model according to the context - it's part of my muscle
> memory.. no overhead whatsoever.

Makes sense and seems reasonable to me.

> Initially, I was unable to do this despite the fact that my aliases and
> functions are sourced in my ~/.bashrc. It's been a while since I looked
> at this but as far as I can remember the reason is that the ‘:!’ Vim
> escape causes a non-interactive shell to be invoked, which bypasses
> sourcing the bashrc file.

As I recall things the behavior in this area of .bashrc sourcing for
non-interctive shells has been different at different times due to
different patches on different systems.  You may have run into the
different behavior over time due to those differences.

In vim on my Debian system (note I am not normally a vim user) when I
type in :! echo $- I see "hBc" and my .bashrc is not sourced.  And of
course if I force it with BASH_ENV=$HOME/.bashrc then it does source
my .bashrc and makes aliases available.

> There may be other (better?) ways to achieve the same result but apart
> from this ‘cd - > /dev/null’ annoyance, I am quite happy with my setup.

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.)

Also aliases can break scripts.  For a humorous example I knew one
person who aliased a local "install-file" command to be something like
if='install-file args ...' and also forced the environment and aliases
to be loaded.  Of course that broke 'if' statements and the result was
pretty catastrophic.  They had no idea what was going on and of course
reported that they hadn't changed anything.  After all how could
adding an alias have such far reaching effects? :-) [To be honest I
may be remembering ksh behavior here but I think it is the same.]

> As I wrote in my initial post, I'm curious as to why I did not run into
> this on debian ‘lenny’. I still have this system available but I haven't
> had a chance to boot into it to take a closer look.

I don't know why there would be a difference between Lenny and
Squeeze.  In both there is a Debian patch that may be relevant:

  - try to check whether bash is being run by sshd and source
  the .bashrc if so (like the rshd behavior).

But I tested vim's :! on both and in neither was the .bashrc sourced
for those commands (unless forced with BASH_ENV).  Not sure if it was
always that way or not.

> > The ksh needed ENV set in order to source a ksh envirionment script.
> > And so bash has that too as a compatibility option.  And also has
> > BASH_ENV which for a bash specific override.  But in all of the years
> > I have been using shells I haven't ever needed to set BASH_ENV.
> > Instead I let the automatic bashrc file processing do everything.
> 
> 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)

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.

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.

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.  But really I would create scripts instead of aliases and
then avoid the entire issue.

> CDPATH is not something I would want to use and is not set in my
> environment. Only BASH_ENV is. 

I got distracted by the fact that it printed the information when the
bashrc file was loaded but did not when BASH_ENV was unset.  My bad.

I think Greg's suggested improvement to your environment script to
avoid the cd calls entirely was a really good improvement.  I always
try to avoid using cd in scripts when practical.  When not I try to
use subshells so that I never have to do a second cd to get back to
the place where I was before.  Then only when neither of those two
things are practical do I use cd.  Since there is a good improvement
to avoid it I would definitely do that instead.  This doesn't address
the BASH_ENV issue but improves another part of the entire space.

Bob