On 2009-02-10, Matt Wozniski <[email protected]> wrote: > On Tue, Feb 10, 2009 at 5:58 PM, Gary Johnson wrote: > > > > On 2009-02-10, Tony Mechelynck wrote:
> >> In Console mode, or when started in GUI mode from a shell, this should > >> not be a problem, since in that case Vim runs in an environment set up > >> by an earlier (interactive) shell, and passes that to every child process. > > > > It's still a problem because unlike environment variables, aliases > > are not exported to child processes. (I think there are some > > exceptions to this, but they don't apply in this case anyway.) > > There are no exceptions to this. Aliases are held within a shell, > there's no way to "pass" an alias to another process. Some shells have an alias command that takes a -x option which is supposed to export the specified alias. For example, http://www.mkssoftware.com/docs/man1/alias.1.asp says, -x marks each alias name on the command line for export. If you specify -x without any names, alias displays all exported aliases. Only exported aliases are passed to a shell that runs a shell script (that is, script.ksh). I think that means that if you are running an instance of that shell and you launch a shell script from it, that shell script can inherit exported aliases. However, if from that first shell you launched some other program, such as vim, and from that program you launched a shell, that second shell would not inherit any aliases. I don't have access to a shell that it supposed to do that, though, so I can't test it. The ksh man page on the Linux system running nearby says, The -x option sets (+x clears) the export attribute of an alias, or, if no names are given, lists the aliases with the export attribute (exporting an alias has no affect[sic]). Regards, Gary --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
