Re: Question on $IFS related differences (Was: Question on $@ vs $@$@)

[Chet Ramey]

On 9/19/24 2:42 AM, Robert Elz wrote:

 Date:Thu, 19 Sep 2024 00:45:44 +0200
 From:Steffen Nurpmeso 
 Message-ID:  <20240918224544.aXWgbZu-@steffen%sdaoden.eu>

   | Woops.  I did not know that, i always separate {} at the beginning
   | an the end, yet not ().

'(' and ')' (parentheses) are operators, '{' and '}' (braces) are not,
nor are '[' and ']' (brackets) - though I have never really understood
bash's rules for '[[' and ']]' in this context.


`[[' and `]]' are reserved words, and `']]' is recognized as a reserved
word if it appears in a command position, with the provision that after a
`[[', what's between the brackets is a conditional command, with its own
grammar rules, so operators like `;' will cause a parse error.

This is similar to `{' and `}'.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Question on $IFS related differences (Was: Question on $@ vs $@$@)

[Steffen Nurpmeso]

Hello Robert.

Thanks again for your extensive answers.

Robert Elz wrote in
 <2675.1726728...@jacaranda.noi.kre.to>:
 |Date:Thu, 19 Sep 2024 00:45:44 +0200
 |From:Steffen Nurpmeso 
 |Message-ID:  <20240918224544.aXWgbZu-@steffen%sdaoden.eu>
 |
 || Woops.  I did not know that, i always separate {} at the beginning
 || an the end, yet not ().
 |
 |'(' and ')' (parentheses) are operators, '{' and '}' (braces) are not,

(And metacharacters that "separate words".  I say that because,
yes, the MUA knows that concept .. but excludes &()<> for several
reasons.)

 |nor are '[' and ']' (brackets) - though I have never really understood
 |bash's rules for '[[' and ']]' in this context.
 |
 |Also note that things tend to change meaning if immediately after
 |an unquoted '$' (or an unsecaped double quoted "$").
 |
 ||   #?255|kent:steffen$ dash -c '{echo du;}'
 ||   dash: 1: Syntax error: "}" unexpected
 |
 |That's because to get the reserved word '{' you first need to
 |get the word '{' and you don't there, the first word is '{echo'
 |which is just another command name, probably unlikely to exist.
 |
 |Hence when the '}' is seen, which is a separate word, as it
 |follows an operator (';') and being in the command word position
 |is recognised as the reserved word '}' you now have a syntax
 |error from the grammar, as a '}' reserved word is only allowed
 |after an opening '{' reserved word, which does not exist here.

Good to know.  I wondered how deep this knowledge is into the
shell programming/hacking community, i think i have--consciously--
never seen this before.  From looking at available things,
nothing.

 |Take a slightly different example
 |
 | $SHELL -c '{echo du>}'
 |
 |That would "work" (if you had a '{echo' command -- binary, script, or
 |function) as '>' is an operator, so there are 3 words and an operator
 |there:
 | '{echo' 'du' > '}'
 |where I put quotes (which change nothing, as there are no reserved words
 |here, the only candidate would be '{echo') around the words, but not the
 |operator (as if there were quotes it would not be an operator).
 |
 |Syntactically that's no different than
 |
 | 'echo' 'foo' > 'file'

I see.

 ||   #?2|kent:steffen$ dash -c '{ echo du;}'
 ||   du
 |
 |There '{' is a word by itself (white space delimited) in the command
 |word position, and so becomes the reserved word '{' (it wouldn't if
 |actually quoted of course, but would still be a separate word because
 |of the following, unquoted, white space).   Then the rest of the syntax
 |is all fine (the same as the first example) and it all works.
 |
 ||   #?0|kent:steffen$ bash -c '{echo du;}'
 |
 |There's no real need to test this kind of thing with different shells,
 |all this is very well understood, and should be the same everywhere
 |(at least provided that none of the disgusting evil that is aliases
 |gets involved.)

We remember your often iterated stance.

 |While I am here, a hint for script writers - always put white space
 |(of some form) around operators (unlike the examples above).  It isn't
 |required by the syntax, but recognising operators always takes the
 |longest sequence of characters that represent any valid operator,
 |and while a sequence (like the '>}' I used above) might not be a valid
 |operator today, who knows what might happen tomorrow?   There are
 |however some combinations (like the ';}') that are so commonly used
 |that no shell author is going to break the world by usurping those,
 |another is '>&-' (and similar for other redirect operators) where
 |the '>&' is an operator, but '-' is just the following word, and
 |'>& -' means just the same -- except for '<<-' which is an operator,
 |and quite different from '<< -'.
 |
 |kre
 --End of <2675.1726728...@jacaranda.noi.kre.to>

Ciao, and greetings from Germany,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[bug #66234] effect of redirecting stderr on checkwinsize undocumented

[anonymous]

URL:
  

 Summary: effect of redirecting stderr on checkwinsize
undocumented
   Group: The GNU Bourne-Again SHell
   Submitter: None
   Submitted: Fri 20 Sep 2024 03:57:42 AM UTC
Category: None
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any


___

Follow-up Comments:


---
Date: Fri 20 Sep 2024 03:57:42 AM UTC By: Anonymous
https://unix.stackexchange.com/a/779423 mentions a bash documentation
omission:

"Bash retrieves the window size from the terminal associated with its standard
error, if any. Redirecting standard error means it can’t do this, so COLUMNS
remains unchanged even if checkwinsize is enabled. I don’t think this is
documented."







___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature

[feature request] Add ".sh" or ".bash" extension to tmpfile generated by `fc`

[shynur .]

`fc` will create a temporary file named something
like "bash-fc.Esf9by", which seldom benefits from
editors that use *suffixes* to infer what syntax
highlighting should be enabled.

(This improvement may not only apply to `fc`.)

--
shynur