View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
00011721003.1(2016/18)/Issue7+TC2Shell and Utilitiespublic2017-11-24 17:322024-06-11 09:09
Reporterstephane Assigned To 
PrioritynormalSeverityObjectionTypeEnhancement Request
Status ClosedResolutionAccepted As Marked 
NameStephane Chazelas
Organization
User Reference
SectionTilde Expansion
Page Number2354
Line Number75026-75034
Interp StatusApproved
Final Accepted Text0001172:0004250
Summary0001172: shell tilde expansion. Clarify ~"user" ~user@domain ~$user ~$(logname) ~-1...
DescriptionThe spec currently says:

> If none of the characters in the tilde-prefix are quoted, the
> characters in the tilde-prefix following the <tilde> are
> treated as a possible login name from the user database.

However, it's not clear what happens if any of those characters
are quoted.

Also, a portable username is defined as [a-zA-Z._][a-zA-Z._-]*
(in both the $LOGNAME description and the "User name" base
definition, it may be worth having one refer to the other to
avoid duplication) but it's not clear whether the expansion of
~user@domain for instance, that is where the tilde prefix is not
a "portable user name" is defined or not (if getpwnam() knows
it for instance).

There is a lot of variation in that regard between
implementations, and the end result is that one can't expect
anything if the tilde prefix is anything but

^~[a-zA-Z._][a-zA-Z._-]*$ (as a BRE in the POSIX locale)

so it would be worth stating more clearly, and also add some
examples of typical cases where users could expect tilde
expansion to work but where it doesn't in practice in several
implementations like ~$user, ~"user", ~$(logname), ~"/bin"

Adding a way to retrieve the home directory of an arbitrary user
would also be useful. FreeBSD has "id -P" (also getent passwd on
several systems) though it doesn't work for users whose username
or gecos or home contains colons or newlines.
Desired ActionChange the content of the Tilde Expansion section to:

A "tilde-prefix" consists of an unquoted <tilde> character at
the beginning of a word, followed by all of the characters
preceding the first unquoted <slash> in the word, or all the
characters in the word if there is no unquoted <slash>. In an
assignment (see XBD Variable Assignment), multiple
tilde-prefixes can be used: at the beginning of the word (that
is, following the <equals-sign> of the assignment), following
any unquoted <colon>, or both. A tilde-prefix in an assignment
is terminated by the first unquoted <colon> or <slash> or the
end of the assignment word.

If the "tilde-prefix" consists of only the tilde character, it
is replaced by the value of the variable HOME. If HOME is unset,
the results are unspecified.

If the tilde-prefix, without the tilde character does not match
the syntax of a portable user name (ref to $LOGNAME), the
results are undefined.

  In particular, the results for ~"string", ~$var, ~foo@bar,
  ~"/bin", ~-1 are undefined as ", $, / and @ are not
  characters of the portable filename character set and -1 is
  not a portable username.

Otherwise, that tilde-prefix removed of the tilde character
shall be treated as a login name and the "tilde-prefix" shall be
replaced by a pathname of the initial working directory
associated with that login name obtained using the getpwnam()
function as defined in the System Interfaces volume of
POSIX.1-2008. If the system does not recognize the login name,
the results are undefined.
Tagstc3-2008

Relationships

related to 0000351 Closedajosey 1003.1(2008)/Issue 7 certain shell special built-ins should expand arguments in assignment context 

Activities

kre

2019-01-25 01:26

reporter   bugnote:0004226

I have sympathy for the issue, but not the details proposed
In particular nothing here needs to be undefined, unspecified
is sufficient.

I am not sure if it needs explicit mention or not (perhaps
in the rationale) [this is implicit in the desjred action]
but people attempting to understand ~ expansion as specified
(and generally implemented in sh, though not in csh) need to
be aware that it happens before any other expansions, including
parameter expansions and quote removal and the implications of
that -- I suspect that while you average reader will understand
that "~user" does no ~ expansion, as the ~ is quoted, and quotes
have not yet been removed, but I doubt that many will follow
through on that reasoning to understand that in ~"user" the user
name that would be looked up is "user" including the quotes.

That is if the user name happened to have (matched) quotes in it:
the user o'sullivan (if one existed, despite the portable
user name rules) cannot ever be found as in ~o'sullivan/... the
/ is quoted, and it will not be found by ~"o'sullivan"/ or
~o\'sullivan/ as in those the quoting chars are still in the
name being looked up. If we actually found and returned the home
directory for some user with the similar name, including the quote
chars, then we would be treated with contempt...

