bash dislikes empty functions or flow control bodies
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -Wall
uname output: Linux latitude 5.15.0-2-amd64 #1 SMP Debian 5.15.5-2 (2021-12-18)
x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.1
Patch Level: 16
Release Status: release
Description:
Even if descriptions of situations where this problem occurs may sound
contrived, those situation exist and require me to catch this problem
with additional code:
a: defining an empty function will throw a syntax error
b: defining an empty bodies flow control construct will thow a syntax error
While it may be debatable whether such construct could serve any purpose
(they actually can), perceived lack of purpose doesn't qualify them as
syntactically wrong. They aren't. Would they be syntactically wrong,
the syntax error would continue to exist after adding a harmless
"no operation" equivalent.
You may justifiable ask "so why not simply use the workaround by adding
a no operation equivalent" - answer is that it may not be me in person
creating a function or a flow control construct - the script may do too,
in accordance with input it received (this is the mentioned part where the
description may sound contrived, but isn't). Therefore I must protect the
script at this point from generating empty functions or flow control
constructs.
You may have guessed here that this is going towards some sort of meta
programming, and a fuller view of the reason for reporting the bug can be
obtained at https://github.com/Bushmills/yoda, specifically
at https://github.com/Bushmills/yoda/issues/7
Measures to circumvent the problem can be found in file
https://github.com/Bushmills/yoda/blob/main/yoda at around line 1900
(at this time) on those lines with text "empty function" in the description
Repeat-By:
bar() { ; }
foo() { if true; then ; fi; }
foo() { while :; do ; done; }
Fix:
In cases where this problem arises, I tend to synthesise the closest
approximation of a "no operation" I know about, which is ":":
bar() { :; }
foo() { if true; then :; fi; }
foo() { while :; do :; done; }
Re: bash dislikes empty functions or flow control bodies
On Tue, Jan 18, 2022 at 12:44:46PM +0100, l.bash...@scarydevilmonastery.net wrote: >a: defining an empty function will throw a syntax error >b: defining an empty bodies flow control construct will thow a syntax error This has been the case since the original Bourne shell in the 1970s. The grammar requires a non-empty body in these places. I doubt this is going to change, ever.
Re: bash dislikes empty functions or flow control bodies
Date:Tue, 18 Jan 2022 12:44:46 +0100
From:l.bash...@scarydevilmonastery.net
Message-ID:
<1642506286.659529.80113.nullmai...@latitude.scarydevilmonastery.net>
|a: defining an empty function will throw a syntax error
|b: defining an empty bodies flow control construct will thow a syntax
error
|
| While it may be debatable whether such construct could serve any purpose
| (they actually can), perceived lack of purpose doesn't qualify them as
| syntactically wrong. They aren't.
They are, and always have been. The sh syntax doesn't permit completely
empty statements, and never has.
| Would they be syntactically wrong,
| the syntax error would continue to exist after adding a harmless
| "no operation" equivalent.
That makes no sense at all. If the question were semantics, that
might be a more reasonable thing to say, but it isn't. The syntax
requires words to exist, ':' is a word (it is even a command, which
is more than is required).
If you want the more elementary case, even less than this, try
E=
fn() { $E; }
(though that one is dangerous, as it is the value of E at the time
the function is called which controls what happens, other than the question
of the syntax, not its value at definition time.
if true then $E; fi
while $E; do $E; done
(the latter is an infinite loop, doing nothing, executing nothing, just
the shell using all the available CPU).
kre
Re: bash dislikes empty functions or flow control bodies
18 Ocak 2022 Salı tarihinde yazdı: > [...] those situation exist and require me to catch this problem > with additional code: >a: defining an empty function will throw a syntax error >b: defining an empty bodies flow control construct will thow a syntax > error > Why make it a special case? What's wrong with prepending all of them with `:;'? -- Oğuz
Re: bash dislikes empty functions or flow control bodies
as you may see
e() { ; }
and sadly
e() { }
is simply invalid code, as the others say its by posix sh and mr bash wont
digg it i guess
On Tue, Jan 18, 2022, 12:46 wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat
> -Werror=format-security -Wall
> uname output: Linux latitude 5.15.0-2-amd64 #1 SMP Debian 5.15.5-2
> (2021-12-18) x86_64 GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
>
> Bash Version: 5.1
> Patch Level: 16
> Release Status: release
>
> Description:
> Even if descriptions of situations where this problem occurs may sound
> contrived, those situation exist and require me to catch this problem
> with additional code:
>a: defining an empty function will throw a syntax error
>b: defining an empty bodies flow control construct will thow a syntax
> error
>
> While it may be debatable whether such construct could serve any purpose
> (they actually can), perceived lack of purpose doesn't qualify them as
> syntactically wrong. They aren't. Would they be syntactically wrong,
> the syntax error would continue to exist after adding a harmless
> "no operation" equivalent.
>
> You may justifiable ask "so why not simply use the workaround by adding
> a no operation equivalent" - answer is that it may not be me in person
> creating a function or a flow control construct - the script may do too,
> in accordance with input it received (this is the mentioned part where the
> description may sound contrived, but isn't). Therefore I must protect the
> script at this point from generating empty functions or flow control
> constructs.
>
> You may have guessed here that this is going towards some sort of meta
> programming, and a fuller view of the reason for reporting the bug can be
> obtained at https://github.com/Bushmills/yoda, specifically
> at https://github.com/Bushmills/yoda/issues/7
> Measures to circumvent the problem can be found in file
> https://github.com/Bushmills/yoda/blob/main/yoda at around line 1900
> (at this time) on those lines with text "empty function" in the description
>
>
> Repeat-By:
> bar() { ; }
> foo() { if true; then ; fi; }
> foo() { while :; do ; done; }
>
> Fix:
> In cases where this problem arises, I tend to synthesise the closest
> approximation of a "no operation" I know about, which is ":":
> bar() { :; }
> foo() { if true; then :; fi; }
> foo() { while :; do :; done; }
>
>
>
>
>
Re: bash dislikes empty functions or flow control bodies
what i meant to detail more is
;
where is the cmd.. synatx err, obviously
On Tue, Jan 18, 2022, 17:23 Alex fxmbsw7 Ratchev wrote:
> as you may see
>
> e() { ; }
>
> and sadly
>
> e() { }
>
> is simply invalid code, as the others say its by posix sh and mr bash wont
> digg it i guess
>
> On Tue, Jan 18, 2022, 12:46 wrote:
>
>> Configuration Information [Automatically generated, do not change]:
>> Machine: x86_64
>> OS: linux-gnu
>> Compiler: gcc
>> Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat
>> -Werror=format-security -Wall
>> uname output: Linux latitude 5.15.0-2-amd64 #1 SMP Debian 5.15.5-2
>> (2021-12-18) x86_64 GNU/Linux
>> Machine Type: x86_64-pc-linux-gnu
>>
>> Bash Version: 5.1
>> Patch Level: 16
>> Release Status: release
>>
>> Description:
>> Even if descriptions of situations where this problem occurs may sound
>> contrived, those situation exist and require me to catch this problem
>> with additional code:
>>a: defining an empty function will throw a syntax error
>>b: defining an empty bodies flow control construct will thow a syntax
>> error
>>
>> While it may be debatable whether such construct could serve any purpose
>> (they actually can), perceived lack of purpose doesn't qualify them as
>> syntactically wrong. They aren't. Would they be syntactically wrong,
>> the syntax error would continue to exist after adding a harmless
>> "no operation" equivalent.
>>
>> You may justifiable ask "so why not simply use the workaround by adding
>> a no operation equivalent" - answer is that it may not be me in person
>> creating a function or a flow control construct - the script may do too,
>> in accordance with input it received (this is the mentioned part where the
>> description may sound contrived, but isn't). Therefore I must protect the
>> script at this point from generating empty functions or flow control
>> constructs.
>>
>> You may have guessed here that this is going towards some sort of meta
>> programming, and a fuller view of the reason for reporting the bug can be
>> obtained at https://github.com/Bushmills/yoda, specifically
>> at https://github.com/Bushmills/yoda/issues/7
>> Measures to circumvent the problem can be found in file
>> https://github.com/Bushmills/yoda/blob/main/yoda at around line 1900
>> (at this time) on those lines with text "empty function" in the
>> description
>>
>>
>> Repeat-By:
>> bar() { ; }
>> foo() { if true; then ; fi; }
>> foo() { while :; do ; done; }
>>
>> Fix:
>> In cases where this problem arises, I tend to synthesise the closest
>> approximation of a "no operation" I know about, which is ":":
>> bar() { :; }
>> foo() { if true; then :; fi; }
>> foo() { while :; do :; done; }
>>
>>
>>
>>
>>
bug-bash@gnu.org
Thank you for your consideration and for implementing it. I have
tried the latest devel branch and played with it. I now really like
its behavior. Thank you very much for taking it into consideration.
> I generally make new functionality that's controlled by a separate option
> off by default in releases. I'll do the same here. It's on now so we can
> evaluate its effects. It's hard to get enough people to test alpha and
> beta releases, so who knows what good that will do.
I see, I have not noticed it. Thank you for your explanation and
sorry for the noise.
> It probably won't be in bash-5.2-alpha, since I already froze and tested
> that, but the behavior will be different in the next devel branch push
> after that.
Does that mean it will be in bash-5.2-beta or in bash-5.3? I am
interested in what would be the behavior of the release version of
bash-5.2, which would affect how I will modify my script.
> I still like the simpler explanation: if bash-5.1 expanded `string' to
> something that contained an unescaped `&', replace it. If it expanded to
> something that contained a literal '\&' you'll get a `&'. Backslash-escaped
> backslashes produce a single literal backslash. But allowing double quotes
> to inhibit the replacement is probably better for backwards compatibility,
> even with patsub_replacement off by default.
Is this an explanation that will be put in ChangeLog or in Bash
Reference Manual? I have checked how the quoting of anchor
characters, # and %, in ${var/#prefix} and ${var/%suffix} is explained
in Bash Reference Manual but could not find the mention about the
quoting. For the pattern matching operators, I found an explanation:
> From https://www.gnu.org/software/bash/manual/html_node/Pattern-Matching.html:
>
> [...] The special pattern characters must be quoted if they are to
> be matched literally.
but I feel the detailed behavior is actually not so clear from this
explanation.
--
Koichi
Bash not escaping escape sequences in directory names
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 uname output: Linux computator 5.10.89-1-MANJARO #1 SMP PREEMPT Wed Dec 29 18:09:17 UTC 2021 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.2 Patch Level: !PATCHLEVEL! Release Status: alpha Description: Note: this happens on 5.1 release version as well and probably many other previous versions If a folder that is being displayed as part of the PS1 prompt contains escape sequences, bash will interpret them literally instead of escaping them like zsh does for example. Escape sequences should be fine if directly part of the prompt string and I'm not aware of any way for this to cause issues other than messing with the prompt string in potentially unexpected ways. I would consider this a bug but it's possible there's an intended use case for it. Repeat-By: This is a silly little use case which gives the illusion of a root shell, with the colours changed and the end of the original prompt hidden. [computator ~]$ echo -e "\"\r\x1b[1;31m[computator \x1b[1;36mjoshh\x1b[1;31m]#\x1b[0;37m\x1b[8m\"" | xargs mkdir [computator ~]$ cd ^M^[\[1\;31m\[computator\ ^[\[1\;36mjoshh^[\[1\;31m\]#^[\[0\;37m^[\[8m/ [computator joshh]# Fix: Haven't looked deeply into the bash internals but sanitizing the directory name (along with other user-controlled substitutions in the prompt) should work.
Re: Bash not escaping escape sequences in directory names
i wanna add only few here, one i observed and was discussed a bit that is, also in declare -p, *sometimes* control chars arent escaped in my case they were messing terminal up after -p other case other dude, its output was escaped .. On Wed, Jan 19, 2022, 04:35 Josh Harcombe wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -g -O2 > uname output: Linux computator 5.10.89-1-MANJARO #1 SMP PREEMPT Wed Dec 29 > 18:09:17 UTC 2021 x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 5.2 > Patch Level: !PATCHLEVEL! > Release Status: alpha > > Description: > Note: this happens on 5.1 release version as well and probably many other > previous versions > If a folder that is being displayed as part of the PS1 prompt contains > escape sequences, bash will interpret them literally instead of escaping > them like zsh does for example. Escape sequences should be fine if directly > part of the prompt string and I'm not aware of any way for this to cause > issues other than messing with the prompt string in potentially unexpected > ways. > I would consider this a bug but it's possible there's an intended use case > for it. > > Repeat-By: > This is a silly little use case which gives the illusion of a root shell, > with the colours changed and the end of the original prompt hidden. > > [computator ~]$ echo -e "\"\r\x1b[1;31m[computator > \x1b[1;36mjoshh\x1b[1;31m]#\x1b[0;37m\x1b[8m\"" | xargs mkdir > [computator ~]$ cd ^M^[\[1\;31m\[computator\ > ^[\[1\;36mjoshh^[\[1\;31m\]#^[\[0\;37m^[\[8m/ > [computator joshh]# > > Fix: > Haven't looked deeply into the bash internals but sanitizing the directory > name (along with other user-controlled substitutions in the prompt) should > work. >
