[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: GNU Arch review - am I accurate?

From: Sylvain Defresne
Subject: Re: [Gnu-arch-users] Re: GNU Arch review - am I accurate?
Date: Fri, 12 Mar 2004 00:19:14 +0100

On Wed, 2004-03-10 at 04:13, David A. Wheeler wrote:
> > I suspect they interfere far less than you think, though.
> That may be.  Certainly, if you never use vim, vi, or more,
> you're much less likely to encounter the "+" problem, and
> if you don't use bash file completion, you won't notice
> any problems with "=".
> But vim is one of the most popular text editors, and bash
> is one of the most popular shells.  If there are alternative
> conventions that are just as reasonable, but easier to use,
> I'd like to see them considered.  Prefix "^" and "@" seem
> the most likely so far, but I don't really care what they are,
> as long as they work cleanly with nearly all tools.
> Why let silly little details (like default filename conventions)
> distract from the good stuff?

Well, '@' is not a valid alternative since it encounter the same "bug"
in bash that '=' is doing. Actually, I'd like to know what you consider
a bug in the handlign of '=' character in completion in bash. If the
problem is that bash it mess completion and the '=' is handled as if the
previous character was a ' ', then it is the intended behaviour since it
allow to use completion in variable assignment. So, you would get:

$ export PATH=/some/convo<tab>
$ export PATH=/some/convoluted-path

But it is true that the bash completion code is not smart enough to
detect when '=' is not preceded by a valid variable name and to not
interpret it as a character delimiter word. Maybe this is what you call
a bug ... But if it is the whole special meaning of the '=' character in
auto-completion, I would not second you on that since I use this feature
of bash almost daily ...

Concerning character that are not in [a-zA-Z0-9], and that have special
meaning in common shell/tools, we find:

        ' ' : common world delimiter (with its relative the tabular

        '=', ':' : are considered as word separators by bash completion
        code ('=' for assignment and ':' for field separator in
        PATH-like variables)
        '@' : bash will then complete using hostname found in /etc/hosts
        '$' : bash will then complete using variable name currently set
        (so that 'echo $PAT<tab>' expand to 'echo $PATH')
        '?', '*' : common globbing characters, cannot be used in
        filename on some FS (FAT, ...)
        '(', ')', '{', '}' : used to group command with or without using
        an auxilliarry sub-shell
        '-' : used by nearly all command to start options
        '&', '|', ';' : used by most of the shell for job control
        '"', ''' : used to quote some portion of the command-line and
        somewhat protect it from word breaking/variable substitution
        '#' : used by bash to start a comment
        '`' : substitute quoted text by command output
        '.' : when used as first character of a filename, it is hidden
        by most of the command-line tool (hidden file)
        '!' : used to call abck command from history (with bash)
        '/' : path separator, can not be used in a filename
        '%' : IIRC it is the equivalent of '$' in windows world
        '+' : used to include ':'-command in the invocation of vi/vim (I
        personnally use daily the following function :
        'tag () { vim "+tag $1" }' that launch vim, and then jump to the
        ',' : is the comma-operator of the find utility 'find', thus it
        is fooled by command like "find ,,undo -name '*.c'"
        '<', '>' : used for file-descriptor manipulation when launching
        '[', ']' : used to give a range of character in
        filename-expansion, for example:
        $ touch aaa aba aca
        $ echo a[ac]a
        aaa aca

        '\' can be used to protect interpretation of almost all of those
        special character from the shell (but not from other command,
        thus '+' and ',' still give problem to vim and find)

Each of those characters either pose portability problems (for example
'*' is invalid in a filename on Windows, but not on Linux), fool some
common tools, cause trouble with (bash) auto-completion, or can cause
strange expansion with the shell, or can break some other command (I
didn't intend the previous list to be exhaustive). To be usable almost
all of them would require some protection (either from absh, or the

Removing all those character and those in '[a-zA-Z0-9]', and considering
only those that are easy to write, remains (in ASCII): '^', '_'. It's
not that much, and they may have some other problem that I have not
still seen (for example, '^' has special meaning in bash after either a
'!' or a '['). And concerning '_', it is generally used by people that
dislike space in filename to replace them, and thus may not be safe as
it could be taken by user.

So, as you can see, there is not many character that can be used safely
as prefix for tla special files. In fact, '=' and '+' may be two of the
less problematic characters, since they only cause problem with one
program each :)

And as other people have already said, you almost never directly edit
those file, so tla nameing-convention should never bother you.

Sorry for this completely off-topic post, and for stepping in this
flamewar ... Going back to work ... And please excuse me for the rather
harsh language at the beginning ...
Sylvain Defresne                               <address@hidden>
1024D/A036DDB1 6AB9 B65F 7C44 819F DD42  62D2 A093 2840 A036 DDB1

Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]