Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

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 2024-06-11 09:07
Reporter kre View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Robert Elz
Organization
User Reference
Section XCU 4 / cd
Page Number 2563
Line Number 83023-83027
Interp Status ---
Final Accepted Text Note: 0005629
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
     /impossible/to/discover/foo/bar
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


to


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
Otherwise
to:


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 tc3-2008
Attached Files

- Relationships

-  Notes
(0005617)
geoffclare (manager)
2022-01-17 12:21

 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.
(0005629)
geoffclare (manager)
2022-01-20 16:39
edited on: 2022-01-21 09:21

 In lines 83024-83025 change the words
an absolute pathname of the new working directory shall be written
to
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:
Otherwise
to:
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.
(0005630)
gbrandenrobinson (reporter)
2022-01-21 03:23

 "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"?
(0005631)
Don Cragun (manager)
2022-01-21 04:01
edited on: 2022-01-21 04:03

 Re Note: 0005630: Yes, thank you. Note: 0005629 will be edited in place to correct the typo.

- 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
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
2024-06-11 09:07 agadmin Status Applied => Closed

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