Return to Revisions

Since most of the occurrences you reference are by me, I feel I have to give an answer here, though I will mostly paraphrase @Gilles.

I've been using list context vs scalar/non-list context (better than string context which can be confusing if not understood as non-list context) dozens of times since at least 2004 on usenet or unix.SE most of the time in articles discussing the impact of leaving expansions unquoted in Bourne-like shells. I don't remember anyone requesting clarification as to what I meant by that before (I do often try to give some examples of such contexts for illustration)

I've not used it in formal specification of any shell languages, that's just English text to help explain the shell behaviour to other persons.

That's not official terminology though that's obviously inspired from perl official (in the documentation) terminology. I can't tell if other persons have used those in the context of Unix shells before me (though it's very likely they did), but certainly people have since. I don't claim ownership of that.

list context (at least when I used it in the contexts I've used it) simply means contexts where the shell is expecting any number of elements. While scalar/non-list/string context would be where only one (or a single string/scalar if you want) is expected, like in perl. In most Bourne-like shells, those list contexts are:

• simple command arguments (as in echo elements)
• for i in elements
• array=(elements) (and variant with +=)

Some shells have more like:

• cmd < elements (and variant with <>) in zsh which does something similar to cat -- elements | cmd (as in nl < *.txt, nl < {foo,bar}.txt but nl < foo.txt < bar.txt).
• cmd > elements (and variants with >| >>...) in zsh which does something similar to cmd | tee -- elements
• elements() { code; } in zsh to define one ore more functions at once (or nothing if elements resolves to an empty list (though a literal () { echo x; } is an anonymous function)).
• compound=(foo=(elements) elements) or matrix=((elements) (elements)) and so on in ksh93.
• etc.

In those contexts, typically, globs are expanded and you need to quote your expansions if you don't want split+glob (or just empty-removal with zsh) to be applied to them.

For instance, if you replace elements with *.txt in the examples above, *.txt will be expanded to the list of txt files in the current directory.

If you're looking for an equivalent in the POSIX specification, look for the contexts where globs are expanded. POSIX, in at least one instance refers to that as a context where field splitting will be performed (wording which was actually changed after I raised issues with the previous wording to the Austin group). Of course, that wording is not very useful to answer the questions about where field splitting is performed.

The scalar contexts would be the other contexts.

In

scalar=*.txt case *.txt in... [[ -f *.txt ]] 

*.txt cannot be expanded because the shell is expecting just one string.

As a caveat/limitation, those terms don't cleanly capture what happens in cmd > * or cmd > ~(N)pattern or a=(); b=; c=(a b); d=*; IFS=:; e=a:b; cmd 1> "${a[@]}" 2> $b 3> "${c[@]}" 4> $d 5> $e in shells like bash/yash (when not in POSIX mode), ksh88 (using set -A instead of var=(...) syntax) or ksh93 (only when interactive with some), where it could be seen as another list context except that only a list with one element is expected (with splitting and globbing working differently for some).