On Mon, Nov 25, 2024 at 9:48 PM Martin D Kealey wrote:
>
> On Mon, 25 Nov 2024 at 22:22, Zachary Santer wrote:
>>
>> People can write bad code in any language.
>
> Yeah, that includes English, apparently.
>
> The problem is that the Shell makes it hard to write good code and easy to
> write bad
On Tue, Nov 26, 2024 at 12:47:48PM +1000, Martin D Kealey wrote:
...
> The problem is that the Shell makes it hard to write good code and easy to
> write bad code.
>
> (“No programmer would ever be lazy.” Yeah, right. I ran a tutorial on Bash
> at the 2015 LCA in Auckland, and was abashed (pun in
Writing's more difficult than reading, and writing can be expensive.
Synoptic reading, traditionally, is considered the "highest form" of
reading (according to "How to Read a Book") (Hate mail to them, please, not
me.). Writing from some definable point of view is inevitable.
It might be worthwhi
On Mon, 25 Nov 2024 at 22:22, Zachary Santer wrote:
> On Mon, Nov 25, 2024 at 5:07 AM Martin D Kealey
> wrote:
> >
> > How about this for a concrete proposal: let's split the current man page
> > into a page per topic. The following list is alphabetical, though I
> should
> > probably put it in
On 11/25/24 3:18 PM, Lawrence Velázquez wrote:
I'm not opposed to modest clarification, but mentioning "[[:class:]]"
would be misleading because it would give the impression that
character class expressions must occur alone within their bracket
expressions.
I added an example illustrating thi
On Mon, Nov 25, 2024, at 3:18 PM, Lawrence Velázquez wrote:
> $ unset IFS
Sorry, this is from an earlier draft in which I used $* to generate
the string of space-separated letters. I just forgot to remove it;
it isn't relevant for the example I actually sent.
--
vq
On 11/25/24 2:18 PM, marcel.plch wrote:
On Monday, November 25th, 2024 at 5:49 PM, Chet Ramey
wrote:
On 11/23/24 9:29 PM, marcel.plch via Bug reports for the GNU Bourne Again
SHell wrote:
Thank you for clarifictaion.
Maybe adding an extra clarification to the bash manpage
in the Patte
On Mon, Nov 25, 2024, at 2:18 PM, marcel.plch via Bug reports for
the GNU Bourne Again SHell wrote:
> Not in one place the pattern "[[:space:]]" is mentioned.
Why should the "space" character class be called out in particular?
It's not special.
> If adding just one sentence containing "[[:space:]
e:]]" to
clarify the section a tiny bit more, I think that
it is well worth it.
[0] - https://stackoverflow.com/questions/79219041/bash-string-substitution-bug
--
Dormouse
publickey - marcel.plch@proton.me - 0x1094A451.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
On 11/23/24 9:29 PM, marcel.plch via Bug reports for the GNU Bourne Again
SHell wrote:
Thank you for clarifictaion.
Maybe adding an extra clarification to the bash manpage
in the Pattern Matching section would be a good idea?
I can add some clarifying text, but I figure that the since this t
On Mon, Nov 25, 2024 at 5:07 AM Martin D Kealey wrote:
>
> How about this for a concrete proposal: let's split the current man page
> into a page per topic. The following list is alphabetical, though I should
> probably put it in some kind of narrative order.
>
>[...]
You mostly just reinvent
On Mon, 25 Nov 2024 at 00:21, Oğuz wrote:
> In another document, not the manual.
>
If my suggested addition does not belong in the manual, then neither does
*any* mention of "character class", nor indeed the entire existing
description of "regular expression". Please provide a patch that removes
On Sun, Nov 24, 2024 at 10:51:43PM +1000, Martin D Kealey wrote:
> On Sun, 24 Nov 2024 at 18:05, Andreas Kähäri wrote:
>
> > I think the manual is quite clear:
> >
> > Within [ and ], character classes can be specified
> > using the syntax [:class:], where class is one of the
> >
On Sun, Nov 24, 2024 at 02:58:45PM -0500, Lawrence Velázquez wrote:
> On Sun, Nov 24, 2024, at 10:08 AM, Andreas Kähäri wrote:
> > On Sun, Nov 24, 2024 at 09:31:42AM -0500, Greg Wooledge wrote:
> >> Similar cases exist elsewhere within the man page. For example, if you
> >> search for $! or $$ you
On Mon, 25 Nov 2024 at 01:08, Andreas Kähäri wrote:
> I don't agree that the special parameters should be written as $! etc.
> since those are their _values_ when used in the shell (exactness is a
> virtue in a manual).
>
In a *printed* manual I would agree with you, but in a man page where the
On Sun, Nov 24, 2024, at 10:08 AM, Andreas Kähäri wrote:
> On Sun, Nov 24, 2024 at 09:31:42AM -0500, Greg Wooledge wrote:
>> Similar cases exist elsewhere within the man page. For example, if you
>> search for $! or $$ you will not find the section that documents them.
>> You would have to know th
On Sun, Nov 24, 2024 at 7:52 AM Martin D Kealey wrote:
>
> When one already knows how it works, that's obvious, and it's hard to see
> how it could mean anything else.
>
> When one *doesn't *already know how it works, “using the syntax *[:class:]*”
> could just as easily mean using *:class:* insid
On Sun, Nov 24, 2024 at 09:31:42AM -0500, Greg Wooledge wrote:
> On Sun, Nov 24, 2024 at 22:51:43 +1000, Martin D Kealey wrote:
> > When one *doesn't *already know how it works, “using the syntax *[:class:]*”
> > could just as easily mean using *:class:* inside *[…]*.
>
> Yeah, good luck with that
On Sun, Nov 24, 2024 at 22:51:43 +1000, Martin D Kealey wrote:
> When one *doesn't *already know how it works, “using the syntax *[:class:]*”
> could just as easily mean using *:class:* inside *[…]*.
Yeah, good luck with that. I predict that if you offer a patch to
make this clearer, there will b
On Sunday, November 24, 2024, Martin D Kealey
wrote:
>
> This REALLY needs to be driven home both in the explanation and with
> examples, preferably with at least one that illustrates using more than one
> character class inside one match group.
>
In another document, not the manual.
--
Oğuz
On Sun, 24 Nov 2024 at 18:05, Andreas Kähäri wrote:
> I think the manual is quite clear:
>
> Within [ and ], character classes can be specified
> using the syntax [:class:], where class is one of the
> following classes defined in the POSIX standard:
> alnum alpha
On Sun, Nov 24, 2024 at 02:29:01AM +, marcel.plch via Bug reports for the
GNU Bourne Again SHell wrote:
> On Sunday, November 24th, 2024 at 3:05 AM, Lawrence Velázquez
> wrote:
>
> > On Sat, Nov 23, 2024, at 7:11 PM, marcel.plch via Bug reports for the GNU
> > Bourne Again SHell wrote:
> >
On Sunday, November 24th, 2024 at 3:05 AM, Lawrence Velázquez
wrote:
> On Sat, Nov 23, 2024, at 7:11 PM, marcel.plch via Bug reports for the GNU
> Bourne Again SHell wrote:
>
> > I am trying to do some file management in bash and I have strings in
> > this format:
> >
> > 1 dir/hello.txt
>
On Sat, Nov 23, 2024, at 7:11 PM, marcel.plch via Bug reports for the GNU
Bourne Again SHell wrote:
> I am trying to do some file management in bash and I have strings in
> this format:
>
> 1 dir/hello.txt
> 2 dir2/bar.jpg
>
> When I run this substitution:
> ${FOO/[:space:]*/Hello}
> I get this r
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt
-fexceptions -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security
-fstack-clash-protection -fcf-p
Thanks a lot!
:-)
Chet Ramey wrote:
Bernd Eggink wrote:
Chet Ramey schrieb:
Bernd Eggink wrote:
prompt: CLUSTER='1 2'; echo ${CLUSTER/${HOSTNAME/.*}}
output: -bash: ${HOSTNAME: bad substitution
Apparently bash interprets this as ${parameter
either
VALUE=host1.blah.com
echo ${VALUE//.*}
or
echo ${VALUE/.*}
is accepted by Bash and works exactly as I would expect it - meaning
it correctly produces "host1" - removes the dot (dot is just a character
- we are not
in the regular expression world) - so the dot and the tr
Bernd Eggink wrote:
Chet Ramey schrieb:
Bernd Eggink wrote:
prompt: CLUSTER='1 2'; echo ${CLUSTER/${HOSTNAME/.*}}
output: -bash: ${HOSTNAME: bad substitution
Apparently bash interprets this as ${parameter/pattern/string}
where pattern = ${HOSTNAME. Looks like a bug;
Chet Ramey schrieb:
Bernd Eggink wrote:
prompt: CLUSTER='1 2'; echo ${CLUSTER/${HOSTNAME/.*}}
output: -bash: ${HOSTNAME: bad substitution
Apparently bash interprets this as ${parameter/pattern/string}
where pattern = ${HOSTNAME. Looks like a bug; it works in ksh.
Th
Bernd Eggink wrote:
prompt: CLUSTER='1 2'; echo ${CLUSTER/${HOSTNAME/.*}}
output: -bash: ${HOSTNAME: bad substitution
Apparently bash interprets this as ${parameter/pattern/string}
where pattern = ${HOSTNAME. Looks like a bug; it works in ksh.
That is, in fact, what
Dmitry V Golovashkin schrieb:
Description:
unexpected bad substitution:
enter the following simple list:
prompt: CLUSTER='1 2'; echo ${CLUSTER/${HOSTNAME%%.*}}
output: 1 2
the idea of the above line is to remove short HOSTNAME (without the
trailing domain)
fro
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: x86_64-redhat-linux-gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDI
32 matches
Mail list logo
