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
0001048 [1003.1(2013)/Issue7+TC1] Shell and Utilities Editorial Enhancement Request 2016-04-28 15:29 2019-02-14 16:28
Reporter rhansen View Status public  
Assigned To
Priority normal Resolution Rejected  
Status Closed  
Name Richard Hansen
Organization
User Reference
Section 2.3.1 Alias Substitution; alias command; unalias command
Page Number 2322, 2429-2431, 3294-3295
Line Number 73690-73705, 77562-77660, 110566-110644
Interp Status ---
Final Accepted Text
Summary 0001048: deprecate alias and unalias
Description There are numerous problems with aliases:
  • their behavior varies significantly among implementations
  • they do not take effect right away; the following doesn't work as expected:
    alias foo=ls; foo
  • the behavior in nontrivial cases such as the following is unclear:
    alias foo='echo "'
foo bar baz"
  • the specification of aliases is complicated and likely to have bugs and unintended effects (see 0000953)
Due to these problems, and the superiority of functions in almost every way, I would like to deprecate aliases.
Desired Action Specific changes will be proposed later.
Tags No tags attached.
Attached Files

- Relationships
related to 0000953Closedajosey Alias expansion is under-specified 
related to 0001055Closed unspecified how much is parsed before execution begins 

-  Notes
(0003179)
geoffclare (manager)
2016-04-28 16:54

 I would support making aliases a feature that is only required to be supported in interactive shells. I think deprecating them altogether is a step too far, as their use to reduce typing in interactive shells is very widespread.
(0003180)
chet_ramey (reporter)
2016-04-28 17:55

 That's the default bash behavior. Alias expansion has to be enabled using the expand_aliases option when the shell is not interactive.

That option is enabled when the shell is in Posix mode, of course.
(0003182)
rhansen (manager)
2016-04-29 00:02
edited on: 2016-04-29 00:03

 There are both pros and cons to making alias and unalias have undefined behavior. Pros:
  • Implementations would be allowed to improve the user experience by having aliases take effect immediately (even after a semicolon).
  • Simpler:
    • It's one less thing a new implementation has to support to become conformant.
    • Static analysis of conformant scripts becomes easier.
    • Conformant implementations can become smaller (useful for embedded systems).
    • Simpler standard document.
Cons:
  • Conformant applications would be prohibited from using aliases.
I will edit this bugnote and update the lists as I think of more items.
(0003186)
joerg (reporter)
2016-04-29 09:10

 The behavior of ksh93 is to clear all non-builtin aliases
before starting scripts but to permit aliases local to a script.

The behavior of the current Bourne Shell is to clear all aliases
before starting scripts but to permit aliases local to a script.
There are no builtin aliases in the Bourne Shell.

Given that aliases are widely used and that functions are not the
general solution for all problems with aliases, I like to keep
aliases - how this should be done is a subject to discussion.

I am in hope that we may be able to agree with the bash maintainers
to come to a more unified behavior of aliases to permit to remove
"unspecified" behavior from the standard in future.

If we however decide to reduce the coverage for aliases in POSIX,
we should first solve other important problems in the standard,
that can be seen related to aliases e.g.:

- 0001025 and similar problems that are caused by the fact that
  e.g. the "type" builtin is not part of the standard. Note that
  ksh removed "type" and introduced a builtin alias type="whence -v"

- Check all ksh (and others???) builtin aliases that may have
  importance to unified behavior of different shell implementations
(0004249)
eblake (manager)
2019-02-14 16:27

 This was discussed in the February 14, 2019 teleconference. In light of the recent efforts to clarify which aspects of aliases are portable (see 0000953 and 0001055), and the fact that aliases are widely used in interactive shells, and there are scripts in the wild that use conditional definitions of aliases to make writing the rest of the script easier, we are reluctant to deprecate aliases at this time.

- Issue History
Date Modified Username Field Change
2016-04-28 15:29 rhansen New Issue
2016-04-28 15:29 rhansen Name => Richard Hansen
2016-04-28 15:29 rhansen Section => 2.3.1 Alias Substitution; alias command; unalias command
2016-04-28 15:29 rhansen Page Number => 2322, 2429-2431, 3294-3295
2016-04-28 15:29 rhansen Line Number => 73690-73705, 77562-77660, 110566-110644
2016-04-28 15:29 rhansen Interp Status => ---
2016-04-28 15:30 rhansen Tag Attached: issue8
2016-04-28 15:30 rhansen Relationship added related to 0000953
2016-04-28 16:54 geoffclare Note Added: 0003179
2016-04-28 17:55 chet_ramey Note Added: 0003180
2016-04-29 00:02 rhansen Note Added: 0003182
2016-04-29 00:03 rhansen Note Edited: 0003182
2016-04-29 00:03 rhansen Note Edited: 0003182
2016-04-29 09:10 joerg Note Added: 0003186
2019-02-14 16:21 eblake Relationship added related to 0001055
2019-02-14 16:27 eblake Note Added: 0004249
2019-02-14 16:28 eblake Status New => Closed
2019-02-14 16:28 eblake Resolution Open => Rejected
2019-02-14 16:28 geoffclare Tag Detached: issue8

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