Re: Where is my system-wide init file?

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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.