> On 2015-08-21, David Brown <david.brown@hesbynett.no> wrote:
>> On 20/08/15 23:05, Grant Edwards wrote:
>>> On 2015-08-20, David Brown <david.brown@hesbynett.no> wrote:
>>>
> [...]
>>>>
>>>> However, you can happily use colons in directories for any other purpose
>>>> - they just need escaping with \: or "" in some situations.
>>>
>>> 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.
>>
>> 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.
>
> Probably so.
>
>> Shells should have no problem with escaped colons, nor do the common
>> command-line utilities, system calls, library functions, etc.
>
> True.
>
>>>> Colons are regularly used as separators in paths in Linux, especially
>>>> in /sys, and are perfectly suitable for the job.
>>>
>>> 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.
>>
>> All I can tell you is that colons /are/ used in file and directory
>> names in many situations on Linux systems.
>
> 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
Reply by Grant Edwards●August 21, 20152015-08-21
On 2015-08-21, David Brown <david.brown@hesbynett.no> wrote:
> On 20/08/15 23:05, Grant Edwards wrote:
>> On 2015-08-20, David Brown <david.brown@hesbynett.no> wrote:
>>
[...]
>>>
>>> However, you can happily use colons in directories for any other purpose
>>> - they just need escaping with \: or "" in some situations.
>>
>> 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.
>
> 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.
Probably so.
> Shells should have no problem with escaped colons, nor do the common
> command-line utilities, system calls, library functions, etc.
True.
>>> Colons are regularly used as separators in paths in Linux, especially
>>> in /sys, and are perfectly suitable for the job.
>>
>> 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.
>
> All I can tell you is that colons /are/ used in file and directory
> names in many situations on Linux systems.
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.
--
Grant Edwards grant.b.edwards Yow! ... he dominates the
at DECADENT SUBWAY SCENE.
gmail.com
Reply by David Brown●August 21, 20152015-08-21
On 20/08/15 23:05, Grant Edwards wrote:
> On 2015-08-20, David Brown <david.brown@hesbynett.no> wrote:
>
>> 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.
>
> 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.
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.
>
>> Colons are regularly used as separators in paths in Linux, especially
>> in /sys, and are perfectly suitable for the job.
>
> 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.
>
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.
Reply by Grant Edwards●August 20, 20152015-08-20
On 2015-08-20, David Brown <david.brown@hesbynett.no> wrote:
> 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.
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.
> Colons are regularly used as separators in paths in Linux, especially
> in /sys, and are perfectly suitable for the job.
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.
--
Grant Edwards grant.b.edwards Yow! With YOU, I can be
at MYSELF ... We don't NEED
gmail.com Dan Rather ...
Reply by David Brown●August 20, 20152015-08-20
On 20/08/15 21:25, Hans-Bernhard Bröker wrote:
> Am 20.08.2015 um 20:42 schrieb Theo Markettos:
>> Hans-Bernhard Bröker <HBBroeker@t-online.de> wrote:
>
>>> 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
>>
>> That is true, but you can avoid the problems by escaping by preceding
>> the :
>> with \ - ie some\:file.
>
> 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.
Reply by Hans-Bernhard Bröker●August 20, 20152015-08-20
>> 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
>
> That is true, but you can avoid the problems by escaping by preceding the :
> with \ - ie some\:file.
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.
> Am 18.08.2015 um 19:38 schrieb Robert Wessel:
>
> > A colon has no special meaning in *nix for a file or device name.
>
> 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
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:
> So, for the sake of continued sanity: don't do that.
Amen to that.
Theo
Reply by Hans-Bernhard Bröker●August 18, 20152015-08-18
Am 18.08.2015 um 19:38 schrieb Robert Wessel:
> A colon has no special meaning in *nix for a file or device name.
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.
Reply by Robert Wessel●August 18, 20152015-08-18
On Tue, 18 Aug 2015 07:44:32 -0700 (PDT), Robert Willy
<rxjwg98@gmail.com> wrote:
>Hi,
>
>I posted this question on BeagleBone group, but there is no reply to my
> question. I hope that somebody here can help.
>
>
>I see the following message from a link:
>http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone//blog/2013/11/22/beaglebone-web-server--led-blinking
>
>
>
>root@bbb-deb:~-- $ ls -l /sys/class/leds/beaglebone:*:*/brightness
>-rw-r--r-- 1 root root 4096 Nov 22 13:35 /sys/class/leds/beaglebone:green:usr0/brightness
>-rw-r--r-- 1 root root 4096 Nov 22 13:35 /sys/class/leds/beaglebone:green:usr1/brightness
>-rw-r--r-- 1 root root 4096 Nov 22 01:30 /sys/class/leds/beaglebone:green:usr2/brightness
>-rw-r--r-- 1 root root 4096 Nov 22 13:35 /sys/class/leds/beaglebone:green:usr3/brightness
>
>It is the first time I see ':' in a path. Whether is it just like a general character in the path, or having special meaning?
A colon has no special meaning in *nix for a file or device name.
Reply by Robert Willy●August 18, 20152015-08-18
Hi,
I posted this question on BeagleBone group, but there is no reply to my
question. I hope that somebody here can help.
I see the following message from a link:
http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone//blog/2013/11/22/beaglebone-web-server--led-blinking
root@bbb-deb:~-- $ ls -l /sys/class/leds/beaglebone:*:*/brightness
-rw-r--r-- 1 root root 4096 Nov 22 13:35 /sys/class/leds/beaglebone:green:usr0/brightness
-rw-r--r-- 1 root root 4096 Nov 22 13:35 /sys/class/leds/beaglebone:green:usr1/brightness
-rw-r--r-- 1 root root 4096 Nov 22 01:30 /sys/class/leds/beaglebone:green:usr2/brightness
-rw-r--r-- 1 root root 4096 Nov 22 13:35 /sys/class/leds/beaglebone:green:usr3/brightness
It is the first time I see ':' in a path. Whether is it just like a general character in the path, or having special meaning?
I am new to Linux yet, though using for some time.
Thanks,