View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001976 | 1003.1(2024)/Issue8 | Shell and Utilities | public | 2026-03-13 21:10 | 2026-04-25 06:04 |
| Reporter | navi | Assigned To | |||
| Priority | normal | Severity | Editorial | Type | Enhancement Request |
| Status | New | Resolution | Open | ||
| Name | navi | ||||
| Organization | |||||
| User Reference | |||||
| Section | XCU: 2. Shell Command Language | ||||
| Page Number | -- | ||||
| Line Number | -- | ||||
| Interp Status | |||||
| Final Accepted Text | |||||
| Summary | 0001976: specify array variables and syntax | ||||
| Description | POSIX sh specifies one array per function, the argument array many sh implementations support having array variables past the argument array due to posix shell specifying a syntax for the argument array, sh implementations with array extensions naturally landed on similar and compatible syntax mksh, ksh93, bash, zsh, osh, yash, all support the following syntax: foo=(a b "c d" e) foo+=(f g) "${foo[@]}" # a b "c d" e f g "${foo[*]}" # "a b c d e f g" "${foo[expr]}" # indexed by expr, where expr is evaluated like $(( expr )) "${#foo[@]}" # 6, the lenght of foo additionally, mksh, ksh, and zsh, support declaring arrays as such: set -A name -- values notably ksh does not implement the name=(values) syntax, but has no other syntax that would conflict with it either ash and dash do not currently implement any sort of arrays, but also have no syntax that conflicts with the existing extensions | ||||
| Desired Action | rough first draft of changes: XBD 4.25: specify varname=(value) as assigning an array variable specify varname[expr]=value as assigning a entry in the array XCU: 2.5: specify array variables as containing an array of arbitrary byte sequences, except for null byte XCU: 2.6.2: specify ${parameter[@]} and ${parameter[*]} expansions matching 2.5.2 special parameters specify ${parameter[expr]} expansion, where expr is arithimetically expanded, then parameter is expanded matching 2.5.1 positional parameters | ||||
| Tags | No tags attached. | ||||
|
|
IMO, specifying arrays in POSIX sh is both impossible (see https://unix.stackexchange.com/questions/238080/test-for-array-support-by-shell/238129#238129 for details) and undesirable. Arrays would be yet another kludge added to a clunky shell design. Arrays/lists should have been the primary variable type in shells and several shells like rc and derivatives or fish have understood that. Unix had a chance to have a shell with clean list variable support with rc (from plan9 / Unix v10 in the late 80s; intended to be the successor of the Bourne shell then), but it's too late now. For sh, you'd want to at least disable implicit word splitting globbing upon unquoted parameter expansion (like with the set +o shwordsplit +o globsubst of the zsh implementation of sh) and certainly not go with the Korn design (as copied by bash). The fact that in all Bourne-like shell with arrays, indices are interpreted as arithmetic expressions complicates the parsing and tokenising significantly and is source of all sorts of bugs and vulnerabilities in particular if you want to allow array elements in any places that expect an lvalue. If you find yourself needing arrays in a sh script, you're probably using the wrong tool: consider switching to perl, ruby or other proper interpreted language, or a shell without so much of a baggage. |
|
|
I'm not sure I agree with that conclusion. The point of POSIX should not be to define a clean shell language. As you point out, it's too late for that and this is visible for more than just arrays. But shell scripts are not used for writing complex software. The reality of the situation is that (a) questions like the one you've linked to occur because people rely on arrays in practice, (b) support for arrays exists in numerous shells and having a common standard is more desirable than each new shell diverging in some new way, and (c) scripts currently need to bake kludges into their scripts like the ones you suggest in your answer you've linked to. I don't think "use another language" is the appropriate answer here but rather that the goal of POSIX should be to provide a uniform way to use the features people rely so that scripts can at least be written in a portable manner. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-03-13 21:10 | navi | New Issue | |
| 2026-04-24 07:17 | stephane | Note Added: 0007423 | |
| 2026-04-25 06:04 | Love4Boobies | Note Added: 0007424 |
