List of “list contexts” [closed]
Clash Royale CLAN TAG#URR8PPP
In perl, a list context is mostly where an array variable is used (or could be used), simple.
In the shell, there are no array variables. However, the undefined list context description is sometimes used.
What is a practical list of list contexts examples ?
When should a list context term be used ?
shell
closed as unclear what you're asking by filbranden, Stephen Harris, ilkkachu, roaima, Scott Mar 2 at 23:50
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |
In perl, a list context is mostly where an array variable is used (or could be used), simple.
In the shell, there are no array variables. However, the undefined list context description is sometimes used.
What is a practical list of list contexts examples ?
When should a list context term be used ?
shell
closed as unclear what you're asking by filbranden, Stephen Harris, ilkkachu, roaima, Scott Mar 2 at 23:50
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
What answer are you expecting that is not already covered in the Q&A you link to (What is (exactly) "list context" (and "string context")?)?
– Stéphane Chazelas
Mar 2 at 17:45
Possible duplicate of What is (exactly) "list context" (and "string context")?
– ilkkachu
Mar 2 at 20:02
add a comment |
In perl, a list context is mostly where an array variable is used (or could be used), simple.
In the shell, there are no array variables. However, the undefined list context description is sometimes used.
What is a practical list of list contexts examples ?
When should a list context term be used ?
shell
In perl, a list context is mostly where an array variable is used (or could be used), simple.
In the shell, there are no array variables. However, the undefined list context description is sometimes used.
What is a practical list of list contexts examples ?
When should a list context term be used ?
shell
shell
edited Mar 6 at 14:19
slm♦
255k71539687
255k71539687
asked Mar 2 at 3:20
anon
closed as unclear what you're asking by filbranden, Stephen Harris, ilkkachu, roaima, Scott Mar 2 at 23:50
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as unclear what you're asking by filbranden, Stephen Harris, ilkkachu, roaima, Scott Mar 2 at 23:50
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
What answer are you expecting that is not already covered in the Q&A you link to (What is (exactly) "list context" (and "string context")?)?
– Stéphane Chazelas
Mar 2 at 17:45
Possible duplicate of What is (exactly) "list context" (and "string context")?
– ilkkachu
Mar 2 at 20:02
add a comment |
What answer are you expecting that is not already covered in the Q&A you link to (What is (exactly) "list context" (and "string context")?)?
– Stéphane Chazelas
Mar 2 at 17:45
Possible duplicate of What is (exactly) "list context" (and "string context")?
– ilkkachu
Mar 2 at 20:02
What answer are you expecting that is not already covered in the Q&A you link to (What is (exactly) "list context" (and "string context")?)?
– Stéphane Chazelas
Mar 2 at 17:45
What answer are you expecting that is not already covered in the Q&A you link to (What is (exactly) "list context" (and "string context")?)?
– Stéphane Chazelas
Mar 2 at 17:45
Possible duplicate of What is (exactly) "list context" (and "string context")?
– ilkkachu
Mar 2 at 20:02
Possible duplicate of What is (exactly) "list context" (and "string context")?
– ilkkachu
Mar 2 at 20:02
add a comment |
2 Answers
2
active
oldest
votes
The Perl comparison is not really helpful. That is a rigorously defined term in Perl, with specific meanings that affect how variables are treated in Perl. The term list context isn't an "official" thing in the shell world. It isn't mentioned anywhere in POSIX, for example. Note how the term is actually defined in most of the cases you point out where it is used: the very answer you link to (emphasis mine):
[. . .] on all words in list context (command line arguments or the words the for loops loop on)
(source)
There are two contexts in shell syntax: list context and string context. Field splitting and filename generation only happen in list context, but that's most of the time. Double quotes delimit a string context: the whole double-quoted string is a single string, not to be split.
(source)
So, essentially when you see the term "list context" with respect to a shell, this isn't an official term and is basically just used to mean "not explicitly a string", in other words, subject to split+glob and shell expansion.
POSIX does actually use list (not "list context"), but in two very different ways. It uses is as a specific, defined term to describe sets of commands (emphasis in the original):
2.9.3 Lists
An AND-OR list is a sequence of one or more pipelines separated by the operators "&&" and "||" .
A list is a sequence of one or more AND-OR lists separated by the
operators ';' and '&'.
The operators "&&" and "||" shall have equal precedence and shall be
evaluated with left associativity. For example, both of the following
commands write solely bar to standard output:false && echo foo || echo bar
true || echo foo && echo bar
A ';' separator or a ';' or terminator shall cause the
preceding AND-OR list to be executed sequentially; an '&' separator or
terminator shall cause asynchronous execution of the preceding AND-OR
list.
The term "compound-list" is derived from the grammar in Shell Grammar;
it is equivalent to a sequence of lists, separated by
characters, that can be preceded or followed by an arbitrary number of
characters.
However, the word list, since it is also the term used in everyday English to denote a set of items, is used quite often in the POSIX specs, usually to refer to lists of arguments. For example:
- The shell performs various expansions (separately) on different parts of each command, resulting in a list of pathnames and fields to be treated as a command and arguments; see wordexp.
(Section 2.1)
If a simple command results in a command name and an optional list of arguments, the following actions shall be performed:
(Section 2.9.1)
The for loop shall execute a sequence of commands for each member in a list of items.
[. . .]
First, the list of words following in shall be expanded to generate a list of items.
(Section 2.9.4)
Returning to the top of the loop involves repeating the condition list of a while or until loop or performing the next assignment of a for loop, and re-executing the loop if appropriate.
continue
builtin
All this is to say that when we refer to "list context" with respect to a shell, we are not using a strict, rigorously defined term such as Perl's, we're just referring to things the shell will treat as a list of items. Things that will be expanded, split, globbed etc. So, practically, any non-quoted collection of characters could be considered a list.
add a comment |
perl
has no "list variables". perl
has scalars, arrays, and hashes, and all of them could be used in a list or scalar context (with the void context as a special kind of scalar context). All subs (functions) in perl
take lists as arguments and return lists. A list behaves differently from an array:
my @v = qw(a b c); my $v = @v; # $v will be 3
my @v = qw(a b c); my $v = @v[0..$#v]; # $v will be 'c'
This is all well documented in the perldata(1) manpage. The name of the operator which checks the type of the current context (wantarray
) is simply a historical accident.
A bourne-like (POSIX) shell has nothing similar, so the question doesn't make much sense; are you wondering where an unquoted variable expansion is not subject to splitting with IFS
and pathname expansion (globbing)? I can think of the right side of a=$var
variable assignment, and the word and patterns of a case
command: case $var in $pat) ...
. A comprehensive list will only be of interest to someone writing another shell implementation, and hopefully they won't base it on stackexchange answers ;-)
How does a shell not have anything similar? You could even argue that only quoted strings are explicitly string context and everything else is in list context. For example the arguments incommand arg1 arg2 arg3
orfor i in a b c
, or evenfoo=*; for i in $foo; do ...
. That last one can be either a list or a string depending on whether it is presented quoted or unquoted. And that's without looking at modern, non-POSIX shells like bash or zsh that support actual array syntax like$foo[1]
.
– terdon♦
Mar 2 at 15:17
You can argue just about everything you like, but the concept of "list context" is not used in the POSIX spec, not used in any shell implementation and is not useful. And stop pounding on the list == array thing; did you actually read my aswer? Anybody who knows perl also knows that list or scalar context has nothing to do with arrays, and the context is not some explanatory prop or part of the parser's guts, but some basic part of theperl
's semantics. I suggest that you re-read the "Context" section of the perldata(1) manpage, already linked from my answer.
– Uncle Billy
Mar 2 at 15:53
this isn't about Perl, it's about the shell. The question is asking what is meant by the term list context when used about the shell. Now, perhaps it should not be used, but the fact remains that it is used regardless. Usually as a shorthand for "subject to split+glob". But since even POSIX refers to arguments as "lists", stating that the shell has nothing similar is a bit extreme.
– terdon♦
Mar 2 at 15:58
One reason why using "list context" for "subject to split+glob" is not useful, is because there's no guarantee that a split+glob won't be performed where the shell expects a single word (eg.a='x y'; echo > $a
).
– Uncle Billy
Mar 2 at 16:15
2
@UncleBilly, ok, let me put it this way: I don't find assertions like that very useful in answers here if they are tossed out without any supporting reasoning. A smiley at the end is not much of an argument. On the contrary, it almost hints that the writer has nothing concrete to say on the matter. Also, the question at hand was "what are the contexts", and by saying "you don't need to know that", you're assuming you know the reason for the question better than the questioner themself. And that, in particular, needs supporting arguments.
– ilkkachu
Mar 2 at 19:31
|
show 3 more comments
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
The Perl comparison is not really helpful. That is a rigorously defined term in Perl, with specific meanings that affect how variables are treated in Perl. The term list context isn't an "official" thing in the shell world. It isn't mentioned anywhere in POSIX, for example. Note how the term is actually defined in most of the cases you point out where it is used: the very answer you link to (emphasis mine):
[. . .] on all words in list context (command line arguments or the words the for loops loop on)
(source)
There are two contexts in shell syntax: list context and string context. Field splitting and filename generation only happen in list context, but that's most of the time. Double quotes delimit a string context: the whole double-quoted string is a single string, not to be split.
(source)
So, essentially when you see the term "list context" with respect to a shell, this isn't an official term and is basically just used to mean "not explicitly a string", in other words, subject to split+glob and shell expansion.
POSIX does actually use list (not "list context"), but in two very different ways. It uses is as a specific, defined term to describe sets of commands (emphasis in the original):
2.9.3 Lists
An AND-OR list is a sequence of one or more pipelines separated by the operators "&&" and "||" .
A list is a sequence of one or more AND-OR lists separated by the
operators ';' and '&'.
The operators "&&" and "||" shall have equal precedence and shall be
evaluated with left associativity. For example, both of the following
commands write solely bar to standard output:false && echo foo || echo bar
true || echo foo && echo bar
A ';' separator or a ';' or terminator shall cause the
preceding AND-OR list to be executed sequentially; an '&' separator or
terminator shall cause asynchronous execution of the preceding AND-OR
list.
The term "compound-list" is derived from the grammar in Shell Grammar;
it is equivalent to a sequence of lists, separated by
characters, that can be preceded or followed by an arbitrary number of
characters.
However, the word list, since it is also the term used in everyday English to denote a set of items, is used quite often in the POSIX specs, usually to refer to lists of arguments. For example:
- The shell performs various expansions (separately) on different parts of each command, resulting in a list of pathnames and fields to be treated as a command and arguments; see wordexp.
(Section 2.1)
If a simple command results in a command name and an optional list of arguments, the following actions shall be performed:
(Section 2.9.1)
The for loop shall execute a sequence of commands for each member in a list of items.
[. . .]
First, the list of words following in shall be expanded to generate a list of items.
(Section 2.9.4)
Returning to the top of the loop involves repeating the condition list of a while or until loop or performing the next assignment of a for loop, and re-executing the loop if appropriate.
continue
builtin
All this is to say that when we refer to "list context" with respect to a shell, we are not using a strict, rigorously defined term such as Perl's, we're just referring to things the shell will treat as a list of items. Things that will be expanded, split, globbed etc. So, practically, any non-quoted collection of characters could be considered a list.
add a comment |
The Perl comparison is not really helpful. That is a rigorously defined term in Perl, with specific meanings that affect how variables are treated in Perl. The term list context isn't an "official" thing in the shell world. It isn't mentioned anywhere in POSIX, for example. Note how the term is actually defined in most of the cases you point out where it is used: the very answer you link to (emphasis mine):
[. . .] on all words in list context (command line arguments or the words the for loops loop on)
(source)
There are two contexts in shell syntax: list context and string context. Field splitting and filename generation only happen in list context, but that's most of the time. Double quotes delimit a string context: the whole double-quoted string is a single string, not to be split.
(source)
So, essentially when you see the term "list context" with respect to a shell, this isn't an official term and is basically just used to mean "not explicitly a string", in other words, subject to split+glob and shell expansion.
POSIX does actually use list (not "list context"), but in two very different ways. It uses is as a specific, defined term to describe sets of commands (emphasis in the original):
2.9.3 Lists
An AND-OR list is a sequence of one or more pipelines separated by the operators "&&" and "||" .
A list is a sequence of one or more AND-OR lists separated by the
operators ';' and '&'.
The operators "&&" and "||" shall have equal precedence and shall be
evaluated with left associativity. For example, both of the following
commands write solely bar to standard output:false && echo foo || echo bar
true || echo foo && echo bar
A ';' separator or a ';' or terminator shall cause the
preceding AND-OR list to be executed sequentially; an '&' separator or
terminator shall cause asynchronous execution of the preceding AND-OR
list.
The term "compound-list" is derived from the grammar in Shell Grammar;
it is equivalent to a sequence of lists, separated by
characters, that can be preceded or followed by an arbitrary number of
characters.
However, the word list, since it is also the term used in everyday English to denote a set of items, is used quite often in the POSIX specs, usually to refer to lists of arguments. For example:
- The shell performs various expansions (separately) on different parts of each command, resulting in a list of pathnames and fields to be treated as a command and arguments; see wordexp.
(Section 2.1)
If a simple command results in a command name and an optional list of arguments, the following actions shall be performed:
(Section 2.9.1)
The for loop shall execute a sequence of commands for each member in a list of items.
[. . .]
First, the list of words following in shall be expanded to generate a list of items.
(Section 2.9.4)
Returning to the top of the loop involves repeating the condition list of a while or until loop or performing the next assignment of a for loop, and re-executing the loop if appropriate.
continue
builtin
All this is to say that when we refer to "list context" with respect to a shell, we are not using a strict, rigorously defined term such as Perl's, we're just referring to things the shell will treat as a list of items. Things that will be expanded, split, globbed etc. So, practically, any non-quoted collection of characters could be considered a list.
add a comment |
The Perl comparison is not really helpful. That is a rigorously defined term in Perl, with specific meanings that affect how variables are treated in Perl. The term list context isn't an "official" thing in the shell world. It isn't mentioned anywhere in POSIX, for example. Note how the term is actually defined in most of the cases you point out where it is used: the very answer you link to (emphasis mine):
[. . .] on all words in list context (command line arguments or the words the for loops loop on)
(source)
There are two contexts in shell syntax: list context and string context. Field splitting and filename generation only happen in list context, but that's most of the time. Double quotes delimit a string context: the whole double-quoted string is a single string, not to be split.
(source)
So, essentially when you see the term "list context" with respect to a shell, this isn't an official term and is basically just used to mean "not explicitly a string", in other words, subject to split+glob and shell expansion.
POSIX does actually use list (not "list context"), but in two very different ways. It uses is as a specific, defined term to describe sets of commands (emphasis in the original):
2.9.3 Lists
An AND-OR list is a sequence of one or more pipelines separated by the operators "&&" and "||" .
A list is a sequence of one or more AND-OR lists separated by the
operators ';' and '&'.
The operators "&&" and "||" shall have equal precedence and shall be
evaluated with left associativity. For example, both of the following
commands write solely bar to standard output:false && echo foo || echo bar
true || echo foo && echo bar
A ';' separator or a ';' or terminator shall cause the
preceding AND-OR list to be executed sequentially; an '&' separator or
terminator shall cause asynchronous execution of the preceding AND-OR
list.
The term "compound-list" is derived from the grammar in Shell Grammar;
it is equivalent to a sequence of lists, separated by
characters, that can be preceded or followed by an arbitrary number of
characters.
However, the word list, since it is also the term used in everyday English to denote a set of items, is used quite often in the POSIX specs, usually to refer to lists of arguments. For example:
- The shell performs various expansions (separately) on different parts of each command, resulting in a list of pathnames and fields to be treated as a command and arguments; see wordexp.
(Section 2.1)
If a simple command results in a command name and an optional list of arguments, the following actions shall be performed:
(Section 2.9.1)
The for loop shall execute a sequence of commands for each member in a list of items.
[. . .]
First, the list of words following in shall be expanded to generate a list of items.
(Section 2.9.4)
Returning to the top of the loop involves repeating the condition list of a while or until loop or performing the next assignment of a for loop, and re-executing the loop if appropriate.
continue
builtin
All this is to say that when we refer to "list context" with respect to a shell, we are not using a strict, rigorously defined term such as Perl's, we're just referring to things the shell will treat as a list of items. Things that will be expanded, split, globbed etc. So, practically, any non-quoted collection of characters could be considered a list.
The Perl comparison is not really helpful. That is a rigorously defined term in Perl, with specific meanings that affect how variables are treated in Perl. The term list context isn't an "official" thing in the shell world. It isn't mentioned anywhere in POSIX, for example. Note how the term is actually defined in most of the cases you point out where it is used: the very answer you link to (emphasis mine):
[. . .] on all words in list context (command line arguments or the words the for loops loop on)
(source)
There are two contexts in shell syntax: list context and string context. Field splitting and filename generation only happen in list context, but that's most of the time. Double quotes delimit a string context: the whole double-quoted string is a single string, not to be split.
(source)
So, essentially when you see the term "list context" with respect to a shell, this isn't an official term and is basically just used to mean "not explicitly a string", in other words, subject to split+glob and shell expansion.
POSIX does actually use list (not "list context"), but in two very different ways. It uses is as a specific, defined term to describe sets of commands (emphasis in the original):
2.9.3 Lists
An AND-OR list is a sequence of one or more pipelines separated by the operators "&&" and "||" .
A list is a sequence of one or more AND-OR lists separated by the
operators ';' and '&'.
The operators "&&" and "||" shall have equal precedence and shall be
evaluated with left associativity. For example, both of the following
commands write solely bar to standard output:false && echo foo || echo bar
true || echo foo && echo bar
A ';' separator or a ';' or terminator shall cause the
preceding AND-OR list to be executed sequentially; an '&' separator or
terminator shall cause asynchronous execution of the preceding AND-OR
list.
The term "compound-list" is derived from the grammar in Shell Grammar;
it is equivalent to a sequence of lists, separated by
characters, that can be preceded or followed by an arbitrary number of
characters.
However, the word list, since it is also the term used in everyday English to denote a set of items, is used quite often in the POSIX specs, usually to refer to lists of arguments. For example:
- The shell performs various expansions (separately) on different parts of each command, resulting in a list of pathnames and fields to be treated as a command and arguments; see wordexp.
(Section 2.1)
If a simple command results in a command name and an optional list of arguments, the following actions shall be performed:
(Section 2.9.1)
The for loop shall execute a sequence of commands for each member in a list of items.
[. . .]
First, the list of words following in shall be expanded to generate a list of items.
(Section 2.9.4)
Returning to the top of the loop involves repeating the condition list of a while or until loop or performing the next assignment of a for loop, and re-executing the loop if appropriate.
continue
builtin
All this is to say that when we refer to "list context" with respect to a shell, we are not using a strict, rigorously defined term such as Perl's, we're just referring to things the shell will treat as a list of items. Things that will be expanded, split, globbed etc. So, practically, any non-quoted collection of characters could be considered a list.
edited Mar 2 at 22:46
answered Mar 2 at 16:59
terdon♦terdon
133k32266446
133k32266446
add a comment |
add a comment |
perl
has no "list variables". perl
has scalars, arrays, and hashes, and all of them could be used in a list or scalar context (with the void context as a special kind of scalar context). All subs (functions) in perl
take lists as arguments and return lists. A list behaves differently from an array:
my @v = qw(a b c); my $v = @v; # $v will be 3
my @v = qw(a b c); my $v = @v[0..$#v]; # $v will be 'c'
This is all well documented in the perldata(1) manpage. The name of the operator which checks the type of the current context (wantarray
) is simply a historical accident.
A bourne-like (POSIX) shell has nothing similar, so the question doesn't make much sense; are you wondering where an unquoted variable expansion is not subject to splitting with IFS
and pathname expansion (globbing)? I can think of the right side of a=$var
variable assignment, and the word and patterns of a case
command: case $var in $pat) ...
. A comprehensive list will only be of interest to someone writing another shell implementation, and hopefully they won't base it on stackexchange answers ;-)
How does a shell not have anything similar? You could even argue that only quoted strings are explicitly string context and everything else is in list context. For example the arguments incommand arg1 arg2 arg3
orfor i in a b c
, or evenfoo=*; for i in $foo; do ...
. That last one can be either a list or a string depending on whether it is presented quoted or unquoted. And that's without looking at modern, non-POSIX shells like bash or zsh that support actual array syntax like$foo[1]
.
– terdon♦
Mar 2 at 15:17
You can argue just about everything you like, but the concept of "list context" is not used in the POSIX spec, not used in any shell implementation and is not useful. And stop pounding on the list == array thing; did you actually read my aswer? Anybody who knows perl also knows that list or scalar context has nothing to do with arrays, and the context is not some explanatory prop or part of the parser's guts, but some basic part of theperl
's semantics. I suggest that you re-read the "Context" section of the perldata(1) manpage, already linked from my answer.
– Uncle Billy
Mar 2 at 15:53
this isn't about Perl, it's about the shell. The question is asking what is meant by the term list context when used about the shell. Now, perhaps it should not be used, but the fact remains that it is used regardless. Usually as a shorthand for "subject to split+glob". But since even POSIX refers to arguments as "lists", stating that the shell has nothing similar is a bit extreme.
– terdon♦
Mar 2 at 15:58
One reason why using "list context" for "subject to split+glob" is not useful, is because there's no guarantee that a split+glob won't be performed where the shell expects a single word (eg.a='x y'; echo > $a
).
– Uncle Billy
Mar 2 at 16:15
2
@UncleBilly, ok, let me put it this way: I don't find assertions like that very useful in answers here if they are tossed out without any supporting reasoning. A smiley at the end is not much of an argument. On the contrary, it almost hints that the writer has nothing concrete to say on the matter. Also, the question at hand was "what are the contexts", and by saying "you don't need to know that", you're assuming you know the reason for the question better than the questioner themself. And that, in particular, needs supporting arguments.
– ilkkachu
Mar 2 at 19:31
|
show 3 more comments
perl
has no "list variables". perl
has scalars, arrays, and hashes, and all of them could be used in a list or scalar context (with the void context as a special kind of scalar context). All subs (functions) in perl
take lists as arguments and return lists. A list behaves differently from an array:
my @v = qw(a b c); my $v = @v; # $v will be 3
my @v = qw(a b c); my $v = @v[0..$#v]; # $v will be 'c'
This is all well documented in the perldata(1) manpage. The name of the operator which checks the type of the current context (wantarray
) is simply a historical accident.
A bourne-like (POSIX) shell has nothing similar, so the question doesn't make much sense; are you wondering where an unquoted variable expansion is not subject to splitting with IFS
and pathname expansion (globbing)? I can think of the right side of a=$var
variable assignment, and the word and patterns of a case
command: case $var in $pat) ...
. A comprehensive list will only be of interest to someone writing another shell implementation, and hopefully they won't base it on stackexchange answers ;-)
How does a shell not have anything similar? You could even argue that only quoted strings are explicitly string context and everything else is in list context. For example the arguments incommand arg1 arg2 arg3
orfor i in a b c
, or evenfoo=*; for i in $foo; do ...
. That last one can be either a list or a string depending on whether it is presented quoted or unquoted. And that's without looking at modern, non-POSIX shells like bash or zsh that support actual array syntax like$foo[1]
.
– terdon♦
Mar 2 at 15:17
You can argue just about everything you like, but the concept of "list context" is not used in the POSIX spec, not used in any shell implementation and is not useful. And stop pounding on the list == array thing; did you actually read my aswer? Anybody who knows perl also knows that list or scalar context has nothing to do with arrays, and the context is not some explanatory prop or part of the parser's guts, but some basic part of theperl
's semantics. I suggest that you re-read the "Context" section of the perldata(1) manpage, already linked from my answer.
– Uncle Billy
Mar 2 at 15:53
this isn't about Perl, it's about the shell. The question is asking what is meant by the term list context when used about the shell. Now, perhaps it should not be used, but the fact remains that it is used regardless. Usually as a shorthand for "subject to split+glob". But since even POSIX refers to arguments as "lists", stating that the shell has nothing similar is a bit extreme.
– terdon♦
Mar 2 at 15:58
One reason why using "list context" for "subject to split+glob" is not useful, is because there's no guarantee that a split+glob won't be performed where the shell expects a single word (eg.a='x y'; echo > $a
).
– Uncle Billy
Mar 2 at 16:15
2
@UncleBilly, ok, let me put it this way: I don't find assertions like that very useful in answers here if they are tossed out without any supporting reasoning. A smiley at the end is not much of an argument. On the contrary, it almost hints that the writer has nothing concrete to say on the matter. Also, the question at hand was "what are the contexts", and by saying "you don't need to know that", you're assuming you know the reason for the question better than the questioner themself. And that, in particular, needs supporting arguments.
– ilkkachu
Mar 2 at 19:31
|
show 3 more comments
perl
has no "list variables". perl
has scalars, arrays, and hashes, and all of them could be used in a list or scalar context (with the void context as a special kind of scalar context). All subs (functions) in perl
take lists as arguments and return lists. A list behaves differently from an array:
my @v = qw(a b c); my $v = @v; # $v will be 3
my @v = qw(a b c); my $v = @v[0..$#v]; # $v will be 'c'
This is all well documented in the perldata(1) manpage. The name of the operator which checks the type of the current context (wantarray
) is simply a historical accident.
A bourne-like (POSIX) shell has nothing similar, so the question doesn't make much sense; are you wondering where an unquoted variable expansion is not subject to splitting with IFS
and pathname expansion (globbing)? I can think of the right side of a=$var
variable assignment, and the word and patterns of a case
command: case $var in $pat) ...
. A comprehensive list will only be of interest to someone writing another shell implementation, and hopefully they won't base it on stackexchange answers ;-)
perl
has no "list variables". perl
has scalars, arrays, and hashes, and all of them could be used in a list or scalar context (with the void context as a special kind of scalar context). All subs (functions) in perl
take lists as arguments and return lists. A list behaves differently from an array:
my @v = qw(a b c); my $v = @v; # $v will be 3
my @v = qw(a b c); my $v = @v[0..$#v]; # $v will be 'c'
This is all well documented in the perldata(1) manpage. The name of the operator which checks the type of the current context (wantarray
) is simply a historical accident.
A bourne-like (POSIX) shell has nothing similar, so the question doesn't make much sense; are you wondering where an unquoted variable expansion is not subject to splitting with IFS
and pathname expansion (globbing)? I can think of the right side of a=$var
variable assignment, and the word and patterns of a case
command: case $var in $pat) ...
. A comprehensive list will only be of interest to someone writing another shell implementation, and hopefully they won't base it on stackexchange answers ;-)
edited Mar 2 at 19:19
answered Mar 2 at 8:59
Uncle BillyUncle Billy
9168
9168
How does a shell not have anything similar? You could even argue that only quoted strings are explicitly string context and everything else is in list context. For example the arguments incommand arg1 arg2 arg3
orfor i in a b c
, or evenfoo=*; for i in $foo; do ...
. That last one can be either a list or a string depending on whether it is presented quoted or unquoted. And that's without looking at modern, non-POSIX shells like bash or zsh that support actual array syntax like$foo[1]
.
– terdon♦
Mar 2 at 15:17
You can argue just about everything you like, but the concept of "list context" is not used in the POSIX spec, not used in any shell implementation and is not useful. And stop pounding on the list == array thing; did you actually read my aswer? Anybody who knows perl also knows that list or scalar context has nothing to do with arrays, and the context is not some explanatory prop or part of the parser's guts, but some basic part of theperl
's semantics. I suggest that you re-read the "Context" section of the perldata(1) manpage, already linked from my answer.
– Uncle Billy
Mar 2 at 15:53
this isn't about Perl, it's about the shell. The question is asking what is meant by the term list context when used about the shell. Now, perhaps it should not be used, but the fact remains that it is used regardless. Usually as a shorthand for "subject to split+glob". But since even POSIX refers to arguments as "lists", stating that the shell has nothing similar is a bit extreme.
– terdon♦
Mar 2 at 15:58
One reason why using "list context" for "subject to split+glob" is not useful, is because there's no guarantee that a split+glob won't be performed where the shell expects a single word (eg.a='x y'; echo > $a
).
– Uncle Billy
Mar 2 at 16:15
2
@UncleBilly, ok, let me put it this way: I don't find assertions like that very useful in answers here if they are tossed out without any supporting reasoning. A smiley at the end is not much of an argument. On the contrary, it almost hints that the writer has nothing concrete to say on the matter. Also, the question at hand was "what are the contexts", and by saying "you don't need to know that", you're assuming you know the reason for the question better than the questioner themself. And that, in particular, needs supporting arguments.
– ilkkachu
Mar 2 at 19:31
|
show 3 more comments
How does a shell not have anything similar? You could even argue that only quoted strings are explicitly string context and everything else is in list context. For example the arguments incommand arg1 arg2 arg3
orfor i in a b c
, or evenfoo=*; for i in $foo; do ...
. That last one can be either a list or a string depending on whether it is presented quoted or unquoted. And that's without looking at modern, non-POSIX shells like bash or zsh that support actual array syntax like$foo[1]
.
– terdon♦
Mar 2 at 15:17
You can argue just about everything you like, but the concept of "list context" is not used in the POSIX spec, not used in any shell implementation and is not useful. And stop pounding on the list == array thing; did you actually read my aswer? Anybody who knows perl also knows that list or scalar context has nothing to do with arrays, and the context is not some explanatory prop or part of the parser's guts, but some basic part of theperl
's semantics. I suggest that you re-read the "Context" section of the perldata(1) manpage, already linked from my answer.
– Uncle Billy
Mar 2 at 15:53
this isn't about Perl, it's about the shell. The question is asking what is meant by the term list context when used about the shell. Now, perhaps it should not be used, but the fact remains that it is used regardless. Usually as a shorthand for "subject to split+glob". But since even POSIX refers to arguments as "lists", stating that the shell has nothing similar is a bit extreme.
– terdon♦
Mar 2 at 15:58
One reason why using "list context" for "subject to split+glob" is not useful, is because there's no guarantee that a split+glob won't be performed where the shell expects a single word (eg.a='x y'; echo > $a
).
– Uncle Billy
Mar 2 at 16:15
2
@UncleBilly, ok, let me put it this way: I don't find assertions like that very useful in answers here if they are tossed out without any supporting reasoning. A smiley at the end is not much of an argument. On the contrary, it almost hints that the writer has nothing concrete to say on the matter. Also, the question at hand was "what are the contexts", and by saying "you don't need to know that", you're assuming you know the reason for the question better than the questioner themself. And that, in particular, needs supporting arguments.
– ilkkachu
Mar 2 at 19:31
How does a shell not have anything similar? You could even argue that only quoted strings are explicitly string context and everything else is in list context. For example the arguments in
command arg1 arg2 arg3
or for i in a b c
, or even foo=*; for i in $foo; do ...
. That last one can be either a list or a string depending on whether it is presented quoted or unquoted. And that's without looking at modern, non-POSIX shells like bash or zsh that support actual array syntax like $foo[1]
.– terdon♦
Mar 2 at 15:17
How does a shell not have anything similar? You could even argue that only quoted strings are explicitly string context and everything else is in list context. For example the arguments in
command arg1 arg2 arg3
or for i in a b c
, or even foo=*; for i in $foo; do ...
. That last one can be either a list or a string depending on whether it is presented quoted or unquoted. And that's without looking at modern, non-POSIX shells like bash or zsh that support actual array syntax like $foo[1]
.– terdon♦
Mar 2 at 15:17
You can argue just about everything you like, but the concept of "list context" is not used in the POSIX spec, not used in any shell implementation and is not useful. And stop pounding on the list == array thing; did you actually read my aswer? Anybody who knows perl also knows that list or scalar context has nothing to do with arrays, and the context is not some explanatory prop or part of the parser's guts, but some basic part of the
perl
's semantics. I suggest that you re-read the "Context" section of the perldata(1) manpage, already linked from my answer.– Uncle Billy
Mar 2 at 15:53
You can argue just about everything you like, but the concept of "list context" is not used in the POSIX spec, not used in any shell implementation and is not useful. And stop pounding on the list == array thing; did you actually read my aswer? Anybody who knows perl also knows that list or scalar context has nothing to do with arrays, and the context is not some explanatory prop or part of the parser's guts, but some basic part of the
perl
's semantics. I suggest that you re-read the "Context" section of the perldata(1) manpage, already linked from my answer.– Uncle Billy
Mar 2 at 15:53
this isn't about Perl, it's about the shell. The question is asking what is meant by the term list context when used about the shell. Now, perhaps it should not be used, but the fact remains that it is used regardless. Usually as a shorthand for "subject to split+glob". But since even POSIX refers to arguments as "lists", stating that the shell has nothing similar is a bit extreme.
– terdon♦
Mar 2 at 15:58
this isn't about Perl, it's about the shell. The question is asking what is meant by the term list context when used about the shell. Now, perhaps it should not be used, but the fact remains that it is used regardless. Usually as a shorthand for "subject to split+glob". But since even POSIX refers to arguments as "lists", stating that the shell has nothing similar is a bit extreme.
– terdon♦
Mar 2 at 15:58
One reason why using "list context" for "subject to split+glob" is not useful, is because there's no guarantee that a split+glob won't be performed where the shell expects a single word (eg.
a='x y'; echo > $a
).– Uncle Billy
Mar 2 at 16:15
One reason why using "list context" for "subject to split+glob" is not useful, is because there's no guarantee that a split+glob won't be performed where the shell expects a single word (eg.
a='x y'; echo > $a
).– Uncle Billy
Mar 2 at 16:15
2
2
@UncleBilly, ok, let me put it this way: I don't find assertions like that very useful in answers here if they are tossed out without any supporting reasoning. A smiley at the end is not much of an argument. On the contrary, it almost hints that the writer has nothing concrete to say on the matter. Also, the question at hand was "what are the contexts", and by saying "you don't need to know that", you're assuming you know the reason for the question better than the questioner themself. And that, in particular, needs supporting arguments.
– ilkkachu
Mar 2 at 19:31
@UncleBilly, ok, let me put it this way: I don't find assertions like that very useful in answers here if they are tossed out without any supporting reasoning. A smiley at the end is not much of an argument. On the contrary, it almost hints that the writer has nothing concrete to say on the matter. Also, the question at hand was "what are the contexts", and by saying "you don't need to know that", you're assuming you know the reason for the question better than the questioner themself. And that, in particular, needs supporting arguments.
– ilkkachu
Mar 2 at 19:31
|
show 3 more comments
What answer are you expecting that is not already covered in the Q&A you link to (What is (exactly) "list context" (and "string context")?)?
– Stéphane Chazelas
Mar 2 at 17:45
Possible duplicate of What is (exactly) "list context" (and "string context")?
– ilkkachu
Mar 2 at 20:02