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 {}.


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: