What is the field (separated by :) in the file path listing?

A colon has no special meaning in *nix for a file or device name.

But it does have a special meaning to some programs (such as those that interpret the $PATH variable), so normally it's best to avoid it if you are the one who assigns path names.

The kernel, however, treats nothing special other than '\0' and '/'.

Stefan

Am 18.08.2015 um 19:38 schrieb Robert Wessel:

It would make for rather interesting problems if it ends up in the pathname of some directory that you wanted to add to PATH, INCLUDE_PATH or some similar sequence of directory names, though, since those are conventionally separated by colons, on Unix ;-P

So, for the sake of continued sanity: don't do that.

That is true, but you can avoid the problems by escaping by preceding the : with \ - ie some\:file. The same is true for spaces, quotes and other characters you wouldn't be able to write in the shell. However escaping can go wrong in all kinds of fun and exciting ways, so:

Amen to that.

Theo

Am 20.08.2015 um 20:42 schrieb Theo Markettos:

I didn't believe that, so I tried, and indeed: it didn't work. PATH doesn't treat a "\:" any different from a plain ':'. Both separate two directory names to be inspected.

The problem at hand is not with _getting_ a ':' into $PATH; it's with making it act as part of a given entry, rather than a separator between paths. AFAICT, there is no way to do that.

This is correct (AFAIK) - the handling of $PATH does not support any kind of escaping. I think it's okay to have spaces in $PATH directories, and you don't need "" or \ escaping - but there is no way to have a directory with a colon in the $PATH.

However, you can happily use colons in directories for any other purpose

- they just need escaping with \: or "" in some situations. Colons are regularly used as separators in paths in Linux, especially in /sys, and are perfectly suitable for the job. In particular, you are never going to want these directories in your $PATH - having a colon in the directory name is arguably a way to protect against that.

And if you really need to put a weirdly named directory on your $PATH, then symlinks will help you out.

Are you sure about that? I think there may be other situations where colons are a problem. For example, /etc/passwd doesn't seem to allow colons in home directory path strings. In passwd(5), I don't find any mention of escaping colons. I've tried various methods to escape/quote a colon in a home directory name and none of them work. Curiously, colons in shell paths seem to be deleted: a shell path of /usr/bin/fo:o executes /usr/bin/foo as the login shell.

Colon was also commonly used as a column separator in flat-field text database files (such as /etc/passwd). More sophisticated parsers of such files probably allow for some sort of quoting or escaping, but I wouldn't be surprised if it causes problems in a few situations.

No, I'm not sure that colons can be used /everywhere/ - it will of course depend on the program that uses them, and how programs handle escaping or give special treatment to the colon. Apparently glibc does not handle escaping in $PATH in execvp, and probably the same issue occurs for any other colon-separated lists. If you can't use colons in directories or filenames in /etc/passwd, then that's a failing in login.

Shells should have no problem with escaped colons, nor do the common command-line utilities, system calls, library functions, etc.

All I can tell you is that colons /are/ used in file and directory names in many situations on Linux systems. The use shown by the OP is very common. It may well be that you'll have trouble trying to use an LED as your home directory, but I don't see that as a serious problem!

Of course, it is often convenient to use names that don't need any form of escaping, or any non-ASCII characters, especially for something like $PATH, program names, and home directories. But the use of colons, dashes, and other symbols in constructed names (such as for the LEDs here) can make it easy for software to parse these names into their parts.

Probably so.

True.

No argument from me on that -- I was just pointing out that there are purposes other than $PATH where you can't use them. But, as you say, they are few and far between.

That's the great thing about Usenet - it's a self-correcting medium! Thanks for the corrections.

David