Date:Wed, 07 Apr 2021 22:24:27 -0400
From:wor...@alum.mit.edu (Dale R. Worley)
Message-ID: <87a6q9ikdg@hobgoblin.ariadne.com>
| "The documentation is the contract between the user and
| the implementer." If something undocumented happens to work, there is
|
Robert Elz writes:
> You're assuming that the manual is a precise specification of what
> is allowed.
Um, of course. "The documentation is the contract between the user and
the implementer." If something undocumented happens to work, there is
no requirement on the implementer to maintain its fu
On 4/5/2021 14:21, Chet Ramey wrote:
This presented an opportunity to marginally simplify the grammar, so it's a
win all around.
The change will be in the next devel branch push.
You have my sincere gratitude. I did not expect so much to come of it.
Chet
--
On 4/5/2021 13:52, Chet Ramey wrote:
On 4/1/21 5:40 PM, Greywolf wrote:
Or do you mean my coding style (which has been valid for over 25 years)?
Hey, if you want to go there, `select' has been in bash with its current
syntax for longer than that. ;-)
(A month over 27 years, if you're curio
On 4/1/21 5:54 PM, Greywolf wrote:
On 4/1/2021 8:57, Chet Ramey wrote:
It's more like `select' doesn't inherit some of the shell's special cases.
select dir in ${d[@]}; do {
break;
} done;
...but select breaks on the "} done;" syntax
Yes, you need a list termi
On 4/1/21 9:23 PM, Dale R. Worley wrote:
Greg Wooledge writes:
It's amazing how many people manage to post their code with NO comments
or explanations of what it's supposed to do, what assumptions are being
made about the inputs, etc. This leaves us to guess.
It seems to be a modern style.
On 4/1/21 5:40 PM, Greywolf wrote:
Or do you mean my coding style (which has been valid for over 25 years)?
Hey, if you want to go there, `select' has been in bash with its current
syntax for longer than that. ;-)
(A month over 27 years, if you're curious.)
--
``The lyf so short, the craft
On 4/5/2021 6:27, Chet Ramey wrote:
On 4/5/21 5:06 AM, Greywolf wrote:
but if you want to go down that track, it's kind of interesting to note
that {} on a single line demands a ; before the }, while () prohibits
it.
This isn't true:
$ ./bash -c '(echo a b c;)'
a b c
but it is the case tha
On 4/5/21 5:06 AM, Greywolf wrote:
the same level of
egregious brokenness as select.
Good god, take a breath.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwr
On 4/5/21 5:06 AM, Greywolf wrote:
but if you want to go down that track, it's kind of interesting to note
that {} on a single line demands a ; before the }, while () prohibits
it.
This isn't true:
$ ./bash -c '(echo a b c;)'
a b c
but it is the case that } is a reserved word, while ) is an
On 4/2/2021 8:21, konsolebox wrote:
That's not a rule but a special compromise. [[ ]] and (( )) are a
form of reserved words themselves just like () and {} as they can be
used multi-line but they aren't allowed to be adjacent to else et al
without a semicolon. [[ ]], (( )), {}, and () are pra
On 4/1/2021 8:57, Chet Ramey wrote:
Yes, you need a list terminator so that `done' is recognized as a reserved
word here. `;' is sufficient. Select doesn't allow the `done' unless it's
in a command position. Some of the other compound commands have special
cases, mostly inherited from the Bourne
On 4/4/2021 23:13, konsolebox wrote:
On Sat, Apr 3, 2021 at 1:09 AM Robert Elz wrote:
| [[ ]] and (( )) are a form of reserved words themselves
Those are bash specials, and I am fairly sure that (( and )) will be
operators, not reserved words (they cannot really be the latter, as ( and
) a
5 Nisan 2021 Pazartesi tarihinde konsolebox yazdı:
>
> The manual itself may be lacking in some places but the syntax here is
> explicit. There's no reason to follow otherwise. These "other methods"
> can only be an implementation mistake or a compromise that's not
> exactly a supported functional
On Sat, Apr 3, 2021 at 1:09 AM Robert Elz wrote:
> | [[ ]] and (( )) are a form of reserved words themselves
>
> Those are bash specials, and I am fairly sure that (( and )) will be
> operators, not reserved words (they cannot really be the latter, as ( and
> ) are operators) and I suspect that
On Mon, Apr 5, 2021 at 12:46 PM Robert Elz wrote:
>
> Date:Sun, 04 Apr 2021 20:27:15 -0400
> From:wor...@alum.mit.edu (Dale R. Worley)
> Message-ID: <87wntha84c@hobgoblin.ariadne.com>
>
>
> | The manual page says
> |
> |if list; then list; [ elif list
Date:Sun, 04 Apr 2021 20:27:15 -0400
From:wor...@alum.mit.edu (Dale R. Worley)
Message-ID: <87wntha84c@hobgoblin.ariadne.com>
| The manual page says
|
|if list; then list; [ elif list; then list; ] ... [ else list; ] fi
|
| so clearly there shoul
Robert Elz writes:
> From:wor...@alum.mit.edu (Dale R. Worley)
>
> | I was going to ask why "else {" works,
>
> The right question would be why '} else' works.
Yeah, typo on my part. The manual page says
if list; then list; [ elif list; then list; ] ... [ else list; ] fi
s
On Thu, Apr 1, 2021 at 7:59 PM Robert Elz wrote:
> Alternatively
> d=( $( ls -d /usr/src/pkg/*/$1 ) )
> or just
> d=( $( printf %s\\n /usr/src/pkg/*/$1 ) )
>
> Just to be sure.Personally I'd do
>
> set -- /usr/src/pkg/*/$1
>
Just the glob is fine in the array assignme
On Fri, Apr 2, 2021 at 2:04 AM Robert Elz wrote:
> chet.ra...@case.edu said:
> | Yes, you need a list terminator so that `done' is recognized as a
> reserved
> | word here. `;' is sufficient. Select doesn't allow the `done' unless
> it's
> | in a command position.
>
> isn't really all that
Date:Fri, 02 Apr 2021 09:02:40 +0200
From:Andreas Schwab
Message-ID: <87o8exp3sf@linux-m68k.org>
| The two case are not really different, they are covered by the same
| rule:
Yes, I knew that ... but they are different, as in the "else {" case
the '{' is in t
Date:Fri, 2 Apr 2021 23:06:40 +0800
From:konsolebox
Message-ID:
| > The right question would be why '} else' works.
|
| This inconsistency should be fixed and prevent people from
| using it wrong. `}; else` should work
Yes.
| but not `} else`
No, that
On Fri, Apr 2, 2021 at 3:03 PM Andreas Schwab wrote:
>
> On Apr 02 2021, Robert Elz wrote:
>
> > Date:Thu, 01 Apr 2021 21:33:31 -0400
> > From:wor...@alum.mit.edu (Dale R. Worley)
> > Message-ID: <874kgpqxlg@hobgoblin.ariadne.com>
> >
> > | I was going to ask why
On Fri, Apr 2, 2021 at 11:41 AM Robert Elz wrote:
>
> Date:Thu, 01 Apr 2021 21:33:31 -0400
> From:wor...@alum.mit.edu (Dale R. Worley)
> Message-ID: <874kgpqxlg@hobgoblin.ariadne.com>
>
> | I was going to ask why "else {" works,
>
> Wrong question. That one is e
On Apr 02 2021, Robert Elz wrote:
> Date:Thu, 01 Apr 2021 21:33:31 -0400
> From:wor...@alum.mit.edu (Dale R. Worley)
> Message-ID: <874kgpqxlg@hobgoblin.ariadne.com>
>
> | I was going to ask why "else {" works,
>
> Wrong question. That one is easy. What follows
Date:Thu, 01 Apr 2021 21:33:31 -0400
From:wor...@alum.mit.edu (Dale R. Worley)
Message-ID: <874kgpqxlg@hobgoblin.ariadne.com>
| I was going to ask why "else {" works,
Wrong question. That one is easy. What follows
'else' is a list and the simplest form of a li
On 4/1/2021 16:03, Robert Elz wrote:
Partly because if you didn't use the braces, the issue wouldn't have arisen.
(And because to most of us it just looks weird, kind of like people
who write functions like f() {( commands to run in a subshell )}
where the braces do nothing useful at all. and sho
Chet Ramey writes:
> Yes, you need a list terminator so that `done' is recognized as a reserved
> word here. `;' is sufficient. Select doesn't allow the `done' unless it's
> in a command position. Some of the other compound commands have special
> cases, mostly inherited from the Bourne shell, to
Greg Wooledge writes:
> It's amazing how many people manage to post their code with NO comments
> or explanations of what it's supposed to do, what assumptions are being
> made about the inputs, etc. This leaves us to guess.
It seems to be a modern style. When I was learning to program, poorly
Date:Thu, 1 Apr 2021 14:40:13 -0700
From:Greywolf
Message-ID: <354ec4df-c24e-d82a-32ad-788a352a5...@starwolf.com>
| Or do you mean my coding style
It was that,
| (which has been valid for over 25 years)?
| (why's everyone bagging on my style and ignoring my or
On Thu, Apr 01, 2021 at 02:54:55PM -0700, Greywolf wrote:
> the requirement
> to have ${var[ix]} instead of honouring $var[ix] with regard to arrays
> is another one).
Before the introduction of arrays, $var[ix] already had a meaning:
the value of the "var" parameter, followed by the 4-character s
Hi, Chet! I've read a lot of your posts long ago, as well!
On 4/1/2021 8:57, Chet Ramey wrote:
It's more like `select' doesn't inherit some of the shell's special cases.
select dir in ${d[@]}; do {
break;
} done;
>>
...but select breaks on the "} done;" syntax
On 4/1/2021 9:58, Robert Elz wrote:
Date:Thu, 1 Apr 2021 11:36:14 -0400
From:Greg Wooledge
Message-ID:
| On Thu, Apr 01, 2021 at 01:36:59AM -0700, greyw...@starwolf.com wrote:
| > The following is valid shell code:
| >
| > d=($(ls /usr/sr
On 4/1/2021 9:16, konsolebox wrote:
On Thu, Apr 1, 2021 at 11:25 PM wrote:
if ((n > 1)); then {
echo "Ambiguous dir specification";
exit 1;
}
else {
dir=${d[0]};
} fi;
The grouping is unnecessary or should be separate
Date:Thu, 1 Apr 2021 13:18:07 -0400
From:Greg Wooledge
Message-ID:
| It's amazing how many people manage to post their code with NO comments
| or explanations of what it's supposed to do, what assumptions are being
| made about the inputs, etc. This leaves us
On 4/1/21 1:18 PM, Greg Wooledge wrote:
> On Thu, Apr 01, 2021 at 11:58:13PM +0700, Robert Elz wrote:
>>
>> | If $1 is not a directory, then you want:
>>
>> It is a directory, or I'd guess, quite likely a pattern chosen
>
> It's amazing how many people manage to post their code with NO comments
On Thu, Apr 01, 2021 at 11:58:13PM +0700, Robert Elz wrote:
>
> | If $1 is not a directory, then you want:
>
> It is a directory, or I'd guess, quite likely a pattern chosen
It's amazing how many people manage to post their code with NO comments
or explanations of what it's supposed to do, wha
Date:Thu, 1 Apr 2021 11:36:14 -0400
From:Greg Wooledge
Message-ID:
| On Thu, Apr 01, 2021 at 01:36:59AM -0700, greyw...@starwolf.com wrote:
| > The following is valid shell code:
| >
| > d=($(ls /usr/src/pkg/*/$1));
|
| Syntactically valid, but seman
On Thu, Apr 1, 2021 at 11:25 PM wrote:
>
> if ((n > 1)); then {
> echo "Ambiguous dir specification";
> exit 1;
> }
> else {
> dir=${d[0]};
> } fi;
The grouping is unnecessary or should be separate from the first class
syntax. B
On 4/1/21 4:36 AM, greyw...@starwolf.com wrote:
Bash Version: 5.1
Patch Level: 4
Release Status: release
Description:
The 'select' directive's syntax does not correspond to the rest of the
shell's syntax.
I am not sure if this is by design; if it is, let me know and I'll go
aw
On Thu, Apr 01, 2021 at 01:36:59AM -0700, greyw...@starwolf.com wrote:
> The following is valid shell code:
>
> d=($(ls /usr/src/pkg/*/$1));
Syntactically valid, but semantically wrong.
If $1 is not a directory, then you want:
d=(/usr/src/pkg/*/"$1")
If $1 is supposed to be a direc
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: netbsd
Compiler: gcc
Compilation CFLAGS: -O2 -I/usr/local/include -D_FORTIFY_SOURCE=2 -I/usr/include
uname output: NetBSD eddie.starwolf.com 9.99.81 NetBSD 9.99.81 (EDDIE) #9: Tue
Mar 23 19:13:25 PDT 2021 gre
42 matches
Mail list logo
