Re: Function definitions

2018-02-26 Thread Chet Ramey
> Chet Ramey writes: > Thank you for an explanation. My takeaway is that most, if not all, > [kaz]sh descendants[1] allow something that IEEE Std 1003.1-2008, 2016 > Edition doesn't. Yep, nothing wrong with that. All shells include extensions beyond what Posix specifies. -- ``The lyf so short,

Re: Function definitions

2018-02-26 Thread moosotc
Pierre Gaston writes: > On Mon, Feb 26, 2018 at 12:45 PM, wrote: > [..snip..] >> >> $ func() true >> bash: syntax error near unexpected token `true' >> >> # Variant#2 >> $ func() { true } >> > ^C >> >> Both forms seem to be valid per [1] and are accepted by (at least) >> ash, zsh and mksh >> >>

Re: Function definitions

2018-02-26 Thread moosotc
Chet Ramey writes: > On 2/26/18 5:45 AM, moos...@gmail.com wrote: > >> Bash Version: 4.4 >> Patch Level: 19 >> Release Status: release >> >> Description: >> Bash rejects valid function definitions >> >> Repeat-By: >> >&g

Re: Function definitions

2018-02-26 Thread Chet Ramey
On 2/26/18 5:45 AM, moos...@gmail.com wrote: > Bash Version: 4.4 > Patch Level: 19 > Release Status: release > > Description: > Bash rejects valid function definitions > > Repeat-By: > > $ func() true > bash: syntax error near unexpected token `true&#

Re: Function definitions

2018-02-26 Thread Pierre Gaston
rentheses -Wno-format-security > uname output: Linux linmac2 4.15.5-1-ARCH #1 SMP PREEMPT Thu Feb 22 > 22:15:20 UTC 2018 x86_64 GNU/Linux > Machine Type: x86_64-unknown-linux-gnu > > Bash Version: 4.4 > Patch Level: 19 > Release Status: release > > Description: >

Function definitions

2018-02-26 Thread moosotc
22:15:20 UTC 2018 x86_64 GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 4.4 Patch Level: 19 Release Status: release Description: Bash rejects valid function definitions Repeat-By: $ func() true bash: syntax error near unexpected token `true' # Variant#2 $ func() { true

Re: CTLESC and CTLNUL not dequoted in exported function definitions

2017-04-09 Thread Chet Ramey
On 4/9/17 6:12 PM, Grisha Levit wrote: > On Sun, Apr 9, 2017 at 5:56 PM, Chet Ramey wrote: >> Thanks for the report and fix. This is the patch where you could have used >> dequote_escapes() ;-) . > > Yup, I realized I'd done the previous one incorrectly shortly after writing > this one, sorry ab

Re: CTLESC and CTLNUL not dequoted in exported function definitions

2017-04-09 Thread Grisha Levit
On Sun, Apr 9, 2017 at 5:56 PM, Chet Ramey wrote: > Thanks for the report and fix. This is the patch where you could have used > dequote_escapes() ;-) . Yup, I realized I'd done the previous one incorrectly shortly after writing this one, sorry about that. But I'm not sure about dequoting the f

Re: CTLESC and CTLNUL not dequoted in exported function definitions

2017-04-09 Thread Chet Ramey
On 4/9/17 12:16 AM, Grisha Levit wrote: > f() { $'\001'; }; export -f f; printenv BASH_FUNC_f%% Thanks for the report and fix. This is the patch where you could have used dequote_escapes() ;-) . Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vi

CTLESC and CTLNUL not dequoted in exported function definitions

2017-04-08 Thread Grisha Levit
For example: $ f() { $'\001'; }; export -f f; printenv BASH_FUNC_f%% | xxd : 2829 207b 2020 2701 0127 0a7d 0a () { '..'.}. I think the following should fix it: diff --git a/variables.c b/variables.c index 87203dac..acac867e 100644 --- a/variables.c +++ b/variables.c @@ -4309,7 +