[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
undesired behavior... reason is.. bug? or feature-deficit
From: |
Linda Walsh |
Subject: |
undesired behavior... reason is.. bug? or feature-deficit |
Date: |
Wed, 04 Mar 2015 18:40:10 -0800 |
User-agent: |
Thunderbird |
I've been working with c++ files recently, and
wrote a function to help open the "<file>.{cc,h}" files
together using "-p" (open the files in separate tabs)
in 'vim' ('gvim' actually).
I just tried the function on windows where it ran into
interference.
On windows, in order to get the windows version
of 'gvim' to auto-background from bash(under cygwin)
like it does on linux, *years* ago, I created an
alias for gvim:
alias gvim='setsid gvim'
It seems like the alias did it's substitution,
but then didn't call the function I had defined
(even though it knows about both):
whence gvim
gvim is aliased to `setsid gvim'
gvim is a function
gvim ()
{ ...
command gvim -p "${files[@]}";
return 0
}
gvim is /prog64/vim/gvim
---
So I'm wondering -- why didn't the alias call the function.
Note... I went out of my way to make sure the function
called the physical copy of gvim (since functions *DO* call
themselves if you aren't careful!)...
So why didn't the alias expand and then call the
function?
I know alias substitution is done first, but then shouldn't
it call any function by the same name? Is there a way
for it to evaluate such things deterministically?...
i.e. alias handles simple-subtitution 1st, then
calls the next "interface" (the function), then
the one in the PATH?
- undesired behavior... reason is.. bug? or feature-deficit,
Linda Walsh <=