2017-06-12 09:58:30 +0100, Geoff Clare:
[...]
> > - In the second case (the one in FreeBSD, Linux and Solaris at
> > least), that's the inode number of a file we
> > cannot access by that path (and again, applications using
> > d_inos to detect hard links could be fooled).
[...]
> You say tha
Stephane Chazelas wrote, on 09 Jun 2017:
>
> 2017-06-09 15:46:56 +0100, Stephane Chazelas:
> [...]
> > In addition to leaving it unspecified whether a "." or ".."
> > entry is returned, we may also want to clarify (or leave
> > unspecified) what d_ino the ".." entry may have for mount-points
> > a
2017-06-09 15:46:56 +0100, Stephane Chazelas:
[...]
> In addition to leaving it unspecified whether a "." or ".."
> entry is returned, we may also want to clarify (or leave
> unspecified) what d_ino the ".." entry may have for mount-points
> and that in any case, there's no guarantee that it would
2017-06-08 15:19:01 +0100, Geoff Clare:
[...]
> In any case, the problem statement is only the submitter's
> interpretation. The fact that the bug was accepted does not mean
> the group agreed with the problem statement, only with the
> suggested change.
[...]
Yes, sorry, I did not mean to imply
2017-06-08 22:34:30 +0700, Robert Elz:
> Date:Thu, 8 Jun 2017 10:50:07 +0100
> From:Stephane CHAZELAS
> Message-ID: <20170608095007.gb7...@chaz.gmail.com>
>
> | It would be like saying: find . -name '.*' should report all the
> | . and .. entries, because those en
Date:Thu, 8 Jun 2017 10:50:07 +0100
From:Stephane CHAZELAS
Message-ID: <20170608095007.gb7...@chaz.gmail.com>
| It would be like saying: find . -name '.*' should report all the
| . and .. entries, because those entries are there and we don't
| want "find" second
Stephane Chazelas wrote, on 08 Jun 2017:
>
> 2017-06-08 12:11:22 +0100, Geoff Clare:
> [...]
> > I can't answer that without knowing why the Base Working Group decided
> > to put in that text instead of using the POSIX.1-1990 text. It's
> > possible there might be some defect report against a dra
Stephane Chazelas wrote, on 08 Jun 2017:
>
> 2017-06-08 12:11:22 +0100, Geoff Clare:
> [...]
> > > OK, but the question remains: "what does it mean?". A "stricter
> > > requirement" for what? That "." or ".." should not come without
> > > the other (my interpretation)? Or that they should not be
>
It supports base POSIX systems aren't non-conforming, if they use how I
interpret it.
Requiring both if one exists but not the other is XSI, it looks, but my copy of
c165.pdf just has the shading, not the XSI margin code. So we could both be
right and wrong on this, lol.
On Thursday, June 8, 20
2017-06-08 12:11:22 +0100, Geoff Clare:
[...]
> I can't answer that without knowing why the Base Working Group decided
> to put in that text instead of using the POSIX.1-1990 text. It's
> possible there might be some defect report against a draft of XSH4, or
> a discussion in the email archives fr
2017-06-08 12:11:22 +0100, Geoff Clare:
[...]
> > OK, but the question remains: "what does it mean?". A "stricter
> > requirement" for what? That "." or ".." should not come without
> > the other (my interpretation)? Or that they should not be
> > treated specially (Mark's interpretation) or that t
Stephane Chazelas wrote, on 08 Jun 2017:
>
> 2017-06-08 10:53:52 +0100, Geoff Clare:
> > Stephane CHAZELAS wrote, on 08 Jun 2017:
> > >
> > > I can see that text was already there at
> > > http://archive.opengroup.org/publications/archive/CDROM/c435.pdf
> > > (1994, I don't think I have access to
2017-06-08 11:01:29 +0100, Geoff Clare:
> Robert Elz wrote, on 08 Jun 2017:
> >
> > And while here, I am also not in favour of attempts to "fix" breakage, just
> > so we appear to conform to the standard. If "." and ".." are supposed to
> > appear in the directories, and (for whatever reason) onl
2017-06-08 10:53:52 +0100, Geoff Clare:
> Stephane CHAZELAS wrote, on 08 Jun 2017:
> >
> > I can see that text was already there at
> > http://archive.opengroup.org/publications/archive/CDROM/c435.pdf
> > (1994, I don't think I have access to older POSIX/Unix related
> > specifications), but marke
Robert Elz wrote, on 08 Jun 2017:
>
> And while here, I am also not in favour of attempts to "fix" breakage, just
> so we appear to conform to the standard. If "." and ".." are supposed to
> appear in the directories, and (for whatever reason) only one of them happens
> to be there, then readdir(
Stephane CHAZELAS wrote, on 08 Jun 2017:
>
> I can see that text was already there at
> http://archive.opengroup.org/publications/archive/CDROM/c435.pdf
> (1994, I don't think I have access to older POSIX/Unix related
> specifications), but marked "EX" (extension) there which doesn't
> tie up with
2017-06-08 11:10:36 +0200, Joerg Schilling:
> Stephane CHAZELAS wrote:
>
> > Could it be that it means that "." and ".." should be returned
> > *first* when they're there on XSI systems? (which would be yet
> > another interpretation that is valid as an "extension" (non-XSI
> > are allowed to ret
Stephane CHAZELAS wrote:
> Could it be that it means that "." and ".." should be returned
> *first* when they're there on XSI systems? (which would be yet
> another interpretation that is valid as an "extension" (non-XSI
> are allowed to return other entries before "." and "..")).
>From what I c
Yes, pretty much. I can't say why it's phrased as it is, I didn't write it. I
lean towards some implementation was making unnamed dirents if the file system
didn't have those as names, perhaps originally for 8" floppies or 9 track
tapes, so something intended to preclude that was added in as sho
2017-06-08 03:37:30 +0700, Robert Elz:
> Date:Wed, 7 Jun 2017 20:56:17 +0100
> From:Stephane CHAZELAS
> Message-ID: <20170607195617.gf5...@chaz.gmail.com>
>
> | I imagine that text was there for some reason.
>
> I have always thought that what was important was the
Date:Wed, 7 Jun 2017 20:56:17 +0100
From:Stephane CHAZELAS
Message-ID: <20170607195617.gf5...@chaz.gmail.com>
| I imagine that text was there for some reason.
I have always thought that what was important was the "one" and that
the main purpose of that language was
2017-06-07 12:41:31 -0400, shwares...@aol.com:
> Because of the 'dot or dot-dot', not 'dot and dot-dot', I construe 'they'
> as "one or the other, or both if both missing" shall not be returned. You
> don't synthesize an unnamed or assigned name record for one that isn't
> present, to relate
Date:Wed, 7 Jun 2017 13:00:27 +0100
From:Stephane Chazelas
Message-ID: <20170607120027.gd5...@chaz.gmail.com>
| I even wonder if anyone would _object_ to POSIX *recommending*
| (if not mandating) the pdksh/zsh behaviour.
I think I would, I am not generally in fav
Because of the 'dot or dot-dot', not 'dot and dot-dot', I construe 'they'
as "one or the other, or both if both missing" shall not be returned. You
don't synthesize an unnamed or assigned name record for one that isn't
present, to relate it to rest of paragraph. This may be off, I can see why
2017-06-07 10:58:58 -0400, shwares...@aol.com:
> Applications can be written portably and are expected to take into account
> a generic file operand is '.' or '..' already; readdir() may or may
> not include '.' or '..' values whenever a path crosses a device mount
> boundary. It may only ha
Applications can be written portably and are expected to take into account
a generic file operand is '.' or '..' already; readdir() may or may
not include '.' or '..' values whenever a path crosses a device mount
boundary. It may only have one or the other entries on the media to report;
t
Stephane Chazelas wrote:
> So pdksh/zsh globs are currently only non-compliant in that they
> may not match what readdir() returns, but in anycase,
> applications cannot make much assumption on whether "." or ".."
> should be returned, so that compliance issue is not very
> relevant. Which is why
2017-06-07 12:24:33 +0100, Geoff Clare:
[...]
> > Yes, it's hard to tell what behaviour one can rely on with the
> > current text. Is opendir(".") required to open the current
> > directory even if there's no "." entry in the current directory
> > (same for "..")? Is foo/./bar required to be the s
Stephane CHAZELAS wrote:
> Yes, it's hard to tell what behaviour one can rely on with the
> current text. Is opendir(".") required to open the current
> directory even if there's no "." entry in the current directory
> (same for "..")? Is foo/./bar required to be the same as
> foo/bar?
Since th
Stephane CHAZELAS wrote, on 07 Jun 2017:
>
> 2017-06-07 12:41:52 +0200, Joerg Schilling:
> > Stephane Chazelas wrote:
> >
> > > Do you have an opinion on whether POSIX should allow the
> > > expansion of globs not to include "." and ".." by default?
> >
> > The fact that some filesystems includ
2017-06-07 12:41:52 +0200, Joerg Schilling:
> Stephane Chazelas wrote:
>
> > Do you have an opinion on whether POSIX should allow the
> > expansion of globs not to include "." and ".." by default?
>
> The fact that some filesystems include "." and ".." in the readdir()
> output does not make the
Stephane Chazelas wrote:
> Do you have an opinion on whether POSIX should allow the
> expansion of globs not to include "." and ".." by default?
The fact that some filesystems include "." and ".." in the readdir()
output does not make these entries required by POSIX.
In 1990, my "WOFS" did alre
Stephane Chazelas wrote, on 07 Jun 2017:
>
> Do you have an opinion on whether POSIX should allow the
> expansion of globs not to include "." and ".." by default?
It's already optional, in a way, as a consequence of it being
optional whether "." and ".." are present in the directory.
However, I t
2017-06-07 09:03:52 +0100, Geoff Clare:
> Stephane Chazelas wrote, on 06 Jun 2017:
[...]
> > rm -rf ./ ../
> >
> > AFAICT, with the above wording, that doesn't allow rm
> > implementations to apply that safeguard in those cases (even
> > though it's al
gnostic message to
> > standard error and do nothing more with such operands.
>
[...]
> Now what about:
>
> rm -rf ./ ../
>
> AFAICT, with the above wording, that doesn't allow rm
> implementations to apply that safeguard in those cases (even
> though it&#x
d fish at least.
"rm" seems to be the only command where that safeguard is
applied. (find .*, ls -R .*, chmod -R 777 .*, chown -R nobody
.* don't have such safeguards).
Now what about:
rm -rf ./ ../
AFAICT, with the above wording, that doesn't allow rm
implementations to app
36 matches
Mail list logo
