|Anonymous | Login||2022-05-28 14:14 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0001527||[1003.1(2016/18)/Issue7+TC2] Shell and Utilities||Objection||Error||2021-10-28 00:24||2022-02-04 10:18|
|Priority||normal||Resolution||Accepted As Marked|
|Section||XCU 4 / cd|
|Final Accepted Text||Note: 0005629|
|Summary||0001527: cd requires the impossible on standard output|
The STDOUT section of XCU 4(cd) says:
If a non-empty directory name from CDPATH is used, or if cd - is used,
an absolute pathname of the new working directory shall be written to
the standard output as follows:
Whether used as cd -P, or the ludicrous cd -L, this requires what might
From XCU 2.5.3 (shell vars):
PWD Set by the shell and by the cd utility. [...]
if there is insufficient permission on the current working
directory, or on any parent of that directory, to determine
what that pathname would be, the value of PWD is unspecified
So the standard clearly recognises that it is not always possioble to
determine the current working directory, which results in PWD being unspecified
but not in unspecified behaviour from cd or pwd (that's only if the user
Further, while not exactly common, nor is this a very rare event, it happens
from time to time, and is usually easily corrected by a simple cd to a fully
qualified path (one which works) which will result in establishing a value
for PWD, after which all is normal (which would not be able to be trusted if
the behaviour of cd was unspecified at that point).
In that state, if the user successfully does:
mkdir foo foo/bar
the text quoted above requires the cd command to print the full path
which, of course, is impossible to do correctly.
It is possible to get into this state after the shell has started (and PWD
is set) as well, though in that case it is typically only cd -P which has the
problem (the shell just "knows" that $PWD is correct, and all it takes to fix
it is some string manipulation in the cd -L case ... but not always true,
as the filesystem may have altered state after PWD was set.)
What shells do in this situation varies. Some print an error or warning
which they're not supposed to do, as "The standard error shall be used only
for diagnostic messages." and that means (according to XCU 1.4) that the
exit status must indicate an error, but for cd (at least without the not
yet existing -e option) when cd has changed directory successfully, it must
exit 0 (-e doesn't solve the problem for cd -L with PWD unset, and no
ability to discover a path of the current working directory anyway, so it
is irrelevant here).
Aside from the technically incorrect error message that is sometimes printed,
most shells print the (adjusted) relative path (which is what it usually, though
not always, is in these cases) that was used in the chdir() call. In the
example above that would be "foo/bar" - not an absolute path by any means.
(zsh almost does that, at least in the copy I have currently, but pretends it
is an absolute path by prepending a '/' - /foo/bar - which is nonsense, and
most probably simply a bug). Other shells simply print nothing in this case.
In the case that PWD is set, and cd -P is used, and the resulting directory's
path cannot be determined, yash seems to treat it something like cd -L, treating
PWD as if it were the correct physical path, and adjusting it. The result is
an absolute path, and in one case I saw it, was actually correct. There was
no way yash could have known that however - it was a guess (even if a well
Since the behaviour of the existing shells varies so much, I suspect that all
that it is possible to say in this situation is that the results are unspecified. Something similar may need to be said about what goes in PWD
(though there the existence of -e in issue8 might make a difference).
Whether it is also desirable to explicitly allow shells to issue an error in
this situation I will leave for future discussion (my shell does not...).
In lines 83024-83025 change the words
Between lines 83026 and 83027 insert a new paragraph.
In line 83027 change the word
This last change just because there are now two antecedent "if"
clauses, and an "Otherwise" would be ambiguous. Implementing the
necessary change in some other way might avoid that problem.
Additionally consider what might need to be altered elsewhere wrt how
PWD is to be set, or not, and any effects that might have. Given what is
in XCU 2.5.3 this might be considered unnecessary.
I did some testing and saw two behaviours when the current dir can't be determined:
In /bin/sh on Solaris 11.4 (a version of ksh93), cd writes nothing
In /bin/sh on macOS (bash 3), cd writes the pathname it passed to chdir()
These seem to me to be the only two reasonable behaviours, so I think instead of saying "it is unspecified what, if anything, is written to the standard output", I would prefer that the new text allows only those two choices.
We should perhaps also add some application usage text warning that applications should not assume that the pathname written by cd will always be an absolute pathname.
edited on: 2022-01-21 09:21
In lines 83024-83025 change the words
an absolute pathname of the new working directory shall be writtento
and the absolute pathname of the new working directory can be determined, that pathname shall be written
Between lines 83026 and 83027 insert a new paragraph
If an absolute pathname of the new current working directory cannot be determined, it is unspecified whether nothing is written to the standard output or the value of curpath used in step 10, followed by a <newline>, is written to the standard output.
In line 83027 change the word:
If a non-empty directory name from CDPATH is not used, and the directory argument is not <tt>'-'</tt>
After line 83048 add to APPLICATION USAGE:
If an absolute pathname of the new current working directory cannot be determined, and a non-empty directory name from CDPATH is used, cd may write a pathname to standard output that is not an absolute pathname.
"Between lines 83026 and 83027 insert a new paragraph
If an absolute pathname of the new current working cannot be determined,"
Is the word "directory" missing after "working"?
Don Cragun (manager)
edited on: 2022-01-21 04:03
Re Note: 0005630: Yes, thank you. Note: 0005629 will be edited in place to correct the typo.
|2021-10-28 00:24||kre||New Issue|
|2021-10-28 00:24||kre||Name||=> Robert Elz|
|2021-10-28 00:24||kre||Section||=> XCU 4 / cd|
|2021-10-28 00:24||kre||Page Number||=> 2563|
|2021-10-28 00:24||kre||Line Number||=> 83023-83027|
|2022-01-17 12:21||geoffclare||Note Added: 0005617|
|2022-01-20 16:39||geoffclare||Note Added: 0005629|
|2022-01-20 16:40||geoffclare||Interp Status||=> ---|
|2022-01-20 16:40||geoffclare||Final Accepted Text||=> Note: 0005629|
|2022-01-20 16:40||geoffclare||Status||New => Resolved|
|2022-01-20 16:40||geoffclare||Resolution||Open => Accepted As Marked|
|2022-01-20 16:40||geoffclare||Tag Attached: tc3-2008|
|2022-01-21 03:23||gbrandenrobinson||Note Added: 0005630|
|2022-01-21 04:01||Don Cragun||Note Added: 0005631|
|2022-01-21 04:02||Don Cragun||Note Edited: 0005631|
|2022-01-21 04:03||Don Cragun||Note Edited: 0005631|
|2022-01-21 04:03||Don Cragun||Note Edited: 0005629|
|2022-01-21 09:21||geoffclare||Note Edited: 0005629|
|2022-02-04 10:18||geoffclare||Status||Resolved => Applied|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|