* [Bug manual/16073] Improve the manual on symbolic links
[not found] <bug-16073-131@http.sourceware.org/bugzilla/>
@ 2013-10-25 21:54 ` mtk.manpages at gmail dot com
2013-10-25 22:01 ` roland at gnu dot org
` (3 subsequent siblings)
4 siblings, 0 replies; 5+ messages in thread
From: mtk.manpages at gmail dot com @ 2013-10-25 21:54 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16073
--- Comment #1 from Michael Kerrisk <mtk.manpages at gmail dot com> ---
Fabrice,
This is on a bit of a tangent, but from a man-pages perspective I agree. The
man page used the same naming scheme, and the poor names were a nagging itch
that I never quite scratched. Your bug report for the libc manual prompted me
to change the man page, where I've used the names 'filepath' and 'linkpath'. I
mildly prefer 'filepath' over 'target', but 'target' is not a bad name either.
Cheers,
Michael
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread* [Bug manual/16073] Improve the manual on symbolic links
[not found] <bug-16073-131@http.sourceware.org/bugzilla/>
2013-10-25 21:54 ` [Bug manual/16073] Improve the manual on symbolic links mtk.manpages at gmail dot com
@ 2013-10-25 22:01 ` roland at gnu dot org
2013-10-26 8:26 ` libnoon at gmail dot com
` (2 subsequent siblings)
4 siblings, 0 replies; 5+ messages in thread
From: roland at gnu dot org @ 2013-10-25 22:01 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16073
--- Comment #2 from Roland McGrath <roland at gnu dot org> ---
Note that in GNU documentation the norm is never to use "path" in the POSIX
sense, because it can be confused with cases like PATH (and LD_LIBRARY_PATH and
so on). GNU reserves "path" for the "search path" sorts of cases, and uses
"file name" for what POSIX calls "pathname" and "file name component" for the
smaller unit of naming.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread* [Bug manual/16073] Improve the manual on symbolic links
[not found] <bug-16073-131@http.sourceware.org/bugzilla/>
2013-10-25 21:54 ` [Bug manual/16073] Improve the manual on symbolic links mtk.manpages at gmail dot com
2013-10-25 22:01 ` roland at gnu dot org
@ 2013-10-26 8:26 ` libnoon at gmail dot com
2013-10-30 1:54 ` mtk.manpages at gmail dot com
2014-06-13 12:35 ` fweimer at redhat dot com
4 siblings, 0 replies; 5+ messages in thread
From: libnoon at gmail dot com @ 2013-10-26 8:26 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16073
--- Comment #3 from Fabrice Bauzac <libnoon at gmail dot com> ---
There are cases where the symlink() system call is used not for linking to
another file, but for the fact that it is a simple way of atomically writing an
arbitrary string into the filesystem. This is useful for some synchronization
use cases I have worked on. And that is why I would prefer the term "CONTENTS"
or "TARGET" rather than "FILENAME" because it can really be an arbitrary string
that will never point to an actual file.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread* [Bug manual/16073] Improve the manual on symbolic links
[not found] <bug-16073-131@http.sourceware.org/bugzilla/>
` (2 preceding siblings ...)
2013-10-26 8:26 ` libnoon at gmail dot com
@ 2013-10-30 1:54 ` mtk.manpages at gmail dot com
2014-06-13 12:35 ` fweimer at redhat dot com
4 siblings, 0 replies; 5+ messages in thread
From: mtk.manpages at gmail dot com @ 2013-10-30 1:54 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16073
--- Comment #4 from Michael Kerrisk <mtk.manpages at gmail dot com> ---
(In reply to Fabrice Bauzac from comment #3)
> There are cases where the symlink() system call is used not for linking to
> another file, but for the fact that it is a simple way of atomically writing
> an arbitrary string into the filesystem. This is useful for some
> synchronization use cases I have worked on. And that is why I would prefer
> the term "CONTENTS" or "TARGET" rather than "FILENAME" because it can really
> be an arbitrary string that will never point to an actual file.
Fair enough. I, the man page, I made the first argument "target".
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread* [Bug manual/16073] Improve the manual on symbolic links
[not found] <bug-16073-131@http.sourceware.org/bugzilla/>
` (3 preceding siblings ...)
2013-10-30 1:54 ` mtk.manpages at gmail dot com
@ 2014-06-13 12:35 ` fweimer at redhat dot com
4 siblings, 0 replies; 5+ messages in thread
From: fweimer at redhat dot com @ 2014-06-13 12:35 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16073
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags| |security-
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread