[1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
The following issue has a resolution that has been APPLIED. == https://austingroupbugs.net/view.php?id=1457 == Reported By:steffen Assigned To:ajosey == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1457 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Applied Name: Steffen Nurpmeso Organization: User Reference: Section:Vol. 3: Shell and Utilities. Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text:https://austingroupbugs.net/view.php?id=1457#c6079 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2021-03-09 21:21 UTC Last Modified: 2022-11-24 10:09 UTC == Summary:Add readlink(1) utility == Issue History Date ModifiedUsername FieldChange == 2021-03-09 21:21 steffenNew Issue 2021-03-09 21:21 steffenStatus New => Under Review 2021-03-09 21:21 steffenAssigned To => ajosey 2021-03-09 21:21 steffenName => Steffen Nurpmeso 2021-03-09 21:21 steffenSection => Vol. 3: Shell and Utilities. 2021-03-09 21:21 steffenPage Number => (page or range of pages) 2021-03-09 21:21 steffenLine Number => (Line or range of lines) 2021-03-10 04:11 emaste Issue Monitored: emaste 2022-02-22 15:58 geoffclare Note Added: 0005700 2022-02-22 16:01 geoffclare Note Edited: 0005700 2022-02-22 16:09 geoffclare Note Edited: 0005700 2022-02-22 16:11 geoffclare Project 1003.1(2008)/Issue 7 => 1003.1(2016/18)/Issue7+TC2 2022-02-22 16:13 geoffclare Note Edited: 0005700 2022-02-22 21:39 emaste Note Added: 0005701 2022-02-22 21:41 emaste Note Deleted: 0005701 2022-02-22 22:19 steffenNote Added: 0005702 2022-02-22 22:34 calestyo Issue Monitored: calestyo 2022-02-23 08:32 geoffclare Note Added: 0005703 2022-02-23 13:31 emaste Note Added: 0005704 2022-02-23 13:38 calestyo Note Added: 0005705 2022-02-24 09:28 geoffclare Note Added: 0005706 2022-02-24 09:32 geoffclare Note Edited: 0005700 2022-02-24 09:34 geoffclare Note Edited: 0005700 2022-02-24 09:36 geoffclare Note Edited: 0005703 2022-02-25 21:24 mirabilos Note Added: 0005721 2022-07-21 10:41 geoffclare Note Added: 0005898 2022-07-21 10:42 geoffclare Note Edited: 0005898 2022-07-21 10:45 geoffclare Note Added: 0005899 2022-07-21 10:47 geoffclare Note Edited: 0005899 2022-07-21 10:57 geoffclare Note Edited: 0005898 2022-07-21 11:15 kreNote Added: 0005900 2022-07-21 11:45 kreNote Added: 0005901 2022-07-29 14:16 geoffclare Note Added: 0005921 2022-11-21 16:12 geoffclare Note Added: 0006079 2022-11-21 16:13 geoffclare Interp Status => --- 2022-11-21 16:13 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1457#c6079 2022-11-21 16:13 geoffclare Status Under Review => Resolved 2022-11-21 16:13 geoffclare Resolution Open => Accepted As Marked 2022-11-21 16:14 geoffclare Tag Attached: issue8 2022-11-24 10:09 geoffclare Status Resolved => Applied ==
[1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
The following issue has been RESOLVED. == https://austingroupbugs.net/view.php?id=1457 == Reported By:steffen Assigned To:ajosey == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1457 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Resolved Name: Steffen Nurpmeso Organization: User Reference: Section:Vol. 3: Shell and Utilities. Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text:https://austingroupbugs.net/view.php?id=1457#c6079 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2021-03-09 21:21 UTC Last Modified: 2022-11-21 16:13 UTC == Summary:Add readlink(1) utility == Issue History Date ModifiedUsername FieldChange == 2021-03-09 21:21 steffenNew Issue 2021-03-09 21:21 steffenStatus New => Under Review 2021-03-09 21:21 steffenAssigned To => ajosey 2021-03-09 21:21 steffenName => Steffen Nurpmeso 2021-03-09 21:21 steffenSection => Vol. 3: Shell and Utilities. 2021-03-09 21:21 steffenPage Number => (page or range of pages) 2021-03-09 21:21 steffenLine Number => (Line or range of lines) 2021-03-10 04:11 emaste Issue Monitored: emaste 2022-02-22 15:58 geoffclare Note Added: 0005700 2022-02-22 16:01 geoffclare Note Edited: 0005700 2022-02-22 16:09 geoffclare Note Edited: 0005700 2022-02-22 16:11 geoffclare Project 1003.1(2008)/Issue 7 => 1003.1(2016/18)/Issue7+TC2 2022-02-22 16:13 geoffclare Note Edited: 0005700 2022-02-22 21:39 emaste Note Added: 0005701 2022-02-22 21:41 emaste Note Deleted: 0005701 2022-02-22 22:19 steffenNote Added: 0005702 2022-02-22 22:34 calestyo Issue Monitored: calestyo 2022-02-23 08:32 geoffclare Note Added: 0005703 2022-02-23 13:31 emaste Note Added: 0005704 2022-02-23 13:38 calestyo Note Added: 0005705 2022-02-24 09:28 geoffclare Note Added: 0005706 2022-02-24 09:32 geoffclare Note Edited: 0005700 2022-02-24 09:34 geoffclare Note Edited: 0005700 2022-02-24 09:36 geoffclare Note Edited: 0005703 2022-02-25 21:24 mirabilos Note Added: 0005721 2022-07-21 10:41 geoffclare Note Added: 0005898 2022-07-21 10:42 geoffclare Note Edited: 0005898 2022-07-21 10:45 geoffclare Note Added: 0005899 2022-07-21 10:47 geoffclare Note Edited: 0005899 2022-07-21 10:57 geoffclare Note Edited: 0005898 2022-07-21 11:15 kreNote Added: 0005900 2022-07-21 11:45 kreNote Added: 0005901 2022-07-29 14:16 geoffclare Note Added: 0005921 2022-11-21 16:12 geoffclare Note Added: 0006079 2022-11-21 16:13 geoffclare Interp Status => --- 2022-11-21 16:13 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1457#c6079 2022-11-21 16:13 geoffclare Status Under Review => Resolved 2022-11-21 16:13 geoffclare Resolution Open => Accepted As Marked ==
[1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1457 == Reported By:steffen Assigned To:ajosey == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1457 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Under Review Name: Steffen Nurpmeso Organization: User Reference: Section:Vol. 3: Shell and Utilities. Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2021-03-09 21:21 UTC Last Modified: 2022-11-21 16:12 UTC == Summary:Add readlink(1) utility == -- (0006079) geoffclare (manager) - 2022-11-21 16:12 https://austingroupbugs.net/view.php?id=1457#c6079 -- Make the changes from "Additional APIs for Issue 8, Part 2" (Austin/1273). Issue History Date ModifiedUsername FieldChange == 2021-03-09 21:21 steffenNew Issue 2021-03-09 21:21 steffenStatus New => Under Review 2021-03-09 21:21 steffenAssigned To => ajosey 2021-03-09 21:21 steffenName => Steffen Nurpmeso 2021-03-09 21:21 steffenSection => Vol. 3: Shell and Utilities. 2021-03-09 21:21 steffenPage Number => (page or range of pages) 2021-03-09 21:21 steffenLine Number => (Line or range of lines) 2021-03-10 04:11 emaste Issue Monitored: emaste 2022-02-22 15:58 geoffclare Note Added: 0005700 2022-02-22 16:01 geoffclare Note Edited: 0005700 2022-02-22 16:09 geoffclare Note Edited: 0005700 2022-02-22 16:11 geoffclare Project 1003.1(2008)/Issue 7 => 1003.1(2016/18)/Issue7+TC2 2022-02-22 16:13 geoffclare Note Edited: 0005700 2022-02-22 21:39 emaste Note Added: 0005701 2022-02-22 21:41 emaste Note Deleted: 0005701 2022-02-22 22:19 steffenNote Added: 0005702 2022-02-22 22:34 calestyo Issue Monitored: calestyo 2022-02-23 08:32 geoffclare Note Added: 0005703 2022-02-23 13:31 emaste Note Added: 0005704 2022-02-23 13:38 calestyo Note Added: 0005705 2022-02-24 09:28 geoffclare Note Added: 0005706 2022-02-24 09:32 geoffclare Note Edited: 0005700 2022-02-24 09:34 geoffclare Note Edited: 0005700 2022-02-24 09:36 geoffclare Note Edited: 0005703 2022-02-25 21:24 mirabilos Note Added: 0005721 2022-07-21 10:41 geoffclare Note Added: 0005898 2022-07-21 10:42 geoffclare Note Edited: 0005898 2022-07-21 10:45 geoffclare Note Added: 0005899 2022-07-21 10:47 geoffclare Note Edited: 0005899 2022-07-21 10:57 geoffclare Note Edited: 0005898 2022-07-21 11:15 kreNote Added: 0005900 2022-07-21 11:45 kreNote Added: 0005901 2022-07-29 14:16 geoffclare Note Added: 0005921 2022-11-21 16:12 geoffclare Note Added: 0006079 ==
[1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1457 == Reported By:steffen Assigned To:ajosey == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1457 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Under Review Name: Steffen Nurpmeso Organization: User Reference: Section:Vol. 3: Shell and Utilities. Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2021-03-09 21:21 UTC Last Modified: 2022-07-29 14:16 UTC == Summary:Add readlink(1) utility == -- (0005921) geoffclare (manager) - 2022-07-29 14:16 https://austingroupbugs.net/view.php?id=1457#c5921 -- The readlink and realpath additions have been made in the Issue8NewAPIs branch in gitlab, based on https://austingroupbugs.net/view.php?id=1457#c5898. Issue History Date ModifiedUsername FieldChange == 2021-03-09 21:21 steffenNew Issue 2021-03-09 21:21 steffenStatus New => Under Review 2021-03-09 21:21 steffenAssigned To => ajosey 2021-03-09 21:21 steffenName => Steffen Nurpmeso 2021-03-09 21:21 steffenSection => Vol. 3: Shell and Utilities. 2021-03-09 21:21 steffenPage Number => (page or range of pages) 2021-03-09 21:21 steffenLine Number => (Line or range of lines) 2021-03-10 04:11 emaste Issue Monitored: emaste 2022-02-22 15:58 geoffclare Note Added: 0005700 2022-02-22 16:01 geoffclare Note Edited: 0005700 2022-02-22 16:09 geoffclare Note Edited: 0005700 2022-02-22 16:11 geoffclare Project 1003.1(2008)/Issue 7 => 1003.1(2016/18)/Issue7+TC2 2022-02-22 16:13 geoffclare Note Edited: 0005700 2022-02-22 21:39 emaste Note Added: 0005701 2022-02-22 21:41 emaste Note Deleted: 0005701 2022-02-22 22:19 steffenNote Added: 0005702 2022-02-22 22:34 calestyo Issue Monitored: calestyo 2022-02-23 08:32 geoffclare Note Added: 0005703 2022-02-23 13:31 emaste Note Added: 0005704 2022-02-23 13:38 calestyo Note Added: 0005705 2022-02-24 09:28 geoffclare Note Added: 0005706 2022-02-24 09:32 geoffclare Note Edited: 0005700 2022-02-24 09:34 geoffclare Note Edited: 0005700 2022-02-24 09:36 geoffclare Note Edited: 0005703 2022-02-25 21:24 mirabilos Note Added: 0005721 2022-07-21 10:41 geoffclare Note Added: 0005898 2022-07-21 10:42 geoffclare Note Edited: 0005898 2022-07-21 10:45 geoffclare Note Added: 0005899 2022-07-21 10:47 geoffclare Note Edited: 0005899 2022-07-21 10:57 geoffclare Note Edited: 0005898 2022-07-21 11:15 kreNote Added: 0005900 2022-07-21 11:45 kreNote Added: 0005901 2022-07-29 14:16 geoffclare Note Added: 0005921 ==
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
On Fri, Jul 22, 2022 at 05:04:09PM +0100, Jonathan Wakely wrote: > On Fri, 22 Jul 2022 at 15:53, Robert Elz via austin-group-l at The > Open Group wrote: > > Aside from that possibility the only reason would seem to be the same > > as why echo (real ones) have -n (and trashy ones have \c) and why > > printf(1) needs a \n to print one ... there are times that it is useful > > to write a partial line to stdout (or wherever) and there's no reason > > that the output of readlink could not be intended to be a part of such > > a gradually constructed output line. > > But then shouldn't *every* command that prints output have a -n option? > > If you need to include the output of readlink in gradually constructed > output you can do what you have to do with other commands: > > printf '%s' "$(readlink foo)" That strips trailing newlines that may have been important. The link contents $'abc' and $'abc\n' are indecipherable under your approach of a path through $() and printf. If you are going to output a constructed filename to stdout, you really DO want: readlink -n foo && echo /newfile to produce the output "link/content/newfile" when foo contains 'link/content', and still handle the case where foo's content is instead something with a trailing newline. > > The fact that echo and printf have that feature means you don't need > it everywhere. You don't need it for utilities that are seldom used in generating partial file names; but for programs like dirname and readlink, providing a simpler way to use the utility in the context of building up a larger file name without losing intermediate trailing newlines that would be eaten by $() is enough of a worry that adding things like -n to make it more useful was worthwhile to the implementors. I'm aware that 'dirname -n' is not common implementation practice, but since 'readlink -n' does appear to be, there's no harm in standardizing it that way. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
On Fri, 22 Jul 2022 at 15:53, Robert Elz via austin-group-l at The Open Group wrote: > Aside from that possibility the only reason would seem to be the same > as why echo (real ones) have -n (and trashy ones have \c) and why > printf(1) needs a \n to print one ... there are times that it is useful > to write a partial line to stdout (or wherever) and there's no reason > that the output of readlink could not be intended to be a part of such > a gradually constructed output line. But then shouldn't *every* command that prints output have a -n option? If you need to include the output of readlink in gradually constructed output you can do what you have to do with other commands: printf '%s' "$(readlink foo)" The fact that echo and printf have that feature means you don't need it everywhere.
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
Date:Fri, 22 Jul 2022 07:58:47 -0500 From:"Eric Blake via austin-group-l at The Open Group" Message-ID: <20220722125847.tidcrt7a6ntvy...@redhat.com> | [If readlink is implemented as a shell builtin, then you could have an | extension where: | | readlink -v var -n -- "$name" If something like that were implemented, the -n would be a waste of space (there) the variable would always be assigned the value of the symlink, the -n is only to suppress the \n that is printed after that when writing it to stdout. The uses in cmdsubs you dissected are clearly not what -n is intended for (though I wonder if perhaps something similar in csh, if that ability is there - it has been so long since I looked at that - might have a different outcome). Aside from that possibility the only reason would seem to be the same as why echo (real ones) have -n (and trashy ones have \c) and why printf(1) needs a \n to print one ... there are times that it is useful to write a partial line to stdout (or wherever) and there's no reason that the output of readlink could not be intended to be a part of such a gradually constructed output line. kre
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
On Fri, Jul 22, 2022 at 09:26:45AM +0200, Quentin Rameau via austin-group-l at
The Open Group wrote:
> Hello,
>
> > ==
> > https://austingroupbugs.net/view.php?id=1457
> > ==
>
> > ==
> > Summary:Add readlink(1) utility
> > ==
>
> > -nDo not output a trailing
> > character.
>
> Out of curiosity, what's a use-case for that?
Good question. My initial thought was that the construct:
var=$(readlink -- "$name")
will NOT assign var to the correct contents if $name is a symlink that
resolves to a string containing trailing newlines, as $() would strip
not only the newline added by readlink, but also the newlines from the
link contents. But using:
var=$(readlink -n -- "$name")
will not fare any better; it will also strip trailing newlines from
the link content. The only reliable way to accurately capture the
contents of a symlink in a shell variable is to do something like:
tmp=$(readlink -n -- "$name"; printf .)
var=${tmp%.}
at which point the addition of -n doesn't really help, because you
could also do:
tmp=$(readlink -- "$name"; printf .)
var=${tmp%?.}
with fewer characters typed.
So the only actual answer I can come up with is "existing practice in
readlink implementations in the wild", where we'd have to ask the
program designers why they thought -n was useful.
[If readlink is implemented as a shell builtin, then you could have an
extension where:
readlink -v var -n -- "$name"
assigns $var to the full symlink contents, without any extra or
stripped newlines, but such an extension is not what we are proposing
to standardize]
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
Hello, > == > https://austingroupbugs.net/view.php?id=1457 > == > == > Summary:Add readlink(1) utility > == > -nDo not output a trailing > character. Out of curiosity, what's a use-case for that?
[1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1457 == Reported By:steffen Assigned To:ajosey == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1457 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Under Review Name: Steffen Nurpmeso Organization: User Reference: Section:Vol. 3: Shell and Utilities. Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2021-03-09 21:21 UTC Last Modified: 2022-07-21 11:45 UTC == Summary:Add readlink(1) utility == -- (0005901) kre (reporter) - 2022-07-21 11:45 https://austingroupbugs.net/view.php?id=1457#c5901 -- Also, wrt the now long deleted note#5701, I totally understand how that could have happened - the combined stat(1)+readlink(1) man page was a total mess, and almost impossible to decipher. At NetBSD we have now split it into two entirely separate pages, stat(1) and readlink(1) - the two (conceptually) are totally unrelated utilities. It just happens that they are the same binary, which looks at argv[0]. readlink (as it exists in BSD) is just stat with a particular set of options (which depends upon the options to readlink) - readlink could as easily have been a script that calls stat - except that for some uses it is used a lot, and adding a sh invocation to every call would be costly. But that note 5701 interpreted that messy man page incorrectly doesn't affect the conclusion to omit readlink -f from the standard. The coreutils readlink -f is (effectively) realpath -E (as specified here) and the BSD one is realpath -e - they are not compatible, and adding more options to readlink to "fix" that would be a sub-optimal solution (what's more, the coreutils version could not be implemented as a call to stat, no matter what options are given stat(1) never returns data about files that don't exist (it would have to invent that, and that's not going to happen.) Issue History Date ModifiedUsername FieldChange == 2021-03-09 21:21 steffenNew Issue 2021-03-09 21:21 steffenStatus New => Under Review 2021-03-09 21:21 steffenAssigned To => ajosey 2021-03-09 21:21 steffenName => Steffen Nurpmeso 2021-03-09 21:21 steffenSection => Vol. 3: Shell and Utilities. 2021-03-09 21:21 steffenPage Number => (page or range of pages) 2021-03-09 21:21 steffenLine Number => (Line or range of lines) 2021-03-10 04:11 emaste Issue Monitored: emaste 2022-02-22 15:58 geoffclare Note Added: 0005700 2022-02-22 16:01 geoffclare Note Edited: 0005700 2022-02-22 16:09 geoffclare Note Edited: 0005700 2022-02-22 16:11 geoffclare Project 1003.1(2008)/Issue 7 => 1003.1(2016/18)/Issue7+TC2 2022-02-22 16:13 geoffclare Note Edited: 0005700 2022-02-22 21:39 emaste Note Added: 0005701 2022-02-22 21:41 emaste Note Deleted: 0005701 2022-02-22 22:19 steffenNote Added: 0005702 2022-02-22 22:34 calestyo Issue Monitored: calestyo 2022-02-23 08:32 geoffclare Note Added: 0005703 2022-02-23 13:31 emaste Note Added: 0005704 2022-02-23 13:38 calestyo Note Added: 0005705 2022-02-24 09:28 geoffclare Note Added: 0005706 2022-02-24 09:32 geoffclare Note Edited: 0005700 2022-02-24 09:34 geoffclare Note Edited: 0005700 2022-02-24 09:36 geoffclare Note Edited: 0005703
[1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1457 == Reported By:steffen Assigned To:ajosey == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1457 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Under Review Name: Steffen Nurpmeso Organization: User Reference: Section:Vol. 3: Shell and Utilities. Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2021-03-09 21:21 UTC Last Modified: 2022-07-21 10:45 UTC == Summary:Add readlink(1) utility == -- (0005899) geoffclare (manager) - 2022-07-21 10:45 https://austingroupbugs.net/view.php?id=1457#c5899 -- My thanks to kre for helping to ensure that my proposed realpath page correctly describes the behaviour both of his new implementation for NetBSD and of the GNU coreutils version (once they add a no-op -E option). Issue History Date ModifiedUsername FieldChange == 2021-03-09 21:21 steffenNew Issue 2021-03-09 21:21 steffenStatus New => Under Review 2021-03-09 21:21 steffenAssigned To => ajosey 2021-03-09 21:21 steffenName => Steffen Nurpmeso 2021-03-09 21:21 steffenSection => Vol. 3: Shell and Utilities. 2021-03-09 21:21 steffenPage Number => (page or range of pages) 2021-03-09 21:21 steffenLine Number => (Line or range of lines) 2021-03-10 04:11 emaste Issue Monitored: emaste 2022-02-22 15:58 geoffclare Note Added: 0005700 2022-02-22 16:01 geoffclare Note Edited: 0005700 2022-02-22 16:09 geoffclare Note Edited: 0005700 2022-02-22 16:11 geoffclare Project 1003.1(2008)/Issue 7 => 1003.1(2016/18)/Issue7+TC2 2022-02-22 16:13 geoffclare Note Edited: 0005700 2022-02-22 21:39 emaste Note Added: 0005701 2022-02-22 21:41 emaste Note Deleted: 0005701 2022-02-22 22:19 steffenNote Added: 0005702 2022-02-22 22:34 calestyo Issue Monitored: calestyo 2022-02-23 08:32 geoffclare Note Added: 0005703 2022-02-23 13:31 emaste Note Added: 0005704 2022-02-23 13:38 calestyo Note Added: 0005705 2022-02-24 09:28 geoffclare Note Added: 0005706 2022-02-24 09:32 geoffclare Note Edited: 0005700 2022-02-24 09:34 geoffclare Note Edited: 0005700 2022-02-24 09:36 geoffclare Note Edited: 0005703 2022-02-25 21:24 mirabilos Note Added: 0005721 2022-07-21 10:41 geoffclare Note Added: 0005898 2022-07-21 10:42 geoffclare Note Edited: 0005898 2022-07-21 10:45 geoffclare Note Added: 0005899 ==
[1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1457 == Reported By:steffen Assigned To:ajosey == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1457 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Under Review Name: Steffen Nurpmeso Organization: User Reference: Section:Vol. 3: Shell and Utilities. Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2021-03-09 21:21 UTC Last Modified: 2022-07-21 10:41 UTC == Summary:Add readlink(1) utility == -- (0005898) geoffclare (manager) - 2022-07-21 10:41 https://austingroupbugs.net/view.php?id=1457#c5898 -- New suggested changes... On page 3194 insert new pages for readlink and realpath: NAMEreadlink - display the contents of a symbolic link SYNOPSISreadlink [-n] file DESCRIPTIONIf the file operand names a symbolic link, the readlink utility shall not follow the symbolic link when resolving file and shall write the contents of the symbolic link to standard output. If the -n option is not specified, the output to standard output shall be followed by a character. If file does not name a symbolic link, readlink shall write a diagnostic message to standard error and exit with non-zero status. OPTIONSThe readlink utility shall conform to [xref to XBD 12.2]. The following option shall be supported: -nDo not output a trailing character. OPERANDSfileA pathname of a symbolic link to be read. STDINNot used. INPUT FILESNone. ENVIRONMENT VARIABLESThe following environment variables shall affect the execution of readlink: LANGProvide a default value for the internationalization variables that are unset or null. (See [xref to XBD 8.2] for the precedence of internationalization variables used to determine the values of locale categories.)LC_ALLIf set to a non-empty string value, override the values of all the other internationalization variables.LC_CTYPEDetermine the locale for the interpretation of sequences of bytes of text data as characters (for example, single-byte as opposed to multi-byte characters in arguments).LC_MESSAGESDetermine the locale that should be used to affect the format and contents of diagnostic messages written to standard error.[XSI]NLSPATHDetermine the location of messages objects and message catalogs.[/XSI] ASYNCHRONOUS EVENTSDefault. STDOUTSee DESCRIPTION. STDERRThe standard error shall be used only for diagnostic messages. OUTPUT FILESNone. EXTENDED DESCRIPTIONNone. EXIT STATUSThe following exit values shall be returned: 0 Successful completion. >0 An error occurred. CONSEQUENCES OF ERRORSDefault. APPLICATION USAGENone. EXAMPLESNone. RATIONALEThe readlink utility was added because using ls -l to obtain the contents of a symbolic link is difficult if the output includes more than one occurrence of the string " -> ". The -f option found in many implementations was not included, as the realpath utility provides equivalent functionality with a choice of behaviors. FUTURE DIRECTIONSNone. SEE ALSOln, ls, pwd, realpath XBD Chapter 8, Section 12.2 XSH readlink() CHANGE HISTORYFirst released in Issue 8. NAMErealpath - resolve a pathname SYNOPSISrealpath [-E|-e] file DESCRIPTIONThe realpath utility shall canonicalize the pathname specified by the file operand as follows: If a call to the realpathrealpath If the -e option is specified, the canonicalization shall fail. If the -E option is specified, then if a call to the realpathrealpath shall expand all symbolic links that would be encountered in an attempt to resolve the specified pathname using the algorithm specified in [xref to XBD 4.13 Pathname Resolution], except that any trailing characters that are not also leading characters shall be ignored. If this expansion succeeds and the path prefix of the expanded pathname resolves to an existing directory, the canonicalized pathname shall be the expanded pathname. In all other cases, the canonicalization shall fail. If the expanded pathname is not empty, does not begin with a , and has exactly one
[1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1457 == Reported By:steffen Assigned To:ajosey == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1457 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Under Review Name: Steffen Nurpmeso Organization: User Reference: Section:Vol. 3: Shell and Utilities. Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2021-03-09 21:21 UTC Last Modified: 2022-07-21 11:15 UTC == Summary:Add readlink(1) utility == -- (0005900) kre (reporter) - 2022-07-21 11:15 https://austingroupbugs.net/view.php?id=1457#c5900 -- The NetBSD code (standard BSD licence, so available to everyone for anything, close enough) which implements https://austingroupbugs.net/view.php?id=1457#c5898 is available at http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/realpath/?only_with_tag=MAIN just follow the links for the source file, the man page, or the Makefile and then click the download link on the most recent revision of what that gives you (depending on your browser, some kind of modified click might be needed to save the file, otherwise it will just display in the browser). (https:// should work as well, if you prefer). This should be fairly easy to build on any BSD derived platform (may need some minor updates to deal with and the __RCSID() macro). This version originated at FreeBSD, but there's not a lot of that code remaining. Issue History Date ModifiedUsername FieldChange == 2021-03-09 21:21 steffenNew Issue 2021-03-09 21:21 steffenStatus New => Under Review 2021-03-09 21:21 steffenAssigned To => ajosey 2021-03-09 21:21 steffenName => Steffen Nurpmeso 2021-03-09 21:21 steffenSection => Vol. 3: Shell and Utilities. 2021-03-09 21:21 steffenPage Number => (page or range of pages) 2021-03-09 21:21 steffenLine Number => (Line or range of lines) 2021-03-10 04:11 emaste Issue Monitored: emaste 2022-02-22 15:58 geoffclare Note Added: 0005700 2022-02-22 16:01 geoffclare Note Edited: 0005700 2022-02-22 16:09 geoffclare Note Edited: 0005700 2022-02-22 16:11 geoffclare Project 1003.1(2008)/Issue 7 => 1003.1(2016/18)/Issue7+TC2 2022-02-22 16:13 geoffclare Note Edited: 0005700 2022-02-22 21:39 emaste Note Added: 0005701 2022-02-22 21:41 emaste Note Deleted: 0005701 2022-02-22 22:19 steffenNote Added: 0005702 2022-02-22 22:34 calestyo Issue Monitored: calestyo 2022-02-23 08:32 geoffclare Note Added: 0005703 2022-02-23 13:31 emaste Note Added: 0005704 2022-02-23 13:38 calestyo Note Added: 0005705 2022-02-24 09:28 geoffclare Note Added: 0005706 2022-02-24 09:32 geoffclare Note Edited: 0005700 2022-02-24 09:34 geoffclare Note Edited: 0005700 2022-02-24 09:36 geoffclare Note Edited: 0005703 2022-02-25 21:24 mirabilos Note Added: 0005721 2022-07-21 10:41 geoffclare Note Added: 0005898 2022-07-21 10:42 geoffclare Note Edited: 0005898 2022-07-21 10:45 geoffclare Note Added: 0005899 2022-07-21 10:47 geoffclare Note Edited: 0005899 2022-07-21 10:57 geoffclare Note Edited: 0005898
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
Date:Fri, 25 Mar 2022 09:22:55 + From:"Geoff Clare via austin-group-l at The Open Group" Message-ID: <20220325092255.GA26387@localhost> | [I have quoted kre's mail in full here, Thanks for that, that was the best way to compensate for my forgetfulness I believe. | They are different (without -e). Here is what strace shows for | the two cases: OK, that's behaving the way I thought it might (my first algorithm approximately) and your tests also show that they regard only ENOENT as "not existing" (answers the question that was in the comment). | It doesn't read any directories, it just uses lstat() for existence | checks. That, of course, is the easy way. Though that doesn't actually check for existence, but for (not sure of the appropriate word) the ability to manipulate the file. Not quite the same thing. | However, I don't see the need for the standard to be specific about | this, since there are many other places where it talks about existence | of files but doesn't specify how the existence check is done. Most of the other places it doesn't matter, here it does. The file in the d_nox case clearly does exist. But not only does the corelinks code not discover that, it also doesn't (without -e) treat the final component as not existing, and use that algorithm. That is, if you used their realpath on a no-x directory, naming a file that doesn't exist in the directory, their code would not treat that the same as the same file not existing in a directory with 'x' permission. I think we need better terminology than "doesn't exist" here, it might be better to actually refer to getting an ENOENT from the realpath() call on the file, rather than it not existing. That is what it appears is actually implemented. | So perhaps the first bullet should be modified something like this: At this point I will skip replying to this message, as you replaced all of this in your subsequent message, so I will go directly to that one. austin-group-l@opengroup.org (Actually Geoff Clare) said 5 hours later: | I obviously didn't pay enough attention to this result, as the wording | change I proposed doesn't cover it. Or, rather, with hindsight, not go to it (yet). I originally had a whole new way of writing the relevant text (roughly) included here, but before I send it I want to think more on exactly what is required, and how it can be specified. If I'm right, it should be all much simpler than it seems. I think to test this, I need to do an implementation of the coreutils without -e algorithm, and make sure that my results are consistent with its. If we're going to consider including this in NetBSD, I will need to do that anyway, so I may as well just do it. kre
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
Geoff Clare wrote, on 25 Mar 2022: > > > ln -s /tmp/gibberish/file d/link2 > > realpath d/link2 > > $ realpath d/link2; echo exit $? > realpath: d/link2: No such file or directory > exit 1 I obviously didn't pay enough attention to this result, as the wording change I proposed doesn't cover it. I can't see any reasonable way to describe it by reference to realpath(), so I think we'll need to find a different approach. Perhaps something along these lines: The realpath utility shall recursively expand all symbolic links in the pathname specified by the file operand, using the algorithm specified in [xref to Pathname Resolution], until one of the following conditions is met: * The last component of the expanded pathname is found to exist and is not a symbolic link. * The last component of the expanded pathname is found not to exist or its existence cannot be determined. * A component of the path prefix of the expanded pathname is found not to exist or its existence cannot be determined. In this case, realpath shall write a diagnostic message to standard error and exit with a non-zero exit status. and then have the realpath() "as if" stuff, but passing it the expanded pathname, or its prefix if -e isn't specified. Will that work? -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
[I have quoted kre's mail in full here, not just the parts I'm
replying to, because the original didn't go to the list.]
Robert Elz wrote, on 25 Mar 2022:
>
> | Do these results (from coreutils 8.30) cover what you need to know:
>
> Some of it, but you tested a directory with x permission, but
> without r (in addition to one with neither) where the more
> interesting case is one with r (so we can see what files exist)
> but without x (so they cannot be stat'd to determine if they
> are symlinks or not - assuming a filesys where the directory doesn't
> contain file type info).
$ mkdir -m a=rw d_nox
$ realpath ./d_nox/foo; echo exit $?
realpath: ./d_nox/foo: Permission denied
exit 1
$ realpath -e ./d_nox/foo; echo exit $?
realpath: ./d_nox/foo: Permission denied
exit 1
> There are also more cases of symlinks to consider
>
> test -d /tmp/realpath || mkdir /tmp/realpath
> cd /tmp/realpath
> mkdir d
> rm -rf foo
> ln -s /tmp/realpath/foo d/link
> realpath d/link
$ realpath d/link; echo exit $?
/tmp/realpath/foo
exit 0
$ realpath -e d/link; echo exit $?
realpath: d/link: No such file or directory
exit 1
> is one, and then
>
> ln -s /tmp/gibberish/file d/link2
> realpath d/link2
$ realpath d/link2; echo exit $?
realpath: d/link2: No such file or directory
exit 1
$ realpath -e d/link2; echo exit $?
realpath: d/link2: No such file or directory
exit 1
> is another. Those are both cases where the final component
> (link and link2) names a file that doesn't exist (in a sense,
> the case "realpath d/nofile" is the simple one, handling that
> case is easy), but in a different way, are they treated the same
> or differently? And what happens in any case? I can do no more
> that guess.
They are different (without -e). Here is what strace shows for
the two cases:
lstat64("/tmp/realpath/d", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
lstat64("/tmp/realpath/d/link", {st_mode=S_IFLNK|0777, st_size=17, ...}) = 0
readlink("/tmp/realpath/d/link", "/tmp/realpath/foo", 18) = 17
lstat64("/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat64("/tmp/realpath", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
lstat64("/tmp/realpath/foo", 0xbfbe9a3c) = -1 ENOENT
lstat64("/tmp/realpath/d", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
lstat64("/tmp/realpath/d/link2", {st_mode=S_IFLNK|0777, st_size=19, ...}) = 0
readlink("/tmp/realpath/d/link2", "/tmp/gibberish/file", 20) = 19
lstat64("/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
lstat64("/tmp/gibberish", 0xbfe9cf8c) = -1 ENOENT
> The examples with -e are less interesting, those should be
> how our realpath acts now, but I will verify later, I will only
> comment more on that if there are differences.
>
> | My bugnote 5700 has what I came up with for readlink -f (without -n),
> | which I think could be reused for realpath without -e.
>
> Yes, the 2nd bullet point looks about right, but that makes it more
> important to verify what the coreutils version does with a directory
> that has read premission, but no x permission, as:
>
> If the file operand names a file that is not a symbolic link,
> or if the path prefix of file resolves, with symbolic links followed,
> to an existing directory
>
> that much is just realpath(3) on the path prefix (and probably a
> test that the result is a directory), and that's fine
>
> and the final component of file does not exist as a directory
> entry in that directory,
>
> and that can be determined by reading the directory, and comparing
> entries with the final component of "file" to see if that is an entry
> in the directory or not - which requires r permission, but doesn't
> need x, or by calling lstat() on the results from realpath, with the
> final component appended, which requires x but doesn't require r.
>
> Which one are we supposed to do to determine this question? Which
> dces the coreutils version do? The text (probably for both readlink -f
> and realpath) needs to be very clear about this.
Here's the strace for the d_nox case:
lstat64("/tmp/realpath/d_nox", {st_mode=S_IFDIR|0666, st_size=4096, ...}) = 0
lstat64("/tmp/realpath/d_nox/foo", 0xbf97522c) = -1 EACCES
It doesn't read any directories, it just uses lstat() for existence
checks.
However, I don't see the need for the standard to be specific about
this, since there are many other places where it talks about existence
of files but doesn't specify how the existence check is done. If an
implementation wants to go the extra mile and try to read the directory
after an EACCES from lstat(), it can. It's a quality-of-implementation
issue.
> | It doesn't state anything explicit about the directory permissions,
> | but I think that's fine because it's normal for utility descriptions
> | to leave such things to be covered by the general rules on utility errors.
>
> As it is written in that note it is fine, if the necessary
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
I replied to Geoff's most recent message, but because of the Reply-To this list insists in inserting, my mailer's policy of believing that Reply-To means what it says, and by default, complying with that request and that, in this case, I forgot to override it, the message wasn't sent to the list. I no longer have a copy, I don't keep e-mail I send in the ordinary course of events (when it is to a list, the list generally sends it back anyway). I have advised Geoff that he can forward the message I sent him to the list if he desires. In any case, it is fine to reply to that message on the list, and quote any parts appropriate. That is, the message was not intended to be private (but was too long to recreate). kre
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
Robert Elz wrote, on 24 Mar 2022: > > | Has there been any progress on the possibility of NetBSD changing > | realpath to behave like coreutils wrt -e? > > Not yet. I cannot work out exactly what I am supposed to > implement, the coreutils doc is hopeless. Until I know > what that is, I cannot propose it to NetBSD developers. > > I am not sure whether "last component not existing" refers to > the final component of the given path not appearing in the > directory to which the earlier path resolves, of if it means > where that component refers toa symlink which does not > name an existing file, or both, or something else. > > Further if it is impossible to determine whether the final > component exists or not, or what it is if it can be determined > to exits (no r or x permission, or just no x) is that supposed to > be ignored as well? Do these results (from coreutils 8.30) cover what you need to know: $ cd /tmp $ mkdir realpath $ cd realpath $ touch file $ ln -s file filelink $ ln -s nofile nofilelink $ mkdir -m a=wx d_nor $ mkdir -m a=w d_norx $ realpath ./filelink; echo exit $? /tmp/realpath/file exit 0 $ realpath -e ./filelink; echo exit $? /tmp/realpath/file exit 0 $ realpath ./nofilelink; echo exit $? /tmp/realpath/nofile exit 0 $ realpath -e ./nofilelink; echo exit $? realpath: ./nofilelink: No such file or directory exit 1 $ realpath ./d_nor/foo; echo exit $? /tmp/realpath/d_nor/foo exit 0 $ realpath -e ./d_nor/foo; echo exit $? realpath: ./d_nor/foo: No such file or directory exit 1 $ realpath ./d_norx/foo; echo exit $? realpath: ./d_norx/foo: Permission denied exit 1 $ realpath -e ./d_norx/foo; echo exit $? realpath: ./d_norx/foo: Permission denied exit 1 > If you were to write a standards worthy description of exactly > what is to be required (which will eventually be required > regardless of whether a -E option is needed to enable it on > BSD systems) that would help. My bugnote 5700 has what I came up with for readlink -f (without -n), which I think could be reused for realpath without -e. It doesn't state anything explicit about the directory permissions, but I think that's fine because it's normal for utility descriptions to leave such things to be covered by the general rules on utility errors. I think the behaviour with -e would simply be described as: The realpath utility shall write to standard output the absolute pathname that would be returned by a call to the realpath() function with the file operand as its first argument, followed by a character. If the realpath() function would return a null pointer, realpath shall write a diagnostic message to standard error and exit with non-zero status. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
Date:Thu, 24 Mar 2022 09:54:20 + From:"Geoff Clare via austin-group-l at The Open Group" Message-ID: <20220324095420.GA29265@localhost> | Has there been any progress on the possibility of NetBSD changing | realpath to behave like coreutils wrt -e? Not yet. I cannot work out exactly what I am supposed to implement, the coreutils doc is hopeless. Until I know what that is, I cannot propose it to NetBSD developers. I am not sure whether "last component not existing" refers to the final component of the given path not appearing in the directory to which the earlier path resolves, of if it means where that component refers toa symlink which does not name an existing file, or both, or something else. Further if it is impossible to determine whether the final component exists or not, or what it is if it can be determined to exits (no r or x permission, or just no x) is that supposed to be ignored as well? If you were to write a standards worthy description of exactly what is to be required (which will eventually be required regardless of whether a -E option is needed to enable it on BSD systems) that would help. kre
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
Robert Elz wrote, on 26 Feb 2022: > > | The point is it's a difference in behaviour between the two > | implementations. > > Yes, understood. My question (not to you, but to the universe) was > whether that difference needs to exist? That is, perhaps I can change > the NetBSD impl to at least behave wrt -e (and the fictional -E) the > same as the coreutils version. That seems like it would be a better > outcome, if it was possible, right? > > Right now I have no idea whether it is possible however (the code > is obviously possible, it is the compat issues/politics that are > questionable). > > | Rather than just making it unspecified whether > | the last component has to exist, it seemed to me that it would > | be more useful to have -e and -E options so that users have a > | way to ensure they get the same behaviour on both. > > Yes, if it turns out not to be possible to alter the default behaviour > of the default for our version, that would certainly be a reasonable > approach. Has there been any progress on the possibility of NetBSD changing realpath to behave like coreutils wrt -e? -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
[reply restricted to list] At 2022-02-28T13:34:09+, Jonathan Wakely via austin-group-l at The Open Group wrote: > On Mon, 28 Feb 2022 at 13:03, Robert Elz wrote: > > > > Date:Mon, 28 Feb 2022 10:28:20 + > > From:Jonathan Wakely > > Message-ID: > > > > > > | Nothing in any GNU licence prevents reading code. > > > > Not explicitly, no. But if I read some code, and then write > > something similar, how would I ever prove I had not copied? > > If I did, even subconsciiusky, and distributed my code, it > > would be required to be GNU licensed wouldn't it? That is > > something I will never do. I give away code I write unrestricted > > (free). Not encunbered ir restricted. > > How is that different from any code that isn't in the public domain? > It's copyrighted either way, and you are bound by the terms of the > licence. Indeed. I worked for several years in FLOSS compliance at a Big Company(tm) with hundreds of distinct products, and the third-party software copyright disclosure PDFs for projects that attempted to minimize the footprint of copyright could run to dozens or even over a hundred pages, driven mostly by BSD- and Apache-style licenses. (Those "NOTICE" files add up if you pay attention to them.) Evidence of this phenomenon is not hard to come by--talk to anybody familiar with the field, or check out the fine print of the documentation for your smart TV or Android phone. (Frequently, it is offered with little or no explanation for its presence.) > > Hence, and especially here as the starting point was that I > > might add code to the BSD realpath utility to make it more > > like the coreutils version, and hence make it easier to > > standardise, I simply cannot look at the GNU code or I would > > not be able to distribute a modified BSD version under the > > BSD licence. > > This is simply wrong. You can look at it. If you're unable to > reimplement it without making it a derived work, then either you > really *are* copying it, or it's not really copyrightable in the first > place (e.g. it simply does something so trivial that there's only one > way to do it, and nobody is going to be able to argue that you > "copied" the original just because you did the same thing). Yes. Copyright is grounded on the presence of original expression and the practice of authorship (as opposed to scribal activities like transcription)[1]. Where there is no room for that, it is difficult for copyright to here. I do not say "impossible" because a sufficiently wealthy and fortunate party can always achieve cockeyed results, whether in the courts or through intellectual property treaties. > What in the GPL means your eyeballs are tainted, This query cuts to the chase. What we're dealing with here is, I submit, not really a matter of legal restriction but a puritanical stance that is scandalized by copyleft, and locates virtue in tactically restricting access to source code. Whether this is done in conscious emulation of AT Unix source license management practices starting in the mid-1970s, or because such restriction is considered inherently virtuous seems to depend on the person. The clubhouse/"core team" approach to source project management reproduces this dynamic with respect to write privileges, and played out in exemplary ways with the NetBSD/OpenBSD split and the XFree86's self-exile into irrelevance. > or what in the BSD licence says you don't need to conform to the > licence if you copy code? The entire USL v. BSDI settlement turned on this very point[2]. 4.4BSD was able to rise like a phoenix from the ashes of the pyre USL had built for it because USL and/or its predecessors-in-interest took a lax attitude to the terms of the UC Regents' copyright notice, and duplicated code without copying the requisite notices. Perhaps the fact that this information came to the awareness of the general public only concomitantly with the SCO vs. IBM lawsuit over the Linux kernel (itself surely a point of amusement to some Linux/GPL detractors) explains why so many BSD partisans today remain ignorant of it. > Please stop calling it "stupid" based on an apparent misunderstanding > of how copyright and licensing works. This discussion doesn't belong > here, but wouldn't be necessary if you'd avoid the inflammatory > language. In other areas, this stance is familiar as the "politics of resentment"[3]. It would be unfortunate if the (further) standardization of readlink/realpath commands by POSIX were frustrated, but especially so if said failure were falsely attributed to the application of copyleft licensing to a particular implementation. (I remember when true(1) and false(1) were shell scripts that proclaimed themselves to be trade secrets--"unpublished proprietary source code of AT"--in full caps.) To avoid that outcome, I volunteer to prepare a human-readable English[1] description of the behavior of the GNU coreutils readlink and realpath commands'
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
On Mon, 28 Feb 2022 at 13:34, Jonathan Wakely wrote: > > On Mon, 28 Feb 2022 at 13:03, Robert Elz wrote: > > > > Date:Mon, 28 Feb 2022 10:28:20 + > > From:Jonathan Wakely > > Message-ID: > > > > > > | Nothing in any GNU licence prevents reading code. > > > > Not explicitly, no. But if I read some code, and then write > > something similar, how would I ever prove I had not copied? > > If I did, even subconsciiusky, and distributed my code, it > > would be required to be GNU licensed wouldn't it? That is > > something I will never do. I give away code I write unrestricted > > (free). Not encunbered ir restricted. > > How is that different from any code that isn't in the public domain? > It's copyrighted either way, and you are bound by the terms of the > licence. > > > > > > Hence, and especially here as the starting point was that I > > might add code to the BSD realpath utility to make it more > > like the coreutils version, and hence make it easier to > > standardise, I simply cannot look at the GNU code or I would > > not be able to distribute a modified BSD version under the > > BSD licence. > > This is simply wrong. You can look at it. If you're unable to > reimplement it without making it a derived work, then either you > really *are* copying it, or it's not really copyrightable in the first > place (e.g. it simply does something so trivial that there's only one > way to do it, and nobody is going to be able to argue that you > "copied" the original just because you did the same thing). > > > It is the stupid GPL which leads to this, if it was a free use > > licence we could just distribute each other's code, or binaries, > > rather than all this duplication, and we'd all be much better off. > > I don't see how BSD licences differ. You are required to retain the > copyright holder's name and the licence text if you redisitribute > source code. If you look at some BSD code, then implement something > similar without copying the GPL code, but you don't put the original Doh, s/GPL code/BSD code/ here. > copyright holder's name on it, how do you prove you didn't copy it? > How is this different from doing the same thing with GPL code? What in > the GPL means your eyeballs are tainted, or what in the BSD licence > says you don't need to conform to the licence if you copy code? > > Please stop calling it "stupid" based on an apparent misunderstanding > of how copyright and licensing works. This discussion doesn't belong > here, but wouldn't be necessary if you'd avoid the inflammatory > language.
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
On Mon, 28 Feb 2022 at 13:03, Robert Elz wrote: > > Date:Mon, 28 Feb 2022 10:28:20 + > From:Jonathan Wakely > Message-ID: > > > | Nothing in any GNU licence prevents reading code. > > Not explicitly, no. But if I read some code, and then write > something similar, how would I ever prove I had not copied? > If I did, even subconsciiusky, and distributed my code, it > would be required to be GNU licensed wouldn't it? That is > something I will never do. I give away code I write unrestricted > (free). Not encunbered ir restricted. How is that different from any code that isn't in the public domain? It's copyrighted either way, and you are bound by the terms of the licence. > > Hence, and especially here as the starting point was that I > might add code to the BSD realpath utility to make it more > like the coreutils version, and hence make it easier to > standardise, I simply cannot look at the GNU code or I would > not be able to distribute a modified BSD version under the > BSD licence. This is simply wrong. You can look at it. If you're unable to reimplement it without making it a derived work, then either you really *are* copying it, or it's not really copyrightable in the first place (e.g. it simply does something so trivial that there's only one way to do it, and nobody is going to be able to argue that you "copied" the original just because you did the same thing). > It is the stupid GPL which leads to this, if it was a free use > licence we could just distribute each other's code, or binaries, > rather than all this duplication, and we'd all be much better off. I don't see how BSD licences differ. You are required to retain the copyright holder's name and the licence text if you redisitribute source code. If you look at some BSD code, then implement something similar without copying the GPL code, but you don't put the original copyright holder's name on it, how do you prove you didn't copy it? How is this different from doing the same thing with GPL code? What in the GPL means your eyeballs are tainted, or what in the BSD licence says you don't need to conform to the licence if you copy code? Please stop calling it "stupid" based on an apparent misunderstanding of how copyright and licensing works. This discussion doesn't belong here, but wouldn't be necessary if you'd avoid the inflammatory language.
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
Date:Mon, 28 Feb 2022 10:28:20 + From:Jonathan Wakely Message-ID: | Nothing in any GNU licence prevents reading code. Not explicitly, no. But if I read some code, and then write something similar, how would I ever prove I had not copied? If I did, even subconsciiusky, and distributed my code, it would be required to be GNU licensed wouldn't it? That is something I will never do. I give away code I write unrestricted (free). Not encunbered ir restricted. Hence, and especially here as the starting point was that I might add code to the BSD realpath utility to make it more like the coreutils version, and hence make it easier to standardise, I simply cannot look at the GNU code or I would not be able to distribute a modified BSD version under the BSD licence. It is the stupid GPL which leads to this, if it was a free use licence we could just distribute each other's code, or binaries, rather than all this duplication, and we'd all be much better off. kre
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
On Fri, 25 Feb 2022 at 14:56, Robert Elz via austin-group-l at The Open Group wrote: > > OK. I have looked at the coreutils realpath man page (gnu licensing > stupidity means I cannot look at their code), Nothing in any GNU licence prevents reading code.
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
Date:Sat, 26 Feb 2022 03:07:15 + (UTC)
From:Thorsten Glaser
Message-ID:
| No, because the trailing /name *may* exist (and be a symlink).
Yes, I had forgotten that case, but that's just a simple modification of
the sample code I provided...
if test -e "${var}" || test -h "${var}"; then
newpath=$(realpath "${var}")
(etc).
That is, unless the point of "not existing" is that (with -e) there
is intended to be an error if final component of the path is a symlink
that doesn't resolve to an existing file, as distinct from the final
component not existing at all.None of the existing documentation
seems very clear to me, doing a compatible implementation, without
copying source, seems likely to be difficult.
| >But I currently don't understand the point of canonicalising a
| >path that doesn't exist (why not create it first, then get the
| >canonical form?
|
| Output filenames.
|
| outf=$(realpath "$1")
| dosomething >"$outf"
And
dosomething >"$1"
won't work (in this precise scenario) for some reason? What's that?
| >If it isn't to be created, and doesn't exist,
| >then why does anyone care what its canonical name might be?)
|
| set -- ./filename
| outf=$(realpath "$1")
| cd "$(realpath "$0/..")"# or mktemp -d or something…
| dosomething >"$outf"
OK, dealing with pathnames relative to someplace other than where
you're going to be, that makes sense, but
case "$1" in
'') # whatever you want to do in that case ;;
/*) outf=$1;;
*) outf=$PWD/$1;;
esac
generally works for me, and doesn't rely upon what is currently a
non-standard utility. [Aside: I know the comment in the above is bad syntax]
For the cd, just
cd $0/..
(which seems unlikely to be what you'd want, since $0 isn't usually a
directory - that is unless you believe in "logical" paths, and have the
"/.." suffix simply perform string manipulation, which is something I
detest. If I want string manipulation, I use sed, that's what it is for.
coreutils has -L (or -s) that would make this work, without it, it should fail
I believe, though once again, the documentation isn't all that clear.
Since realpath(1) is not in POSIX (yet) we cannot consult that, but we
do have realpath(3) there, and of that one of the possible errors is:
[ENOTDIR] A component of the path prefix names an existing file that is
neither a directory nor a symbolic link to a directory, or the
file_name argument contains at least one non- character
and ends with one or more trailing characters and the
last pathname component names an existing file that is neither
a directory nor a symbolic link to a directory.
For present purposes we can ignore everything after the 2nd line there
(that alternate reason for ENOTDIR doesn't apply here) but assuming that
$0 might often be "/bin/sh" then $0/.. is "/bin/sh/.." in which "A component
of the path prefix" (ie: /bin/sh in this case) "names an existing file" (one
hopes that /bin/sh is an existing file) "that is neither a directory nor
a symbolic link to a directory" (and one assumes that /bin/sh isn't any
kind of directory). Hence you should simply get ENOTDIR from $0/..
A relevant question here, is given that we have
mkdir /tmp/foo
ln -s /tmp/foo sym
>/tmp/bar
>bar
then does
realpath sym/../bar
return ./bar (or $PWD/bar more likely), or does it return /tmp/bar ?
I believe /tmp/bar is correct (and that is indeed what mksh seems to
generate.)
But on netbsd ..
netbsd# realpath /bin/sh/..
realpath: /bin/sh/..: Not a directory
whereas for mksh
mksh $ realpath /bin/sh/..
/bin
which seems incorrect to me. But as realpath(1) isn't yet
standardised, who knows - but it is hard to see that happening in
a way that makes it incompatible with realpath(3).
| >That is, the plan would be to perhaps add the -e option
| (and maybe -q, and perhaps a newly invented -E),
|
| Why?
Because -q is the one common option currently, and -e to coreutils
realpath gives when BSD realpath currently does. The -E proposal
is to allow BSD realpath to act like the coreutils version, without
sacrificing backwards compat with what exists (but that might not be
needed, I am not sure if we care that much about this ... just do not
know yet.)
| Instead of -e, you can just do a subsequent test -e on the file.
Perhaps, but with -e the internal implementation is much simpler,
seems odd to do all the work of dealing with coping with a non-existant
file when the code that follows is just going to fail in that case
anyway. Simpler for everyone to just let realpath(1) fail.
| Instead of -q, you can 2>/dev/null.
No, that suppresses everything to stderr, including usage messages, etc.
The -q option just suppresses sys call errors (like files not existing).
| >and almost certainly to allow
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
Robert Elz via austin-group-l at The Open Group dixit:
>The non existing path version can just be done as:
>
> var=/whatever/path/name # obtained however this path is calculated
> newpath=$(realpath ${var%/*})/${var##*/}
No, because the trailing /name *may* exist (and be a symlink).
>But I currently don't understand the point of canonicalising a
>path that doesn't exist (why not create it first, then get the
>canonical form?
Output filenames.
outf=$(realpath "$1")
dosomething >"$outf"
> If it isn't to be created, and doesn't exist,
>then why does anyone care what its canonical name might be?)
set -- ./filename
outf=$(realpath "$1")
cd "$(realpath "$0/..")"# or mktemp -d or something…
dosomething >"$outf"
This is something I do all the time.
>You do need (as do we all) to accept that sometimes complying with a new
>version of the standard is going to require implementation changes, right?
Yes. But I have hope that, if I argue my case sufficiently, the
new version of the standard will be made with my case in mind ;)
>That is, the plan would be
>to perhaps add the -e option (and maybe -q, and perhaps a newly invented -E),
Why?
Instead of -e, you can just do a subsequent test -e on the file.
Instead of -q, you can 2>/dev/null.
>and almost certainly to allow multiple file args
No, absolutely NOT that. That’s going to reopen the debate about
output separators (and only safe if NUL). And none of the existing
implementations has -0/-z/-Z.
I *did* think about this when adding realpath to mksh, and I decided
for handling exactly one argument precisely to avoid this hellhole.
bye,
//mirabilos
--
> Wish I had pine to hand :-( I'll give lynx a try, thanks.
Michael Schmitz on nntp://news.gmane.org/gmane.linux.debian.ports.68k
a.k.a. {news.gmane.org/nntp}#news.gmane.linux.debian.ports.68k in pine
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
Dixi quod… >But useless as most Android scripts would get mksh’s realpath >if called without any options… > >(some custom Android ROMs add busybox or GNU bash, but that’s You can also symlink or hardlink realpath to mksh and get its builtin. That would make which you get consistent ☺ Goodnight, //mirabilos -- Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
Date:Fri, 25 Feb 2022 21:24:37 +
From:=22Austin Group Bug Tracker via austin-group-l at The Op=
en Group=22
Message-ID: =
This is from https://austingroupbugs.net/view.php?id=1457#c5721
(bugnote 5721 to issue 1457)
| The realpath in mksh is specified to allow referring to nonexistant files
| in existing directories, which I understand is very much not a POSIX thing.
That is what coreutils version does by default, and which is what is
perhaps to be added. coreutils has a -e option though which requires
the file also exist, that would likely be added as well.
| Without that, though, I'd consider it good as useless
Why? What's the usage that expects to work with non-existing files?
The BSD version currently only permits the existing file variant.
The non existing path version can just be done as:
var=/whatever/path/name # obtained however this path is calculated
newpath=$(realpath ${var%/*})/${var##*/}
can't it, as the trailing (non-existing) "name" can't be a symlink, so
won't be altered -- this would be in an existence test like:
if test -e "${var}" ; then
newpath=$(realpath "${var}")
else
newpath=$(realpath "${var%/*}")/"${var##*/}"
fi
if test $? -ne 0
then
# whatever is to be done if realpath errors
fi
But I currently don't understand the point of canonicalising a
path that doesn't exist (why not create it first, then get the
canonical form? If it isn't to be created, and doesn't exist,
then why does anyone care what its canonical name might be?)
| readlink is important. I'd argue for standardised readlink without
| and with -f but not adding realpath (unless the latter can be done in a way
| that doesn't blow up (remember the story of cat(1) that went out and came
| back waving flags) mksh or, worse, make its implementation incompatible).
You do need (as do we all) to accept that sometimes complying with a new
version of the standard is going to require implementation changes, right?
Here (unlike perhaps the [^xxx] stuff) the changes would simply be to add
things that are currently errors (or if you punt to an external implementation,
when these happen, to just keep doing that).That is, the plan would be
to perhaps add the -e option (and maybe -q, and perhaps a newly invented -E),
and almost certainly to allow multiple file args - that should be possible
to handle, one of those ways. Note that if -E is added, *all* implementations
will require changes, though for some the change would just be to allow that
option, and ignore it.
kre
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
On Fri, Feb 25, 2022 at 1:30 PM Thorsten Glaser wrote: > enh via austin-group-l at The Open Group dixit: > > >> OK, I did. Note that we're talking of options for realpath(1), not > >> readlink(1). It looks as if the toybox version (from what I can gather > >> from what I guess from that very stylised code) has no options to > realpath > >> at all - and that it is simply a clone of readlink -f, just as Steffen > >> indicated the busybox version is. > > > >correct. > > But useless as most Android scripts would get mksh’s realpath > if called without any options… > didn't i disable that, to avoid such confusion? yeah: https://cs.android.com/android/platform/superproject/+/master:external/mksh/src/funcs.c;l=130?q=realpath%20file:mksh (you're right in principle, though: this will be true for sufficiently old versions of Android.) > (some custom Android ROMs add busybox or GNU bash, but that’s > thankfully become rare) > > bye, > //mirabilos > -- > 22:20⎜ The crazy that persists in his craziness becomes a master > 22:21⎜ And the distance between the craziness and geniality is > only measured by the success 18:35⎜ "Psychotics are consistently > inconsistent. The essence of sanity is to be inconsistently inconsistent >
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
Date:Fri, 25 Feb 2022 12:31:32 -0800 From:enh Message-ID: | my assumption was "readlink(1) has a bunch of options, getting that into | POSIX would be a nightmare Except that that is exactly what is happening, and where all of this started. Quite likely not all of the options that the various implementations of readlink(1) supports will be included - the one of note here is -f, of which the coreutils doc apparently says that realpath(1) is a better utility to use. Which led to whether realpath should be included in POSIX in addition to readlink - but probably in that case without the -f option to readlink being included (that would just be an implementation extension). Since all readlink implementations (that I know of anyway) seem to have the -f option, and it seems to work the same way in all, I think omitting it from POSIX would be a mistake, but what I think here doesn't really matter all that much, and has no bearing on whether or not realpath should also be added. | fwiw, current macOS does have readlink (with just -n), but still no | realpath. It seems in that case that macOS would need to add either readlink -f or realpath (or perhaps both) to comply with the planned forthcoming posix. [On multiple file args] | i don't think that's true of busybox? No idea, I know nothing of busybox beyond what I read here. kre
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
enh via austin-group-l at The Open Group dixit: >> OK, I did. Note that we're talking of options for realpath(1), not >> readlink(1). It looks as if the toybox version (from what I can gather >> from what I guess from that very stylised code) has no options to realpath >> at all - and that it is simply a clone of readlink -f, just as Steffen >> indicated the busybox version is. > >correct. But useless as most Android scripts would get mksh’s realpath if called without any options… (some custom Android ROMs add busybox or GNU bash, but that’s thankfully become rare) bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
[1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1457 == Reported By:steffen Assigned To:ajosey == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1457 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Under Review Name: Steffen Nurpmeso Organization: User Reference: Section:Vol. 3: Shell and Utilities. Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2021-03-09 21:21 UTC Last Modified: 2022-02-25 21:24 UTC == Summary:Add readlink(1) utility == -- (0005721) mirabilos (reporter) - 2022-02-25 21:24 https://austingroupbugs.net/view.php?id=1457#c5721 -- mksh has a realpath builtin, please don’t add an incompatible requirement if you do ;-) It takes an optional first argument "--" (skipped) and a mandatory second argument (file); no options, and any other arguments cause an error message as well. I’ve recently learnt about some differences between BSD and POSIX realpath on the C level (from reading the OpenSSH mailing list). The realpath in mksh is specified to allow referring to nōnexistant files in existing directories, which I understand is very much not a POSIX thing. Without that, though, I’d consider it good as useless (one can always add a test -e afterwards). https://github.com/MirBSD/mksh/blob/5d135a8ee38d84c5a4f6c175b9a831d5acbc641b/misc.c#L1886 in case of interest. I understand other OSes have diverging realpath utilities. mksh has a mode where a utility can call the builtin or an external one depending on the existence of the latter and, optionally, presence of flags. The latter is implemented for realpath, so “realpath -h” calls coreutils’ realpath on my GNU system, but not on the BSD system without an external realpath utility. This is a compromise. “readlink” is important. I’d argue for standardised readlink without and with -f but not adding realpath (unless the latter can be done in a way that doesn’t blow up (remember the story of cat(1) that went out and came back waving flags) mksh or, worse, make its implementation incompatible). Issue History Date ModifiedUsername FieldChange == 2021-03-09 21:21 steffenNew Issue 2021-03-09 21:21 steffenStatus New => Under Review 2021-03-09 21:21 steffenAssigned To => ajosey 2021-03-09 21:21 steffenName => Steffen Nurpmeso 2021-03-09 21:21 steffenSection => Vol. 3: Shell and Utilities. 2021-03-09 21:21 steffenPage Number => (page or range of pages) 2021-03-09 21:21 steffenLine Number => (Line or range of lines) 2021-03-10 04:11 emaste Issue Monitored: emaste 2022-02-22 15:58 geoffclare Note Added: 0005700 2022-02-22 16:01 geoffclare Note Edited: 0005700 2022-02-22 16:09 geoffclare Note Edited: 0005700 2022-02-22 16:11 geoffclare Project 1003.1(2008)/Issue 7 => 1003.1(2016/18)/Issue7+TC2 2022-02-22 16:13 geoffclare Note Edited: 0005700 2022-02-22 21:39 emaste Note Added: 0005701 2022-02-22 21:41 emaste Note Deleted: 0005701 2022-02-22 22:19 steffenNote Added: 0005702 2022-02-22 22:34 calestyo Issue Monitored: calestyo 2022-02-23 08:32 geoffclare Note Added: 0005703 2022-02-23 13:31 emaste Note Added: 0005704 2022-02-23 13:38 calestyo Note Added: 0005705 2022-02-24 09:28 geoffclare Note Added: 0005706 2022-02-24 09:32 geoffclare Note Edited: 0005700
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
On Fri, Feb 25, 2022 at 12:20 PM Robert Elz via austin-group-l at The Open Group wrote: > Date:Fri, 25 Feb 2022 15:25:53 + > From:"Geoff Clare via austin-group-l at The Open Group" < > austin-group-l@opengroup.org> > Message-ID: <20220225152553.GA4559@localhost> > > | The point is it's a difference in behaviour between the two > | implementations. > > Yes, understood. My question (not to you, but to the universe) was > whether that difference needs to exist? That is, perhaps I can change > the NetBSD impl to at least behave wrt -e (and the fictional -E) the > same as the coreutils version. That seems like it would be a better > outcome, if it was possible, right? > > Right now I have no idea whether it is possible however (the code > is obviously possible, it is the compat issues/politics that are > questionable). > > | Rather than just making it unspecified whether > | the last component has to exist, it seemed to me that it would > | be more useful to have -e and -E options so that users have a > | way to ensure they get the same behaviour on both. > > Yes, if it turns out not to be possible to alter the default behaviour > of the default for our version, that would certainly be a reasonable > approach. > > | So my preferences are (in descending order): > > I'd insert: > > 0. Make the BSD version compatible with coreutils (at least for >the one issue that seems to matter - though I'm not sure what >its practical uses are). > > | 1. POSIX adds realpath with -e and -E, > > [...] > > | I wasn't proposing any other options be included for realpath > | (except perhaps -q, depending on whether it behaves the same in > | both implementations). > > Understood, I was just ruminating on the others on the assumption that > if I can attempt to make ours compatible, just how compat should I aim. > It won't be all the way, but perhaps more than just the -e issue. > > The -q seems to be (close enough to, given the other differences) the > same between the two (at least according to the coreutils man page). > It just makes some stderr output vanish (which incidentally might make > realpath do exit(1) without anything on stderr). > > e...@google.com said: > | in terms of "what's actually used in the wild", Android uses toybox > (0BSD > | licensed, so anyone can look :-) ) > > OK, I did. Note that we're talking of options for realpath(1), not > readlink(1). It looks as if the toybox version (from what I can gather > from what I guess from that very stylised code) has no options to realpath > at all - and that it is simply a clone of readlink -f, just as Steffen > indicated the busybox version is. > correct. > There would be no point including realpath(1) in posix if it is simply > readlink -f with no options possible at all - there has to be some > difference > in how it works to be worth including, I would have thought. > except readlink isn't in posix either :-) *that's* the portability issue i've seen in practice. in places where we do/did support macOS as well as linux, we'd end up with a python one-liner or whatever to make up for this. my assumption was "readlink(1) has a bunch of options, getting that into POSIX would be a nightmare ... but everyone seems to have got on just fine with a trivial realpath(1) that has no options [apart from the fact that it's also not in POSIX]". fwiw, current macOS does have readlink (with just -n), but still no realpath. > e...@google.com also said: > | one thing i haven't seen mentioned so far (but which i added to toybox > | myself, so i know it's definitely in use) is that existing realpath > | implementations support *multiple* file arguments on the command line, > not > | just one. > > Sure, as best I can tell, all implementations of both readlink and realpath > allow multiple file (path) args. > i don't think that's true of busybox? > kre > >
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
Date:Fri, 25 Feb 2022 15:25:53 + From:"Geoff Clare via austin-group-l at The Open Group" Message-ID: <20220225152553.GA4559@localhost> | The point is it's a difference in behaviour between the two | implementations. Yes, understood. My question (not to you, but to the universe) was whether that difference needs to exist? That is, perhaps I can change the NetBSD impl to at least behave wrt -e (and the fictional -E) the same as the coreutils version. That seems like it would be a better outcome, if it was possible, right? Right now I have no idea whether it is possible however (the code is obviously possible, it is the compat issues/politics that are questionable). | Rather than just making it unspecified whether | the last component has to exist, it seemed to me that it would | be more useful to have -e and -E options so that users have a | way to ensure they get the same behaviour on both. Yes, if it turns out not to be possible to alter the default behaviour of the default for our version, that would certainly be a reasonable approach. | So my preferences are (in descending order): I'd insert: 0. Make the BSD version compatible with coreutils (at least for the one issue that seems to matter - though I'm not sure what its practical uses are). | 1. POSIX adds realpath with -e and -E, [...] | I wasn't proposing any other options be included for realpath | (except perhaps -q, depending on whether it behaves the same in | both implementations). Understood, I was just ruminating on the others on the assumption that if I can attempt to make ours compatible, just how compat should I aim. It won't be all the way, but perhaps more than just the -e issue. The -q seems to be (close enough to, given the other differences) the same between the two (at least according to the coreutils man page). It just makes some stderr output vanish (which incidentally might make realpath do exit(1) without anything on stderr). e...@google.com said: | in terms of "what's actually used in the wild", Android uses toybox (0BSD | licensed, so anyone can look :-) ) OK, I did. Note that we're talking of options for realpath(1), not readlink(1). It looks as if the toybox version (from what I can gather from what I guess from that very stylised code) has no options to realpath at all - and that it is simply a clone of readlink -f, just as Steffen indicated the busybox version is. There would be no point including realpath(1) in posix if it is simply readlink -f with no options possible at all - there has to be some difference in how it works to be worth including, I would have thought. e...@google.com also said: | one thing i haven't seen mentioned so far (but which i added to toybox | myself, so i know it's definitely in use) is that existing realpath | implementations support *multiple* file arguments on the command line, not | just one. Sure, as best I can tell, all implementations of both readlink and realpath allow multiple file (path) args. kre
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
enh wrote in : |in terms of "what's actually used in the wild", Android uses toybox (0BSD |licensed, so anyone can look :-) ) for both on-device *and* for the OS |build itself on the host. | |toybox readlink ( |https://github.com/landley/toybox/blob/master/toys/other/readlink.c) |currently supports: | |usage: readlink FILE... | |With no options, show what symlink points to, return error if not |symlink. | |Options for producing canonical paths (all symlinks/./.. resolved): |-e Canonical path to existing entry (fail if missing) |-f Full path (fail if directory missing) |-m Ignore missing entries, show where it would be |-n No trailing newline |-q Quiet (no output, just error code) | |since toybox tends to add things _as they're needed_, rather than "because |coreutils has them", that's probably "solid anecdata" about what gets used |in the wild. | |one thing i haven't seen mentioned so far (but which i added to toybox |myself, so i know it's definitely in use) is that existing realpath |implementations support *multiple* file arguments on the command line, not |just one. To extend this with the widely used busybox: #?127|kent:toolbox.git$ busybox.static readlink --help BusyBox v1.34.0 (2022-01-03 21:34:20 CET) multi-call binary. Usage: readlink [-fnv] FILE Display the value of a symlink -f Canonicalize by following all symlinks -n Don't add newline -v Verbose #?0|kent:toolbox.git$ busybox.static realpath --help BusyBox v1.34.0 (2022-01-03 21:34:20 CET) multi-call binary. Usage: realpath FILE... Print absolute pathnames of FILEs --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
Geoff Clare wrote in
<20220225152553.GA4559@localhost>:
|Robert Elz wrote, on 25 Feb 2022:
|>
|> OK. I have looked at the coreutils realpath man page (gnu licensing
|> stupidity means I cannot look at their code), and I can see the
|> possibility (subject to community agreement) of implementing
|> some of the options it has. Not all.
|>
|> I'm not sure a -E option is needed, if the whole path exists it
|> makes no difference, if just the last component is missing, I
|> can't really imagine and BSD usage requiring an error in that case
|> (and anyone who needs tgat could use -e if I implement this).
|
|The point is it's a difference in behaviour between the two
|implementations. Rather than just making it unspecified whether
|the last component has to exist, it seemed to me that it would
|be more useful to have -e and -E options so that users have a
|way to ensure they get the same behaviour on both.
|
|So my preferences are (in descending order):
|
|1. POSIX adds realpath with -e and -E, and readlink without -f.
Why adjust a closed issue if all known implementations of
readlink(1) do support an identical -f?
|Unspecified which of -e or -E is the default.
|GNU adds a no-op -E to realpath.
|NetBSD/FreeBSD adds -E and a no-op -e to realpath.
|
|2. POSIX adds readlink with -f (whose behaviour is the same for
|both implementations). No realpath.
POSIX could also mention the possibility to handle these two
commands via "argv[0] tricks", "realpath like readlink -f"?
It portability is not an issue.
I looked in my things, i do have two use cases for realpath(1),
quite some more for readlink(1), which i even "fake" in my
~/.profile as necessary:
# UnixWare plus does not have readlink(1)
if command -v readlink >/dev/null 2>&1; then
:
else
readlink() {
echo "${*}"
}
fi
What a mess. POSIX has readlink(2) and realpath(3), coming from
that i would assume many programmers who "live" in a modern *x
environment simply take this for granted?
Ok, the manuals say
readlink - print resolved symbolic links or canonical file names
realpath - print the resolved path
but this is GNU only; On OpenBSD one can read
.Nd display target of symbolic link on standard output
.Nd print the canonicalized absolute pathname
and on FreeBSD (in /bin even!)
.Nd return resolved physical path
letting aside readlink for now.
The latter is why i personally would "naturally" think, as it
mirrors readlink(2) and realpath(3).
|3. POSIX adds realpath without -e and -E, and readlink without -f.
|Unspecified whether realpath needs last component to exist.
|
|I wasn't proposing any other options be included for realpath
|(except perhaps -q, depending on whether it behaves the same in
|both implementations).
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
in terms of "what's actually used in the wild", Android uses toybox (0BSD licensed, so anyone can look :-) ) for both on-device *and* for the OS build itself on the host. toybox readlink ( https://github.com/landley/toybox/blob/master/toys/other/readlink.c) currently supports: usage: readlink FILE... With no options, show what symlink points to, return error if not symlink. Options for producing canonical paths (all symlinks/./.. resolved): -e Canonical path to existing entry (fail if missing) -f Full path (fail if directory missing) -m Ignore missing entries, show where it would be -n No trailing newline -q Quiet (no output, just error code) since toybox tends to add things _as they're needed_, rather than "because coreutils has them", that's probably "solid anecdata" about what gets used in the wild. one thing i haven't seen mentioned so far (but which i added to toybox myself, so i know it's definitely in use) is that existing realpath implementations support *multiple* file arguments on the command line, not just one. On Fri, Feb 25, 2022 at 6:56 AM Robert Elz via austin-group-l at The Open Group wrote: > OK. I have looked at the coreutils realpath man page (gnu licensing > stupidity means I cannot look at their code), and I can see the > possibility (subject to community agreement) of implementing > some of the options it has. Not all. > > I'm not sure a -E option is needed, if the whole path exists it > makes no difference, if just the last component is missing, I > can't really imagine and BSD usage requiring an error in that case > (and anyone who needs tgat could use -e if I implement this). > > The -m opion just looks stupid, at first glance it would mean > that any trailing part of a path could be missing (since if > a subdir is absent, necessarily it cannot have contents, but > there is also the possibility of /e1/e2/m1/../l1/m2/../e3/l2 > where ane e? name is an existing directory, any l? is an > existing symlink, and each m? is non-existing junk. > Dealing with nonsense like this isn't worth the effort, so > -m is unlikely to ever happen. Some other option (maybe > -p for partial) could exist to allow resolving smylinks > in a leading existing prefix of a path, omitting any more > existance checks beyond that (so no more symlink resolution) > but only if there is some demonstrated need for that. > > -L is not an possibility, I could easily add a do nothing -P > option though (just like our shell's cd command). > > The long name options won't happen, and I find it hard to > see a real need for the 2 --relative options in any case, it > seems likely they could better, and more flexibly, be handled > by post processing the results than built in. > > Then we get to the harder choices ... -z looks easy, and > harmless, but in practice probably mostly useless. So I'm > not sure about that one. -s just turns the whole thing into > a simple string processing program, something that could be > done with a fairly simple sed script, so I'm not sure about > that either. > > Their man page is also woefully short on error details. > Eg: what counts as "missing". Obviously ENOENT, but > what about ENOTDIR in the case of /d/f/m > where d is an existing directory (or path), f is some > non directory file, and m is (obviously) missing? > Or EACCESS for /d/n/m? where d is as previously, > n is an existing directory without x permission (perhaps > no r permission either) and m? is presumed missing as > we cannot determine if it is there, and even if r perm > exists, so we can read /d/n and discover m? exists, > we do not know if is is a symlink or not (cannot lstat). > > This is something of a mess, and while I hesitate to say > it, all too typical of linux/gnu software which only > specifies what happens in the cases they think of, and > all else is just "whatever happens" and isn't necassarily > even consistent in one utility. > > With this it would be difficult (and pure fluke if it > happened) for me to implement something compat, and I'd > hesitate to even suggest adding code to be compat, unless > I could promise that is what tge result woukd be. > > Of course if there was a proposed POSIX spec that made it > clear what is intended in all these odd cases, that might > make a big difference. > > kre > >
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
Robert Elz wrote, on 25 Feb 2022: > > OK. I have looked at the coreutils realpath man page (gnu licensing > stupidity means I cannot look at their code), and I can see the > possibility (subject to community agreement) of implementing > some of the options it has. Not all. > > I'm not sure a -E option is needed, if the whole path exists it > makes no difference, if just the last component is missing, I > can't really imagine and BSD usage requiring an error in that case > (and anyone who needs tgat could use -e if I implement this). The point is it's a difference in behaviour between the two implementations. Rather than just making it unspecified whether the last component has to exist, it seemed to me that it would be more useful to have -e and -E options so that users have a way to ensure they get the same behaviour on both. So my preferences are (in descending order): 1. POSIX adds realpath with -e and -E, and readlink without -f. Unspecified which of -e or -E is the default. GNU adds a no-op -E to realpath. NetBSD/FreeBSD adds -E and a no-op -e to realpath. 2. POSIX adds readlink with -f (whose behaviour is the same for both implementations). No realpath. 3. POSIX adds realpath without -e and -E, and readlink without -f. Unspecified whether realpath needs last component to exist. I wasn't proposing any other options be included for realpath (except perhaps -q, depending on whether it behaves the same in both implementations). -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
OK. I have looked at the coreutils realpath man page (gnu licensing stupidity means I cannot look at their code), and I can see the possibility (subject to community agreement) of implementing some of the options it has. Not all. I'm not sure a -E option is needed, if the whole path exists it makes no difference, if just the last component is missing, I can't really imagine and BSD usage requiring an error in that case (and anyone who needs tgat could use -e if I implement this). The -m opion just looks stupid, at first glance it would mean that any trailing part of a path could be missing (since if a subdir is absent, necessarily it cannot have contents, but there is also the possibility of /e1/e2/m1/../l1/m2/../e3/l2 where ane e? name is an existing directory, any l? is an existing symlink, and each m? is non-existing junk. Dealing with nonsense like this isn't worth the effort, so -m is unlikely to ever happen. Some other option (maybe -p for partial) could exist to allow resolving smylinks in a leading existing prefix of a path, omitting any more existance checks beyond that (so no more symlink resolution) but only if there is some demonstrated need for that. -L is not an possibility, I could easily add a do nothing -P option though (just like our shell's cd command). The long name options won't happen, and I find it hard to see a real need for the 2 --relative options in any case, it seems likely they could better, and more flexibly, be handled by post processing the results than built in. Then we get to the harder choices ... -z looks easy, and harmless, but in practice probably mostly useless. So I'm not sure about that one. -s just turns the whole thing into a simple string processing program, something that could be done with a fairly simple sed script, so I'm not sure about that either. Their man page is also woefully short on error details. Eg: what counts as "missing". Obviously ENOENT, but what about ENOTDIR in the case of /d/f/m where d is an existing directory (or path), f is some non directory file, and m is (obviously) missing? Or EACCESS for /d/n/m? where d is as previously, n is an existing directory without x permission (perhaps no r permission either) and m? is presumed missing as we cannot determine if it is there, and even if r perm exists, so we can read /d/n and discover m? exists, we do not know if is is a symlink or not (cannot lstat). This is something of a mess, and while I hesitate to say it, all too typical of linux/gnu software which only specifies what happens in the cases they think of, and all else is just "whatever happens" and isn't necassarily even consistent in one utility. With this it would be difficult (and pure fluke if it happened) for me to implement something compat, and I'd hesitate to even suggest adding code to be compat, unless I could promise that is what tge result woukd be. Of course if there was a proposed POSIX spec that made it clear what is intended in all these odd cases, that might make a big difference. kre
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
Date:Fri, 25 Feb 2022 09:33:19 +
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID: <20220225093319.GA15607@localhost>
| Would you (or whoever maintains realpath for NetBSD)
It was added about 2 years ago ("is used in some scripts") and
hasn't been touched since ... no specific maintainer, and the
guy who added it hasn't been very active recently (other life
issues or projects I guess).
| be willing to add a -E option that makes your version behave like
| the coreutils default?
No specific objection from me currently, but I will find a man
page for that one (coreutils is in pkgsrc I think, so that should
be easy) and see what looks reasonable, then ask other NetBSD
developers. Almost anything might be possible.
| The alternative would be to go back to the original plan of just adding
| readlink (with the -f option for canonicalisation).
I'm not sure what the missing functionality in our realpath is
that makes readlink -f more attractive/practical for this purpose,
but I will see if I can find out...
| I assume that if NetBSD added -E, FreeBSD would have no problem with
| picking up that change.
It would be easier for them to do, I guess, but just because we
do doesn't mean they automatically copy (or vice versa).
Still this utility looks little known/used enough in the BSD world
that anything might be possible. We have "there's no point being
different, so be compat with linux" and "came from linux, must be
crap" points of view, and almost everything between.
kre
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
Robert Elz wrote, on 25 Feb 2022: > > | Does it have the same last-component-need-not-exist behaviour as the > | GNU coreutils default, or is it just a wrapper round realpath(3)? > > Just a wrapper. The substance of the thing is an 8 line loop, the > rest (about 60 lines total, ie: another 50+, not counting the boilerplate > copyright/licence comments at the start) is the standard stuff - blank lines, > includes, declarations, the getopt() loop for the 1 option (-q) supported, and > a usage() function. Would you (or whoever maintains realpath for NetBSD) be willing to add a -E option that makes your version behave like the coreutils default? Then POSIX could specify it with -e and -E options, and say it is unspecified which is the default. The alternative would be to go back to the original plan of just adding readlink (with the -f option for canonicalisation). > The NetBSD version came from FreeBSD, so unless theirs has been updated > recently, it will be the same. The FreeBSD man page only shows a -q option, so it appears it is still the same. https://www.freebsd.org/cgi/man.cgi?query=realpath=1 I assume that if NetBSD added -E, FreeBSD would have no problem with picking up that change. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
Date:Thu, 24 Feb 2022 15:57:08 + From:"Geoff Clare via austin-group-l at The Open Group" Message-ID: <20220224155708.GA912@localhost> | Does it have the same last-component-need-not-exist behaviour as the | GNU coreutils default, or is it just a wrapper round realpath(3)? Just a wrapper. The substance of the thing is an 8 line loop, the rest (about 60 lines total, ie: another 50+, not counting the boilerplate copyright/licence comments at the start) is the standard stuff - blank lines, includes, declarations, the getopt() loop for the 1 option (-q) supported, and a usage() function. The NetBSD version came from FreeBSD, so unless theirs has been updated recently, it will be the same. You can see the NetBSD one at: http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/realpath/ kre ps: we don't have the absurd -L option either of course, but we don't to cd -L either, that whole "logical path" thing is garbage that has long past its use-by date.
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
Robert Elz wrote, on 24 Feb 2022: > > | Solaris 11.4 has the GNU coreutils realpath. Do BSD systems have a > realpath > | utility? > > FreeBSD looks to, and it will be in NetBSD 10 when that gets released, > whenever that happens (it is almost as slow as posix-8...) (We have > had realpath(3) for a while). > > But the only option our realpath(1) has is -q ... no -e or -m options. Does it have the same last-component-need-not-exist behaviour as the GNU coreutils default, or is it just a wrapper round realpath(3)? -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
Date:Thu, 24 Feb 2022 09:28:21 + From:"Austin Group Bug Tracker via austin-group-l at The Open Group" Message-ID: <130f9dec10c1532c47e835c2df07b...@austingroupbugs.net> | Solaris 11.4 has the GNU coreutils realpath. Do BSD systems have a realpath | utility? FreeBSD looks to, and it will be in NetBSD 10 when that gets released, whenever that happens (it is almost as slow as posix-8...) (We have had realpath(3) for a while). But the only option our realpath(1) has is -q ... no -e or -m options. kre
[1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1457 == Reported By:steffen Assigned To:ajosey == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1457 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Under Review Name: Steffen Nurpmeso Organization: User Reference: Section:Vol. 3: Shell and Utilities. Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2021-03-09 21:21 UTC Last Modified: 2022-02-24 09:28 UTC == Summary:Add readlink(1) utility == -- (0005706) geoffclare (manager) - 2022-02-24 09:28 https://austingroupbugs.net/view.php?id=1457#c5706 -- Looking at the GNU coreutils man page for realpath(1), it seems that its default behaviour is the same as readlink -f in that all components except the last need to exist, but it has -e and -m options which alter the existence requirements. It also has a -L option which eliminates ".." components before following symlinks. I assume these features are the reason the readlink man page says realpath is preferred over readlink -f. Even though there is no longer any obstacle to standardising readlink -f, I think we should still consider adding realpath (alongside readlink without -f). Solaris 11.4 has the GNU coreutils realpath. Do BSD systems have a realpath utility? Issue History Date ModifiedUsername FieldChange == 2021-03-09 21:21 steffenNew Issue 2021-03-09 21:21 steffenStatus New => Under Review 2021-03-09 21:21 steffenAssigned To => ajosey 2021-03-09 21:21 steffenName => Steffen Nurpmeso 2021-03-09 21:21 steffenSection => Vol. 3: Shell and Utilities. 2021-03-09 21:21 steffenPage Number => (page or range of pages) 2021-03-09 21:21 steffenLine Number => (Line or range of lines) 2021-03-10 04:11 emaste Issue Monitored: emaste 2022-02-22 15:58 geoffclare Note Added: 0005700 2022-02-22 16:01 geoffclare Note Edited: 0005700 2022-02-22 16:09 geoffclare Note Edited: 0005700 2022-02-22 16:11 geoffclare Project 1003.1(2008)/Issue 7 => 1003.1(2016/18)/Issue7+TC2 2022-02-22 16:13 geoffclare Note Edited: 0005700 2022-02-22 21:39 emaste Note Added: 0005701 2022-02-22 21:41 emaste Note Deleted: 0005701 2022-02-22 22:19 steffenNote Added: 0005702 2022-02-22 22:34 calestyo Issue Monitored: calestyo 2022-02-23 08:32 geoffclare Note Added: 0005703 2022-02-23 13:31 emaste Note Added: 0005704 2022-02-23 13:38 calestyo Note Added: 0005705 2022-02-24 09:28 geoffclare Note Added: 0005706 ==
[1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1457 == Reported By:steffen Assigned To:ajosey == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1457 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Under Review Name: Steffen Nurpmeso Organization: User Reference: Section:Vol. 3: Shell and Utilities. Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2021-03-09 21:21 UTC Last Modified: 2022-02-23 13:38 UTC == Summary:Add readlink(1) utility == -- (0005705) calestyo (reporter) - 2022-02-23 13:38 https://austingroupbugs.net/view.php?id=1457#c5705 -- Re: #5703 "Note realpath(1) is the preferred command to use for canonicalization functionality." => but *just* for the canonicalization, AFAIU, realpath cannot print the resolved link (i.e. it's destination) Issue History Date ModifiedUsername FieldChange == 2021-03-09 21:21 steffenNew Issue 2021-03-09 21:21 steffenStatus New => Under Review 2021-03-09 21:21 steffenAssigned To => ajosey 2021-03-09 21:21 steffenName => Steffen Nurpmeso 2021-03-09 21:21 steffenSection => Vol. 3: Shell and Utilities. 2021-03-09 21:21 steffenPage Number => (page or range of pages) 2021-03-09 21:21 steffenLine Number => (Line or range of lines) 2021-03-10 04:11 emaste Issue Monitored: emaste 2022-02-22 15:58 geoffclare Note Added: 0005700 2022-02-22 16:01 geoffclare Note Edited: 0005700 2022-02-22 16:09 geoffclare Note Edited: 0005700 2022-02-22 16:11 geoffclare Project 1003.1(2008)/Issue 7 => 1003.1(2016/18)/Issue7+TC2 2022-02-22 16:13 geoffclare Note Edited: 0005700 2022-02-22 21:39 emaste Note Added: 0005701 2022-02-22 21:41 emaste Note Deleted: 0005701 2022-02-22 22:19 steffenNote Added: 0005702 2022-02-22 22:34 calestyo Issue Monitored: calestyo 2022-02-23 08:32 geoffclare Note Added: 0005703 2022-02-23 13:31 emaste Note Added: 0005704 2022-02-23 13:38 calestyo Note Added: 0005705 ==
[1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1457 == Reported By:steffen Assigned To:ajosey == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1457 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Under Review Name: Steffen Nurpmeso Organization: User Reference: Section:Vol. 3: Shell and Utilities. Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2021-03-09 21:21 UTC Last Modified: 2022-02-23 13:31 UTC == Summary:Add readlink(1) utility == -- (0005704) emaste (reporter) - 2022-02-23 13:31 https://austingroupbugs.net/view.php?id=1457#c5704 -- I added a comment about the -f option on FreeBSD, but deleted it moments later after realizing I was mistaken. FreeBSD documents stat and readlink in the same man page and the option summary is unclear about which options apply to which program. Here is an excerpt of the stat/readlink man page that describes only readlink: readlink [-fn] [file ...] When invoked as readlink, only the target of the symbolic link is printed. If the given argument is not a symbolic link and the -f option is not specified, readlink will print nothing and exit with an error. If the -f option is specified, the output is canonicalized by following every symlink in every component of the given path recursively. readlink will resolve both absolute and relative paths, and return the absolute pathname corresponding to file. In this case, the argument does not need to be a symbolic link. -n Do not force a newline to appear at the end of each piece of output. >From NetBSD's man page: readlink [-fnqsv] [file ...] When invoked as readlink, only the target of the symbolic link is printed. If the given argument is not a symbolic link and the -f option is not specified, readlink will print nothing and exit with an error. If the -f option is specified, the output is canonicalized by following every symlink in every component of the given path recursively. readlink will resolve both absolute and relative paths, and return the absolute pathname corresponding to file. In this case, the argument does not need to be a symbolic link. -nDo not force a newline to appear at the end of each piece of output. -qSuppress failure messages if calls to stat(2) or lstat(2) fail. When run as readlink, error messages are automatically suppressed. -s... When run as readlink, suppress error messages. -vTurn off quiet mode. And OpenBSD: readlink [-fn] file -f Canonicalize by following every symlink in every component of the given path recursively. readlink will resolve both absolute and relative paths and return the absolute pathname corresponding to file. The argument does not need to be a symbolic link. -n Do not print a trailing newline character. Issue History Date ModifiedUsername FieldChange == 2021-03-09 21:21 steffenNew Issue 2021-03-09 21:21 steffenStatus New => Under Review 2021-03-09 21:21 steffenAssigned To => ajosey 2021-03-09 21:21 steffenName => Steffen Nurpmeso 2021-03-09 21:21 steffenSection => Vol. 3: Shell and Utilities. 2021-03-09 21:21 steffenPage Number => (page or range of pages) 2021-03-09 21:21 steffenLine Number => (Line or range of lines) 2021-03-10 04:11 emaste Issue Monitored: emaste 2022-02-22 15:58 geoffclare Note Added: 0005700
[1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1457 == Reported By:steffen Assigned To:ajosey == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1457 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Under Review Name: Steffen Nurpmeso Organization: User Reference: Section:Vol. 3: Shell and Utilities. Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2021-03-09 21:21 UTC Last Modified: 2022-02-23 08:32 UTC == Summary:Add readlink(1) utility == -- (0005703) geoffclare (manager) - 2022-02-23 08:32 https://austingroupbugs.net/view.php?id=1457#c5703 -- I agree we should drop -f from readlink. I noticed that the GNU coreutils man page for readlink says "Note realpath(1) is the preferred command to use for canonicalization functionality." So perhaps we should add a realpath utility in place of readlink -f. Issue History Date ModifiedUsername FieldChange == 2021-03-09 21:21 steffenNew Issue 2021-03-09 21:21 steffenStatus New => Under Review 2021-03-09 21:21 steffenAssigned To => ajosey 2021-03-09 21:21 steffenName => Steffen Nurpmeso 2021-03-09 21:21 steffenSection => Vol. 3: Shell and Utilities. 2021-03-09 21:21 steffenPage Number => (page or range of pages) 2021-03-09 21:21 steffenLine Number => (Line or range of lines) 2021-03-10 04:11 emaste Issue Monitored: emaste 2022-02-22 15:58 geoffclare Note Added: 0005700 2022-02-22 16:01 geoffclare Note Edited: 0005700 2022-02-22 16:09 geoffclare Note Edited: 0005700 2022-02-22 16:11 geoffclare Project 1003.1(2008)/Issue 7 => 1003.1(2016/18)/Issue7+TC2 2022-02-22 16:13 geoffclare Note Edited: 0005700 2022-02-22 21:39 emaste Note Added: 0005701 2022-02-22 21:41 emaste Note Deleted: 0005701 2022-02-22 22:19 steffenNote Added: 0005702 2022-02-22 22:34 calestyo Issue Monitored: calestyo 2022-02-23 08:32 geoffclare Note Added: 0005703 ==
[1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1457 == Reported By:steffen Assigned To:ajosey == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1457 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Under Review Name: Steffen Nurpmeso Organization: User Reference: Section:Vol. 3: Shell and Utilities. Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2021-03-09 21:21 UTC Last Modified: 2022-02-22 22:19 UTC == Summary:Add readlink(1) utility == -- (0005702) steffen (reporter) - 2022-02-22 22:19 https://austingroupbugs.net/view.php?id=1457#c5702 -- Re #5701 That is a pity. Then despites Geoff's awesome work on providing a fully fledged standard entry including -f based on refined realpath() usage, readlink should stay and -f alone be dropped. And i should apologize for not looking everywhere. (That -f of Net and FreeBSD is really strange.) Issue History Date ModifiedUsername FieldChange == 2021-03-09 21:21 steffenNew Issue 2021-03-09 21:21 steffenStatus New => Under Review 2021-03-09 21:21 steffenAssigned To => ajosey 2021-03-09 21:21 steffenName => Steffen Nurpmeso 2021-03-09 21:21 steffenSection => Vol. 3: Shell and Utilities. 2021-03-09 21:21 steffenPage Number => (page or range of pages) 2021-03-09 21:21 steffenLine Number => (Line or range of lines) 2021-03-10 04:11 emaste Issue Monitored: emaste 2022-02-22 15:58 geoffclare Note Added: 0005700 2022-02-22 16:01 geoffclare Note Edited: 0005700 2022-02-22 16:09 geoffclare Note Edited: 0005700 2022-02-22 16:11 geoffclare Project 1003.1(2008)/Issue 7 => 1003.1(2016/18)/Issue7+TC2 2022-02-22 16:13 geoffclare Note Edited: 0005700 2022-02-22 21:39 emaste Note Added: 0005701 2022-02-22 21:41 emaste Note Deleted: 0005701 2022-02-22 22:19 steffenNote Added: 0005702 ==
[1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1457 == Reported By:steffen Assigned To:ajosey == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1457 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Under Review Name: Steffen Nurpmeso Organization: User Reference: Section:Vol. 3: Shell and Utilities. Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2021-03-09 21:21 UTC Last Modified: 2022-02-22 21:39 UTC == Summary:Add readlink(1) utility == -- (0005701) emaste (reporter) - 2022-02-22 21:39 https://austingroupbugs.net/view.php?id=1457#c5701 -- -f here conflicts with FreeBSD's readlink -f format Display information using the specified format. See the Formats section for a description of valid formats. Issue History Date ModifiedUsername FieldChange == 2021-03-09 21:21 steffenNew Issue 2021-03-09 21:21 steffenStatus New => Under Review 2021-03-09 21:21 steffenAssigned To => ajosey 2021-03-09 21:21 steffenName => Steffen Nurpmeso 2021-03-09 21:21 steffenSection => Vol. 3: Shell and Utilities. 2021-03-09 21:21 steffenPage Number => (page or range of pages) 2021-03-09 21:21 steffenLine Number => (Line or range of lines) 2021-03-10 04:11 emaste Issue Monitored: emaste 2022-02-22 15:58 geoffclare Note Added: 0005700 2022-02-22 16:01 geoffclare Note Edited: 0005700 2022-02-22 16:09 geoffclare Note Edited: 0005700 2022-02-22 16:11 geoffclare Project 1003.1(2008)/Issue 7 => 1003.1(2016/18)/Issue7+TC2 2022-02-22 16:13 geoffclare Note Edited: 0005700 2022-02-22 21:39 emaste Note Added: 0005701 ==
