View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001632Issue 8 draftsShell and Utilitiespublic2023-01-31 00:582024-06-11 09:12
Reporterkre Assigned To 
PrioritynormalSeverityObjectionTypeClarification Requested
Status ClosedResolutionAccepted As Marked 
Product VersionDraft 2.1 
NameRobert Elz
Organization
User Reference
SectionXCU 2.6.1
Page Number2319-2320
Line Number74775-74794
Final Accepted Text0001632:0006184
Summary0001632: Tilde expansions with HOME="" or HOME value ending in /
DescriptionThe current draft, and earlier versions, this is not a new problem, it
could have been filed against any older version - but as 2.6.1 has already
been updated for other reasons for Issue 8, it seemed sensible to use its
most recent draft, don't specify what should happen if HOME="" or if the
value of HOME ends in a '/' - including particularly, the case of HOME=/

The case of HOME=/ is perhaps most interesting, as if the text is treated
literally, which almost all shells do, the result of expanding ~/foo in
such a case is //foo which is an unspecified pathname (as I understand it).

A recent ksh93 produces /foo from this case, but that's the only shell I
can find which does (amusingly, for the case of HOME=/dir/ that version
of ksh93 produces /dir//foo for ~/foo whereas an older one produces //foo
for HOME=/ and /dir/foo for the HOME=/dir/ case)..

mksh also makes /dir/foo in the HOME=/dir/ case and //foo in the HOME=
case, most other shells simply do as the standard says, and replace the tilde
prefix (just '~' here) with the value of HOME, which results in the // in both
cases.

This leads to the desire to use HOME="" instead of HOME=/ in the case where
the home directory is intended to be the root directory, which results in
~/foo expanding to /foo in almost all shells (the now quite old FreeBSD shell
I use to test with doesn't expand ~ at all when $HOME is an empty string,
but that is. or quite likely was, clearly a bug, so I assume it has been
fixed sometime in the past several years).

However, despite the language of the standard:

   The pathname resulting from tilde expansion shall be treated as if
   quoted to prevent it being altered by field splitting and pathname
   expansion.

most shells expand a word which is just ~ to nothing if HOME='' rather
than (effectively) to "" which that sentence seems to require. Only
bash, the NetBSD shell, and the older version of ksh93 made "".
(Again, the FreeBSD shell just produces ~ here, for the same reason as above).

This all needs to be cleaned up.
Desired ActionI'd suggest requiring that if a pathname resulting from a tilde espansion
(a term which really ought be better defined - I assume that in ~/foo
where HOME=/dir that the pathname intended is "/dir" not "/dir/foo"
otherwise ~/*.c would never be able to work) ends in a / that if a /
occurs as the next character of the word containing the tilde expansion
be omitted from the result - as that produces better results overall
(despite it going to require changes in most shells, including the one
I maintain).

I'd also suggest being more explicit either than when HOME='' ~ expands
to "" or nothing (it makes no difference if there is more to the word).
For this, I'd prefer "" (for both the obvious reason, and because it is
more consistemt with both the current wording, and useful behaviour).
Tagsapplied_after_i8d3, tc3-2008

Activities

mirabilos

2023-02-06 01:46

reporter   bugnote:0006144

I’d prefer HOME= to be treated the same as HOME=/ wrt. expansion, and to make sure that these are logical concatenations of pathnames, e.g. '/home' + 'foo' = '/home/foo' but '/' + 'foo' = '/foo'. This avoids both “naïve” string concatenation and the problem of having to decide what to do with an empty string; I consider an empty string to not be a valid pathname and therefore not a valid expansion for a sole tilde.

I’m happy to change mksh to match; from a Debian perspective, we’re entering soft freeze in a few days so a speedy decision would be welcome.

geoffclare

2023-03-02 16:42

manager   bugnote:0006184

On page 2320 line 74793 section 2.6.1, change:
The pathname resulting from tilde expansion shall be treated as if quoted to prevent it being altered by field splitting and pathname expansion.
to:
The pathname that replaces the tilde-prefix shall be treated as if quoted to prevent it being altered by field splitting and pathname expansion; if a <slash> follows the tilde-prefix and the pathname ends with a <slash>, the trailing <slash> from the pathname should be omitted from the replacement. If the word being expanded consists of only the <tilde> character and HOME is set to the null string, this produces an empty field (as opposed to zero fields) as the expanded word.
<small>Note: A future version of this standard may require that if a <slash> follows the tilde-prefix and the pathname ends with a <slash>, the trailing <slash> from the pathname is omitted from the replacement.</small>

Issue History

Date Modified Username Field Change
2023-01-31 00:58 kre New Issue
2023-01-31 00:58 kre Name => Robert Elz
2023-01-31 00:58 kre Section => XCU 2.6.1
2023-01-31 00:58 kre Page Number => 2319-2320
2023-01-31 00:58 kre Line Number => 74775-74794
2023-02-06 01:46 mirabilos Note Added: 0006144
2023-03-02 16:42 geoffclare Note Added: 0006184
2023-03-02 16:44 geoffclare Final Accepted Text => 0001632:0006184
2023-03-02 16:44 geoffclare Status New => Resolved
2023-03-02 16:44 geoffclare Resolution Open => Accepted As Marked
2023-03-02 16:45 geoffclare Tag Attached: tc3-2008
2023-05-16 10:55 geoffclare Status Resolved => Applied
2023-05-16 10:55 geoffclare Tag Attached: applied_after_i8d3
2024-06-11 09:12 agadmin Status Applied => Closed