List of “list contexts” [closed]

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












-3















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 ?










share|improve this 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















-3















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 ?










share|improve this 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













-3












-3








-3








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 ?










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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

















  • 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










2 Answers
2






active

oldest

votes


















1














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:




  1. 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.






share|improve this answer
































    -1














    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 ;-)






    share|improve this answer

























    • 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











    • 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
















    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    1














    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:




    1. 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.






    share|improve this answer





























      1














      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:




      1. 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.






      share|improve this answer



























        1












        1








        1







        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:




        1. 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.






        share|improve this answer















        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:




        1. 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.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Mar 2 at 22:46

























        answered Mar 2 at 16:59









        terdonterdon

        133k32266446




        133k32266446























            -1














            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 ;-)






            share|improve this answer

























            • 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











            • 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















            -1














            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 ;-)






            share|improve this answer

























            • 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











            • 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













            -1












            -1








            -1







            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 ;-)






            share|improve this answer















            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 ;-)







            share|improve this answer














            share|improve this answer



            share|improve this answer








            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 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











            • 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












            • 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











            • 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


            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Bahrain

            Postfix configuration issue with fips on centos 7; mailgun relay