View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
00012321003.1(2016/18)/Issue7+TC2Shell and Utilitiespublic2019-03-02 23:352024-06-11 09:08
Reporterstephane Assigned To 
PrioritynormalSeverityObjectionTypeEnhancement Request
Status ClosedResolutionAccepted As Marked 
NameStephane Chazelas
Organization
User Reference
SectionShell redirection
Page Number2361
Line Number75317-75319
Interp StatusApproved
Final Accepted Text0001232:0004414
Summary0001232: redirection to wildcard that match more than one word
Description> Pathname expansion shall not be performed on the word by a
> non-interactive shell; an interactive shell may perform it,
> but shall do so only when the expansion would result in one
> word.

That wording matches the behaviour of ksh88 or pdksh, but not
that of bash or ksh93, which when the expansion would result in
more than one word fail the redirected command with an
"ambiguous redirect" error instead of leaving the wildcard
unexpanded (which IMO, is slightly saner).

zsh does a tee-like redirection in cmd > * and a cat-like input
redirection in cmd < *, but not when in sh mode.
Desired ActionChange to:

> Pathname expansion shall not be performed on the word by a
> non-interactive shell; an interactive shell may perform it
> but if the expansion would result in more than one word, the
> behaviour is unspecified.


Related: ksh88 does that expansion even when non-interactive. As
the POSIX specification deviates from that reference
implementation, it would be useful to add a "rationale" section
stating it clearly and add a test case to the conformance test
suite as there are still many certified systems that are not
compliant in that regard.

It's quite serious as it means that code like cmd > $file could
end up redirecting to a different file from the one stored in
$file even though POSIX guarantees it should not.

That's why in practice we also need to quote parameter expansions
and command substitutions in the target of redirections even in
scripts (for ksh88, but also for bash when not in sh mode).
Tagstc3-2008

Activities

geoffclare

2019-06-10 15:30

manager   bugnote:0004414

Interpretation response
------------------------
The standard states the requirements for pathname expansion in redirections, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor.

Rationale:
-------------
The standard does not match some existing practice.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
Change:
Pathname expansion shall not be performed on the word by a non-interactive shell; an interactive shell may perform it, but shall do so only when the expansion would result in one word.
to:
Pathname expansion shall not be performed on the word by a non-interactive shell; an interactive shell may perform it, but if the expansion would result in more than one word it is unspecified whether the redirection proceeds without pathname expansion being performed or the redirection fails.

<small>Note: a future version of this standard may require that the redirection fails in this case.</small>

stephane

2019-06-10 17:22

reporter   bugnote:0004415

Re: 0001232:0004414
> it is unspecified whether the redirection proceeds without pathname expansion being performed or the redirection fails

Why restrict to only these two behaviours? The zsh behaviour sounds more useful here IMO (it's not done in sh mode in zsh, but I can imagine more sh implementations could want to do something along those lines if the spec allowed it). It would not make much difference to the shell user. The spec already tells them they can't use globs in redirection portably.

(not that I care much either way, to me the POSIX standard is only useful for scripts, I can't imagine anyone using sh as their interactive shell, let alone caring if what they do in it is portable).

geoffclare

2019-06-11 08:24

manager   bugnote:0004417

Re: 0001232:0004415 Two reasons - one you stated yourself: zsh does not behave that way in sh mode; the other is that for most users if a pattern matches more than one file, it's because they made a mistake in the pattern, in which case a failure is the most helpful behaviour - hence the note about a future version requiring it.

agadmin

2019-10-07 15:17

administrator   bugnote:0004605

Interpretation proposed: 7 October 2019

agadmin

2019-11-11 12:20

administrator   bugnote:0004649

Interpretation Approved: 11 Nov 2019

Issue History

Date Modified Username Field Change
2019-03-02 23:35 stephane New Issue
2019-03-02 23:35 stephane Name => Stephane Chazelas
2019-03-02 23:35 stephane Section => Shell redirection
2019-03-02 23:35 stephane Page Number => 2361
2019-03-02 23:35 stephane Line Number => 75317-75319
2019-06-10 15:30 geoffclare Note Added: 0004414
2019-06-10 15:31 geoffclare Interp Status => Pending
2019-06-10 15:31 geoffclare Final Accepted Text => 0001232:0004414
2019-06-10 15:31 geoffclare Status New => Interpretation Required
2019-06-10 15:31 geoffclare Resolution Open => Accepted As Marked
2019-06-10 15:32 geoffclare Tag Attached: tc3-2008
2019-06-10 17:22 stephane Note Added: 0004415
2019-06-11 08:24 geoffclare Note Added: 0004417
2019-10-07 15:17 agadmin Interp Status Pending => Proposed
2019-10-07 15:17 agadmin Note Added: 0004605
2019-11-11 12:20 agadmin Interp Status Proposed => Approved
2019-11-11 12:20 agadmin Note Added: 0004649
2019-12-04 11:54 geoffclare Status Interpretation Required => Applied
2024-06-11 09:08 agadmin Status Applied => Closed