Re: Are there any plans for more readable, modern syntaxes for If statements?
On Thu, Mar 12, 2020 at 4:01 PM Eli Schwartz
wrote:
> On 3/12/20 3:00 PM, Vaidas BoQsc wrote:
> > Are there any plans to have alternative, a more modern C or D like
> syntaxes
> > for IF statements, While loop and the like in Bash?
> >
> > Would it be better to just make a new shell and command language similar
> to
> > Bash instead of adding these alternatives?
>
> $ if (true) { echo success; }
> bash: syntax error near unexpected token `{'
> $ alias {=then }=fi
> $ if (true) { echo success; }
> success
>
I do things like:
test && { true_command1;true_command2; : ; } || {
false_command1; false_command2; false_command3; }
Notice the command : (colon) as the last command in the true. The reason
that I put it there is to guarantee that the $? from the series of
"true_commnds" is 0 (aka "true") so that the commands in the || are not
executed.
>
> Is this what you wanted? :p
>
> Personally, I don't really see the problem. I already need to remember
> how to do these in multiple languages, and any of them look weird from
> the context of another language. Can you describe why you feel the bash
> syntax isn't "modern enough"?
>
> What would you propose for backwards compatibility, and what is the
> likelihood people will actually use a different syntax to do the same
> thing, which only works on very new systems? What about POSIX sh scripts?
>
> This seems like a fairly big proposal for something I'm not even seeing
> a definite argument as being actually wrong.
>
> --
> Eli Schwartz
> Arch Linux Bug Wrangler and Trusted User
>
>
--
People in sleeping bags are the soft tacos of the bear world.
Maranatha! <><
John McKown
Re: Are there any plans for more readable, modern syntaxes for If statements?
On 3/13/20 7:59 AM, John McKown wrote:
> I do things like:
>
> test && { true_command1;true_command2; : ; } || {
> false_command1; false_command2; false_command3; }
>
> Notice the command : (colon) as the last command in the true. The reason
> that I put it there is to guarantee that the $? from the series of
> "true_commnds" is 0 (aka "true") so that the commands in the || are not
> executed.
OP: "I want readable, modern syntax for If statements, inspired by C."
You: "Don't use If, use &&, which doesn't look like a C If either."
I'm... not following? I mean, yes, the things which you do are valid
bash syntax, and yes, they seem to do what you want them to do, but I
don't *really* understand how they tie in to the premise of the thread.
In contrast, "abuse parser macros" is a valid if terrible answer to the
question of changing the syntax of a bash feature. Something which is
otherwise not really an option, since 40-year-old languages do not
change fundamental syntax on a whim as though they are, I dunno, perl6.
(I am still mindblown that "I want a modern syntax for " can
possibly lead to "imitate C, which is 50 years old and thus astoundingly
even less modern than the Bourne shell by an entire decade".)
--
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: Are there any plans for more readable, modern syntaxes for If statements?
On 3/13/20 9:27 AM, Eli Schwartz wrote: > (I am still mindblown that "I want a modern syntax for " can > possibly lead to "imitate C, which is 50 years old and thus astoundingly > even less modern than the Bourne shell by an entire decade".) I think the emphasis is on more familiar and more readily recognizable syntax, which I suppose leads to improved readability. -- ``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/ signature.asc Description: OpenPGP digital signature
Re: Are there any plans for more readable, modern syntaxes for If statements?
Date:Fri, 13 Mar 2020 06:59:56 -0500
From:John McKown
Message-ID:
| I do things like:
|
| test && { true_command1;true_command2; : ; } || {
| false_command1; false_command2; false_command3; }
That's OK, and at times I have been tempted that way, but it really is
easier to just do
if
then
true_command1
true_command2
else
false_command1
false_command2
false_command3
fi
Not only do you not need to remember that the ':' command (or "true") is
important, but the exit status of all of this will be whichever of
true_command2 or false_command3 that was executed, which can be
used in other tests later.
The cost of typing a few extra words to make things clearer, and having
the code not look quite so "look what I can do ma" (ie: less "cool") is
worth it to be more clear, and less likely to have bugs.
kre
Re: [PATCH] Define $as_echo and $as_echo_n for backward compatibility.
On 3/13/20 2:22 PM, Zack Weinberg wrote: On Fri, Mar 13, 2020 at 3:13 PM Eric Blake wrote: Unpatched bash 5.0 has a bug where calling $as_echo that contains \ can result in unintended globbing, where the behavior of the expansion is dependent on the contents of the current directory. Nasty! Yikes! And not just unpatched 5.0.0, either... $ bash --version GNU bash, version 5.0.16(1)-release (x86_64-pc-linux-gnu) $ touch %sn; bash -c 'cmd='\''printf %s\n'\''; $cmd test' testn$ I don't see any practical workaround and I surely hope this gets fixed *properly* soon in bash (that discussion you linked to doesn't seem terribly promising, though). You can always make $as_echo expand to the name of a shell function rather than to something that directly contains \, but then we have to worry about making sure the function is defined before anyone that uses $as_echo... I'm wondering if Chet has an update on the matter (adding bug-bash). Repeating some context: https://www.mail-archive.com/austin-group-l@opengroup.org/msg04237.html was a mail to the POSIX folks last June complaining about how bash 5.0's change to allow \ to trigger globbing has unintended consequences, and breaks many existing configure scripts based on the contents of the current directory. I know the Austin Group finally settled on wording that does indeed explicitly state that unpatched bash 5.0 is buggy: https://www.austingroupbugs.net/view.php?id=1234#c4564 " On page 3749 line 128725 section C.2.13.3, add a new paragraph: Patterns are matched against existing filenames and pathnames only when the pattern contains a '*', '?' or '[' character that will be treated as special. This prevents accidental removal of backslash characters in variable expansions where generating a list of matching files is not intended and a (usually oddly named) file with a matching name happens to exist. For example, a shell script that tries to be portable to systems that predate the introduction of functions and printf might use this on POSIX systems: myecho='printf %s\n' to be used as: $myecho args... If %s\n were to be matched against existing files, this would not work if a file called %sn happened to exist. " but I don't know where things stand in bash proper to incorporate the result of that discussion (is it something fixed in unreleased batch, and we are just missing a formal patch to the 5.0 series, or is it still unwritten, or...?). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Re: [PATCH] Define $as_echo and $as_echo_n for backward compatibility.
On 3/13/20 3:32 PM, Eric Blake wrote: > I'm wondering if Chet has an update on the matter (adding bug-bash). > Repeating some context: > https://www.mail-archive.com/austin-group-l@opengroup.org/msg04237.html > was a mail to the POSIX folks last June complaining about how bash 5.0's > change to allow \ to trigger globbing has unintended consequences, and > breaks many existing configure scripts based on the contents of the current > directory. I know the Austin Group finally settled on wording that does > indeed explicitly state that unpatched bash 5.0 is buggy: Not exactly. The decision was that bash-5.0 conformed to the original wording, so the group adopted new wording to standardize the bash-4.4 behavior. Bash-5.1 will revert to the bash-4.4 behavior; the change has been in the devel branch since last October. -- ``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/
