Hi Stefan, and наб,
On 6/21/22 23:35, Stefan Puiu wrote:
On Mon, Jun 20, 2022 at 6:23 PM наб <nabijaczleweli@xxxxxxxxxxxxxxxxxx> wrote:
Hi!
On Mon, Jun 20, 2022 at 11:55:18AM +0300, Stefan Puiu wrote:
On Mon, Jun 20, 2022 at 2:40 AM наб <nabijaczleweli@xxxxxxxxxxxxxxxxxx> wrote:
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@xxxxxxxxxxxxxxxxxx>
---
man7/environ.7 | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/man7/environ.7 b/man7/environ.7
index 019c5a25a..24446c709 100644
--- a/man7/environ.7
+++ b/man7/environ.7
@@ -158,8 +158,12 @@ used by
to find manual pages, and so on.
.TP
.B PWD
-The current working directory.
-Set by some shells.
+Absolute path to the current working directory;
+required to be partially canonical (no
+.I .\&
+or
+.I ..\&
+components).
If any shell decides to ignore that part of the spec, is there
anything preventing them?
It no longer being a valid shell (if on startup) or providing an invalid
cd built-in (when cding), from the stand-point of conformance to both
the standard and historical shells.
My expectation from the Linux manual pages is that they document
behavior I'm likely to encounter in the real world on Linux, with
various libcs etc. Specs can be misread, misunderstood, ignored, or
can be wrong sometimes (see the discussion about fork being required
to be async signal safe, for example, the RH page here:
https://access.redhat.com/articles/2921161). So if I write software
that, say, does getent("PWD"), it's useful to know if there are cases
where that might not work. Even if POSIX requires PWD to be set,
that's not reassuring when my program crashes. That's why I asked if
you checked some shells to see what they do.
Also, I see there's already environ.3p for the POSIX version.
I would make it clear in the text that this
is a spec requirement, not a practical guarantee (e.g. "required by
<spec> to be ...").
Those are one and the same, that's the point of SUS/POSIX
(and conformance to historical implementations).
Are you aware of one or are you just concern-trolling?
I don't know of a shell that doesn't set PWD, but since you said the
previous comment ("Some shells set it") was wrong, I assumed you had
checked that. I did try bash and busybox sh and they seem to set it,
but there are (quite) a few other shells out there.
Since no-one seems to know of a shell that deviates from this behavior,
and no-one replied in a couple of weeks, I'm going to assume that all
well-known shells follow POSIX, and that the wording was falling on the
safe side of things in the old times where following standards was not a
common thing to do (or maybe the page was written before there were any
standards).
So I applied the patch.
I don't know why you think that my question is some kind of trolling.
You can look up my contributions in the mailing list archive. It's
been a while since my last patch to the project; nowadays I follow
some of the mailing list discussions in my spare time and occasionally
chime in on people's patches. I get things wrong sometimes, of course,
but your reply is the first one that is defensive (and somewhat rude,
I would say). Probably a good indication that I need to find other
uses of my (spare) time.
Thanks for following the list, I appreciate your reviews!
Obviously, pretty much no part of this manual applies to csh
because csh is its own 2BSD brand of insanity (in this case
largely because it predates V7 (3BSD), and, hence, the environment).
csh users understand they use a non-shell,
Well, this is the environ.7 man page, mostly useful to programmers
AFAICT, who don't have much control over what people use as their
shell. If they can set csh as their login shell, why should I assume
they won't? People have many reasons to choose the shell they run -
distro default, they like some features, speed, company policy, legacy
systems... Not sure POSIX compliance is high on that list.
I checked csh(1) provides PWD, at least on my system (and in fact, it's
the only variable it sets):
$ env -i csh
% env
PWD=/home/alx
% csh -l
% env
PWD=/home/alx
%
I'm going to assume that the text is not true, unless someone reports
otherwise.
Thanks you both!
Alex
--
Alejandro Colomar
<http://www.alejandro-colomar.es/>