The standard could say to do quote removal on the tilde-prefix
before looking it up, but it doesn't, and doing so now would be
a new invention.

As the issue points out doesn't say what should happen if there
are quote chars. I might fix this issue, rather than with the
proposed new text, but by changing the sense of the relevant
sentence...

That is, alter
     If none of the characters in the tilde-prefix
     are quoted, the characters in the tilde-prefix
to
     If any of the characters in the tilde-prefix are
     quoted, the result is unspecified, otherwise the
     characters in the tilde-prefix ....

Just being unspecified what happens when the tilde-prefix contains
chars that are not valid for LOGNAME is enough to satisfy the
technical requirements, but being more explicit that this also
includes any quoting chars might be better.

geoffclare

2019-02-07 10:59

manager   bugnote:0004240

Last edited: 2019-02-14 16:40

 I'd suggest the Tilde Expansion section should be updated to contain:
A ``tilde-prefix'' consists of an unquoted <tilde> character at the beginning of a word, followed by all of the characters preceding the first unquoted <slash> in the word, or all the characters in the word if there is no <slash>. In an assignment (see [xref to XBD 4.23]), multiple tilde-prefixes can be used: one at the beginning of the word (that is, following the <equals-sign> of the assignment), or one following any unquoted <colon>, or both. A tilde-prefix in an assignment is terminated by the first unquoted <colon> or <slash>, or the end of the assignment word.

If the tilde-prefix consists of only the <tilde> character, it shall be replaced by the value of the variable HOME. If HOME is unset, the results are unspecified.

Otherwise, the characters in the tilde-prefix following the <tilde> shall be treated as a possible login name from the user database. If these characters do not form a portable login name (see the description of the LOGNAME environment variable in [xref to XBD 8.3]), the results are unspecified.

Note: since the tilde-prefix is not subject to further word expansions after the <tilde> is removed to obtain the login name, none of the following has a portable login name following the <tilde>:
~"string"
~'string'
~$var
~\/bin
owing to the presence of '"', '\'', '$', '\\' and '/' characters in the login name.

If the characters in the tilde-prefix following the <tilde> form a portable login name, the tilde-prefix shall be replaced by a pathname of the initial working directory associated with the login name. The pathname shall be obtained as if by using the getpwnam() function as defined in the System Interfaces volume of POSIX.1-2017. If the system does not recognize the login name, the results are unspecified.

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

geoffclare

2019-02-14 16:47

manager   bugnote:0004250

Interpretation response
------------------------
The standard is unclear on this issue, and no conformance distinction can
be made between alternative implementations based on this. This is being
referred to the sponsor.

Rationale:
-------------
None.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
Make the changes in 0001172:0004240

agadmin

2019-02-15 17:50

administrator   bugnote:0004256

Interpretation Proposed: 15 Feb 2019

agadmin

2019-03-19 14:14

administrator   bugnote:0004339

Interpretation Approved: 19 March 2019

Issue History

Date Modified Username Field Change
2017-11-24 17:32 stephane New Issue
2017-11-24 17:32 stephane Name => Stephane Chazelas
2017-11-24 17:32 stephane Section => Tilde Expansion
2017-11-24 17:32 stephane Page Number => 2354
2017-11-24 17:32 stephane Line Number => 75026-75034
2019-01-25 01:26 kre Note Added: 0004226
2019-02-07 10:59 geoffclare Note Added: 0004240
2019-02-14 16:32 geoffclare Note Edited: 0004240
2019-02-14 16:40 geoffclare Note Edited: 0004240
2019-02-14 16:43 eblake Relationship added related to 0000351
2019-02-14 16:47 geoffclare Note Added: 0004250
2019-02-14 16:48 geoffclare Interp Status => Pending
2019-02-14 16:48 geoffclare Final Accepted Text => 0001172:0004250
2019-02-14 16:48 geoffclare Status New => Interpretation Required
2019-02-14 16:48 geoffclare Resolution Open => Accepted As Marked
2019-02-14 16:48 geoffclare Tag Attached: tc3-2008
2019-02-15 17:50 agadmin Interp Status Pending => Proposed
2019-02-15 17:50 agadmin Note Added: 0004256
2019-03-19 14:14 agadmin Interp Status Proposed => Approved
2019-03-19 14:14 agadmin Note Added: 0004339
2019-11-08 11:51 geoffclare Status Interpretation Required => Applied
2024-06-11 09:09 agadmin Status Applied => Closed