inaccurate documentation for [[:ascii:]]
The documentation for glob character classes is innacurate: > 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 ascii blank cntrl digit graph lower print punct space > upper word xdigit > A character class matches any character belonging to that class. The > word character class matches letters, digits, and the character _. Out of those classes, [:ascii:] and [:word:] are not defined by the POSIX standard. [:word:] is clarified, but [:ascii:] isn't, so it is easy to miss that bash supports [:ascii:] when glancing that part of the documentation. I think it should be clarified that bash supports all the standard character classes, and that [:word:] and [:ascii:] are supported extensions. o/ emanuele6
Re: inaccurate documentation for [[:ascii:]]
does graph mean printable On Tue, May 30, 2023, 14:40 Emanuele Torre wrote: > The documentation for glob character classes is innacurate: > > > 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 ascii blank cntrl digit graph lower print punct space > > upper word xdigit > > A character class matches any character belonging to that class. The > > word character class matches letters, digits, and the character _. > > Out of those classes, [:ascii:] and [:word:] are not defined by the > POSIX standard. > > [:word:] is clarified, but [:ascii:] isn't, so it is easy to miss that > bash supports [:ascii:] when glancing that part of the documentation. > > I think it should be clarified that bash supports all the standard > character classes, and that [:word:] and [:ascii:] are supported > extensions. > > o/ > emanuele6 > >
Re: inaccurate documentation for [[:ascii:]]
On Tue, May 30, 2023 at 02:42:46PM +0200, alex xmb ratchev wrote: > does graph mean printable Sort of. [[:print:]] matches all the printable characters https://en.wikipedia.org/wiki/ASCII#Printable_characters [[:graph:]] matches all the characters that are printable, but not whitespace. In POSIX/C locale, the only difference between [:graph:] and [:print:] is that [:print:] contains space (0x20), and [:graph:] doesn't. o/ emanuele6
Re: inaccurate documentation for [[:ascii:]]
On Tue, May 30, 2023, 14:51 Emanuele Torre wrote: > On Tue, May 30, 2023 at 02:42:46PM +0200, alex xmb ratchev wrote: > > does graph mean printable > > Sort of. [[:print:]] matches all the printable characters > https://en.wikipedia.org/wiki/ASCII#Printable_characters > > [[:graph:]] matches all the characters that are printable, but not > whitespace. > > In POSIX/C locale, the only difference between [:graph:] and [:print:] > is that [:print:] contains space (0x20), and [:graph:] doesn't. > cool answer .. thanks .. o/ > emanuele6 >
Re: Error message: cannot find _struct in shared object
On 5/27/23 12:39 PM, Wiley Young wrote: Bash Version: 5.2 Patch Level: 15 Release Status: release Description: A syntax error on a variable assignment lead to $x being unset when `enable -n "$x" was executed, which produced this error message: ./test.sh: line 22: enable: cannot find _struct in shared object : /usr/bin/bash: undefined symbol: _struct Thanks for the report. dlopen will succeed with a null pathname, but the object will (obviously) not have the required loadable builtin info. Best not to call it with a null pathname at all. Chet -- ``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/
Re: enable builtin bugs in bash 5.2
On 5/27/23 12:44 PM, Emanuele Torre wrote: Since bash 5.2, enable mkdir is equivalent to enable -f mkdir mkdir. But, if you use the -n flag, and mkdir is not a loaded builtin, it will also be equivalent to enable -f mkdir mkdir (so the -n flag is ignored), and the newly loaded foo will be enabled instead of disabled: I think that this is not intended and that, if the -n flag is specified, enable should only try to disable all the loadable builtins named as the argument, and skip, with a warning message, arguments that are not loaded builtins; instead of trying to load (as enabled) arguments, that are not loaded builtins, from files in the current directory and BASH_LOADABLES_PATH as it does now. H. That's not the only option. How about we load it if found but mark it as not enabled? It will still take `enable -d' to delete it. -- ``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/
Re: enable builtin bugs in bash 5.2
On Tue, May 30, 2023, 21:29 Chet Ramey wrote: > On 5/27/23 12:44 PM, Emanuele Torre wrote: > > Since bash 5.2, enable mkdir is equivalent to enable -f mkdir mkdir. > > > > But, if you use the -n flag, and mkdir is not a loaded builtin, it will > > also be equivalent to enable -f mkdir mkdir (so the -n flag is > > ignored), and the newly loaded foo will be enabled instead of disabled: > > > > I think that this is not intended and that, if the -n flag is specified, > > enable should only try to disable all the loadable builtins named as the > > argument, and skip, with a warning message, arguments that are not > > loaded builtins; instead of trying to load (as enabled) arguments, that > > are not loaded builtins, from files in the current directory and > > BASH_LOADABLES_PATH as it does now. > > H. That's not the only option. How about we load it if found but mark > it as not enabled? It will still take `enable -d' to delete it. > all for it bash functionality less limited than posix .. may need a --disable-flag in ./bash greets -- > ``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/ > > >
Re: enable builtin bugs in bash 5.2
Date:Tue, 30 May 2023 15:28:57 -0400 From:Chet Ramey Message-ID: | H. That's not the only option. How about we load it if found but mark | it as not enabled? It will still take `enable -d' to delete it. That wouldn't match the man page, and isn't really rational. The man page says: The -f option means to load the new builtin command name from shared object filename, on systems that support dynamic loading. and If no options are supplied and a name is not a shell builtin, enable will attempt to load name from a shared object named name, as if the command were ``enable -f name name . That's all it says about loading anything. So to load something, either -f needs to be used, or no options be given. Of -n: If -n is used, each name is disabled; otherwise, names are enabled. which is fine, but says nothing about loading anything (but is an option, so if -n is given, we are not in the "no options" case). Nor does it say what happens in that case if name isn't a builtin - so that could either just be ignored (like unset does for vars not set) or be an error, either would be OK. For the behaviour you're suggesting, I'd expect the usage to be enable -fn name which should load name (if it can be found, of course) and disable it (though I'm not sure why anyone would ever want to do that). kre
Re: enable builtin bugs in bash 5.2
On Tue, May 30, 2023, 22:47 Robert Elz wrote: > Date:Tue, 30 May 2023 15:28:57 -0400 > From:Chet Ramey > Message-ID: > > | H. That's not the only option. How about we load it if found but > mark > | it as not enabled? It will still take `enable -d' to delete it. > > That wouldn't match the man page, and isn't really rational. > > The man page says: > > The -f option means to load the new builtin command name from > shared object filename, on systems that support dynamic loading. > > and > > If no options are supplied and a name is not a shell builtin, > enable will attempt to load name from a shared object named name, > as if the command were ``enable -f name name . > > That's all it says about loading anything. So to load something, > either -f needs to be used, or no options be given. > > Of -n: > > If -n is used, each name is disabled; otherwise, names are enabled. > > which is fine, but says nothing about loading anything (but is an option, > so if -n is given, we are not in the "no options" case). Nor does it > say what happens in that case if name isn't a builtin - so that could > either just be ignored (like unset does for vars not set) or be an > error, either would be OK. > > For the behaviour you're suggesting, I'd expect the usage to be > > enable -fn name > > which should load name (if it can be found, of course) and disable > it (though I'm not sure why anyone would ever want to do that). > > kre > sorry .. cant read much text .. i be for newering , i understand mismatches but somewhen u gotta have them all .. peace >
Re: enable builtin bugs in bash 5.2
On Tue, May 30, 2023, 22:55 alex xmb ratchev wrote: > > > On Tue, May 30, 2023, 22:47 Robert Elz wrote: > >> Date:Tue, 30 May 2023 15:28:57 -0400 >> From:Chet Ramey >> Message-ID: >> >> | H. That's not the only option. How about we load it if found but >> mark >> | it as not enabled? It will still take `enable -d' to delete it. >> >> That wouldn't match the man page, and isn't really rational. >> >> The man page says: >> >> The -f option means to load the new builtin command name from >> shared object filename, on systems that support dynamic loading. >> >> and >> >> If no options are supplied and a name is not a shell builtin, >> enable will attempt to load name from a shared object named name, >> as if the command were ``enable -f name name . >> >> That's all it says about loading anything. So to load something, >> either -f needs to be used, or no options be given. >> >> Of -n: >> >> If -n is used, each name is disabled; otherwise, names are enabled. >> >> which is fine, but says nothing about loading anything (but is an option, >> so if -n is given, we are not in the "no options" case). Nor does it >> say what happens in that case if name isn't a builtin - so that could >> either just be ignored (like unset does for vars not set) or be an >> error, either would be OK. >> >> For the behaviour you're suggesting, I'd expect the usage to be >> >> enable -fn name >> >> which should load name (if it can be found, of course) and disable >> it (though I'm not sure why anyone would ever want to do that). >> >> kre >> > > sorry .. cant read much text > .. i be for newering , i understand mismatches > but somewhen u gotta have them all > .. peace > i mean also in a speedy manner >
