On 2/2/23 1:47 AM, Martin D Kealey wrote:
...in posix mode, fname must be a valid shell name and may not be the name
of one of the POSIX special builtins.
In default mode, a function name can be any unquoted shell word that does
not contain $. ...
I'm guessing the intention is that it
On 2/2/23 3:02 PM, Dale R. Worley wrote:
Greg Wooledge writes:
I'd be totally OK with restricting the function namespace a bit more.
Function names should not be allowed to contain backticks or less-than
or greater-than signs (in my opinion). I'm still undecided about
parentheses, but I'm
On 1/31/23 2:33 PM, Dale R. Worley wrote:
So it does seem that a function named "a[0]" is valid in default mode.
Of course it is.
unset [-fv] [-n] [name ...]
... If no options are
supplied, each name refers to a variable; if there is no vari‐
On 1/4/23 12:56 PM, Emanuele Torre wrote:
The unset builtin, when invoked without an option, should first try to
unset the variable (or array element) specified by its arguments, and
then fall back to trying to remove the function definition for the
function that has the name specified by the
On 2/2/23 3:36 PM, Greg Wooledge wrote:
A case might be made that slashes should also be disallowed, because it
allows exported function names like /bin/echo to be inherited by a
script, potentially causing all kinds of odd behavior. But that's a
different battle.
As a matter of fact, bash
On 2/3/23 1:17 AM, Koichi Murase wrote:
It would break all my scripts, which use slashes for the
pseudo-namespacing, so I'm personally unhappy if the function names
would be restricted at this time. As far as I try the oldest Bash
version 1.14.7 available at < https://ftp.gnu.org/gnu/bash/ > (I
On 2/2/23 6:38 PM, Robert Elz wrote:
Date:Thu, 2 Feb 2023 15:36:30 -0500
From:Greg Wooledge
Message-ID:
| There's a legitimate reason to support function names that contain *some*
| punctuation characters beyond underscore.
There is a very good reason to
Date:Fri, 3 Feb 2023 15:55:34 -0500
From:Chet Ramey
Message-ID:
| There's no good reason to reduce the possible function namespace below
| what's allowed for external commands.
Agreed.
| However, bash allows,
| and has always allowed, function names to
Date:Fri, 3 Feb 2023 11:22:23 -0500
From:Chet Ramey
Message-ID:
| > Hmm, I wonder whether <(:) could be a valid function name,
| > if it expands to something like /dev/fd/63?
|
| Bash doesn't allow that; it treats the < like a $ in this case.
If unquoted,
2023年2月4日(土) 11:12 Chet Ramey :
> > But a posix conforming shell will still never execute a function that
> > has a '/' in its name, even if it has extended the character set for
> > function names, and allows '/' in that set.
>
> Yep. I'll probably change that.
I disagree with making the change
On 2/3/23 7:01 PM, Robert Elz wrote:
Date:Fri, 3 Feb 2023 11:22:23 -0500
From:Chet Ramey
Message-ID:
| > Hmm, I wonder whether <(:) could be a valid function name,
| > if it expands to something like /dev/fd/63?
|
| Bash doesn't allow that; it
4 Şubat 2023 Cumartesi tarihinde Koichi Murase
yazdı:
> Is Bash required to strictly follow the POSIX
> standard even for non-POSIX shell scripts that use Bash extensions?
It promises POSIX compatibility in POSIX mode, and POSIX says
>If the command name contains at least one , the shell shall
2023年2月4日(土) 15:38 Oğuz :
> 4 Şubat 2023 Cumartesi tarihinde Koichi Murase yazdı:
>>
>> Is Bash required to strictly follow the POSIX
>> standard even for non-POSIX shell scripts that use Bash extensions?
>
> It promises POSIX compatibility in POSIX mode, and POSIX says
> >If the command name
On 2/3/23 6:55 PM, Robert Elz wrote:
| However, bash allows,
| and has always allowed, function names to contain slashes when running in
| default mode. This has been true for over 30 years.
I never knew that, and I've been using bash probably all of that time.
OK.
| It's kind
14 matches
Mail list logo
