Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
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 2021-10-28 00:24
Reporter kre View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name Robert Elz
User Reference
Section XCU 4 / cd
Page Number 2563
Line Number 83023-83027
Interp Status ---
Final Accepted Text
Summary 0001527: cd requires the impossible on standard output
Description 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
be impossible.

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
modifies PWD).

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
     export CDPATH=foo
     cd 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
educated one).

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...).

Desired Action In lines 83024-83025 change the words

an absolute pathname of
the new working directory shall be written


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
cannot be determined, it is unspecified what, if anything,
shall be 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>

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.
Tags No tags attached.
Attached Files

- Relationships

There are no notes attached to this issue.

- Issue History
Date Modified Username Field Change
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

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker