On 31/12/13 12:40, Erik Christiansen wrote:
On 31.12.13 10:18, Tony Mechelynck wrote:
On 31/12/13 09:34, Erik Christiansen wrote:
$ grep which .bashrc
alias which='type -a' # Checks aliases & functions also.
The problem with this alias, IIUC, is when one tries to use
vim `which somecommand`
to edit an executable script, since the output of "type" is in a different
format.
Sort of. Making "which" a helpful tool and convenient mnemonic for the
vast majority of general use cases, makes it unsuited to that one, but
not merely due to format. On this host, without looking further than
"which" itself, it finds several (prioritised) alternatives:
$ which which
which is aliased to `type -a'
which is /usr/bin/which
which is /bin/which
I'm not too sure how a command should mind-read which of several
alternatives we'd prefer to examine, now that we know what's there. OK,
sometimes picking the one which has path priority will be the right one.
Without -a (aka --all) it gives only the first one in the $PATH.
So I'd have to go with your second strategy:
I suppose you would have to do
vim `/usr/bin/which somecommand`
instead (at least on my system, which is in /usr/bin, not in plain /bin) to
bypass the alias, or else do it manually:
which somecommand # aliased to type -a
vim ~/bin/somecommand
If we want to tweak the command with path priority, then we'd need to
vim .bashrc, to get at the alias. But if we wanted to examine the
underlying shell script which constitutes "which", then it'd be
vim /bin/which, since /usr/bin/which is just a link to that anyway.
Not here:
linux:~ # type -a which
which is /usr/bin/which
which is /usr/bin/X11/which
linux:~ # ls -l /usr/bin/X11
lrwxrwxrwx 1 root root 1 Jul 13 17:13 /usr/bin/X11 -> ./
linux:~ # ls -l /usr/bin/which
-rwxr-xr-x 1 root root 23144 Nov 5 2012 /usr/bin/which*
linux:~ # ls -l /bin/which
ls: cannot access /bin/which: No such file or directory
Finding stuff in the filesystem is, at least here, a greater challenge
than invoking vim on a specific file, so maximising transparency has the
greater payoff, I find. Making an informed choice on which alternative
to edit seems to beat a tiny bit of automation, I figure. But needs
differ, I'll accept.
Here's wishing a happy new year to all Vimmers. (Under an hour and a half
away here.)
Erik
Sure, happy new year to you all, though on _my_ clock it's only about
13:02 on the 31 as I type this.
Best regards,
Tony.
--
The makers may make
and the users may use,
but the fixers must fix
with but minimal clues
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
