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 cont
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日(土) 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 t
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 treats
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
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, th
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 cont
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
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 do
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 lean
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 shouldn
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 arg
14 matches
Mail list logo
