Re: Completion: Tilde and environment variables
- From: <tpgww@xxxxxxxxxxx>
- To: emelfm2@xxxxxxxxxxxxx
- Date: Tue, 3 Mar 2009 12:56:16 +1100
On Mon, 2 Mar 2009 14:24:17 +0100
kba <unixprog@xxxxxxxxxxxxxx> wrote:
> > I forgot to mention - 0.5.1 does not cope with any $VAR in a
> > commandline generally. It expects any $VAR to be distinct - at end of
> > string or surrounded by whitespace. As it happens, I fixed this about
> > a day after 0.5.1 release, and is now in svn. But even so, $VAR
> > interpretation is not entirely structureless. If VAR is internal, we
> > can check easily enough whether "$VAR<any text>" is meant to include
> > that a variable. But for externals, there's too many combinations of
> > variable and text to evaluate. So for externals you must use {}
> > delimiters e.g. /path/${DATA}/subdir.
>
> This also works now and I have no problem with curly braces. However, I
> don't really understand, why internal variable names can contain '/'. In
> the shell (bash, zsh),'/' can't be part of a variable name. Is there a
> special reason to allow it in emelfm2? If every whitespace and every '/'
> was an obvious variable name delimiter, wouldn't it be possible to use
> '/path/$DATA/subdir' instead of '/path/${DATA}/subdir'?
I just didn't bother to exclude anything from inclusion in an internal
variable. And originally these variables were conceived to assist working with
fuse, in particular remembering and using mount points, hence paths.
Things like /path/${DATA}/subdir are needed only for _external_ variables. It's
easy enough to process the internal ones without using {}.
Regards
Tom
--
Users can unsubscribe from the list by sending email to
emelfm2-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field or by
logging into the web interface.
Other related posts: