On 2/15/23 9:35 PM, Koichi Murase wrote:
P.S. The history in [1] is also interesting. Thanks.
[1] https://lists.gnu.org/archive/html/bug-bash/2023-02/msg00109.html
There are bound to be some good stories over 35 years.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
2023年2月7日(火) 0:59 Koichi Murase :
> By the way, I got a reply from the chair, Andrew, yesterday and could
> get my account in the Austing Group Issue Tracker. I'll later submit
> an issue about the implementation extension of function names with
> slashes.
Sorry for the delay about an issue in
2023年2月7日(火) 0:40 Chet Ramey :
> On 2/4/23 8:02 PM, Koichi Murase wrote:
> > In the previous time that I raised the discussion about ``no-argument
> > return in trap handlers'', I directly posted an email to the mailing
> > list [1]. Fortunately, I got about ten replies but later,
> >
On 2/4/23 8:02 PM, Koichi Murase wrote:
In the previous time that I raised the discussion about ``no-argument
return in trap handlers'', I directly posted an email to the mailing
list [1]. Fortunately, I got about ten replies but later,
unfortunately, it was finally forgotten without any
2023年2月5日(日) 11:12 Robert Elz :
> | In the previous time that I raised the discussion about ``no-argument
> | return in trap handlers'', I directly posted an email to the mailing
> | list [1]. Fortunately, I got about ten replies but later,
> | unfortunately, it was finally forgotten
Date:Sun, 5 Feb 2023 10:02:09 +0900
From:Koichi Murase
Message-ID:
| In the previous time that I raised the discussion about ``no-argument
| return in trap handlers'', I directly posted an email to the mailing
| list [1]. Fortunately, I got about ten replies
2023年2月5日(日) 5:04 Chet Ramey :
> On 2/4/23 4:23 AM, Koichi Murase wrote:
> > As far as I test, there are four implementations that allow defining
> > functions with slashes: Bash and Zsh allow executing the functions
> > (even in their POSIX modes), and mksh and Yash don't allow executing
> > them
2023年2月5日(日) 4:48 Chet Ramey :
> I would be interested in the outcome of a discussion like this on the
> austin-group-l mailing list. I very much doubt this would happen, but
> anything's possible.
Thank you. I'm thinking of opening a discussion there.
In the previous time that I raised the
On 2/4/23 4:23 AM, Koichi Murase wrote:
As far as I test, there are four implementations that allow defining
functions with slashes: Bash and Zsh allow executing the functions
(even in their POSIX modes), and mksh and Yash don't allow executing
them by default.
Yash doesn't allow declaring
On 2/4/23 12:14 PM, Koichi Murase wrote:
Is Bash required to strictly follow the POSIX
standard even for non-POSIX shell scripts that use Bash extensions?
The standard doesn't have a provision for extensions there: shell functions
are only executed if the name does not contain a slash.
I
On 2/4/23 1:38 AM, Oğuz wrote:
It promises POSIX compatibility in POSIX mode, and POSIX says
If the command name contains at least one , the shell shall execute
a non-built-in utility
I think he meant he'll change that for POSIX mode only though
That's right.
--
``The lyf so short, the
2023年2月5日(日) 2:04 Chet Ramey :
>
> On 2/3/23 11:50 PM, Koichi Murase wrote:
> > 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
2023年2月4日(土) 23:58 Oğuz :
> 4 Şubat 2023 Cumartesi tarihinde Koichi Murase yazdı:
>>
> I understand. But I think both bash and zsh should change their behavior to
> disallow the functions in question at least in posix mode, and the standard
> shouldn't allow it, that's what I'm saying
Thanks,
On 2/3/23 11:50 PM, Koichi Murase wrote:
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
4 Şubat 2023 Cumartesi tarihinde Koichi Murase
yazdı:
>
> I understand. But I think both bash and zsh should change their behavior
to disallow the functions in question at least in posix mode, and the
standard shouldn't allow it, that's what I'm saying
--
Oğuz
2023年2月4日(土) 20:43 Oğuz İsmail Uysal :
> On 2/4/23 12:23 PM, Koichi Murase wrote:
> > Changing the behavior related to the function names wouldn't make the
> > behavior of the shell entirely unspecified
> I see, but that's not what you're suggesting. You're suggesting that how
> command search and
2023年2月4日(土) 19:41 Robert Elz :
> [...]
>
> Incidentally, while I understand your desire to make function namespaces
> using '/'
I think this is a separate interesting discussion, so let me reply in
a separate mail.
I guess you understand me, but just to be sure, I'm not desiring to
make it in
2023年2月4日(土) 19:06 Robert Elz :
> I am fairly sure that Chet was speaking about when bash is in posix
> mode, not the default mode behaviour.
Thanks for the comments. If so, the only thing that I would like to
ask is about the possibility of allowing unspecified behaviors which
never affect the
On 2/4/23 12:23 PM, Koichi Murase wrote:
Changing the behavior related to the function names wouldn't make the
behavior of the shell entirely unspecified
I see, but that's not what you're suggesting. You're suggesting that how
command search and execution works be changed to allow functions
Date:Sat, 4 Feb 2023 16:42:08 +0900
From:Koichi Murase
Message-ID:
| * XCU 2.4 ``The following words may be recognized as reserved words on
| some implementations (when none of the characters are quoted), causing
| unspecified results: [[ ]] function select''
Date:Sat, 4 Feb 2023 13:50:26 +0900
From:Koichi Murase
Message-ID:
| 2023å¹´2æ4æ¥(å) 11:12 Chet Ramey :
| > Yep. I'll probably change that.
|
| I disagree with making the change to disallow the execution of
| functions with a slash in their names.
I
2023年2月4日(土) 17:14 Oğuz :
> 4 Şubat 2023 Cumartesi tarihinde Koichi Murase yazdı:
>>
>> Wouldn't it be possible to make the result of defining the function
>> names with slashes unspecified in a similar idea?
>
> If you mean like declaring that a shell's overall behavior be unspecified
I didn't
4 Şubat 2023 Cumartesi tarihinde Koichi Murase
yazdı:
> Wouldn't it be possible to make the result of defining the function
> names with slashes unspecified in a similar idea?
If you mean like declaring that a shell's overall behavior be unspecified
once a function with a name that wouldn't
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
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
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
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,
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
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
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 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 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
2023年1月5日(木) 2:56 Emanuele Torre :
> [...]
>
> It seems that, if an operand of unset is in the form of
> validvariablename[something], the unset builtin invoked without options,
> will only attempt to delete an array element specified by that argument,
> and will not fall back to removing a
2023年2月3日(金) 5:37 Greg Wooledge :
> There's a legitimate reason to support function names that contain *some*
> punctuation characters beyond underscore. Hyphens, periods, colons (single
> or double) -- all fine. Some people like namespace::function names, and
> bash should continue to allow
On Fri, Feb 03, 2023 at 06:38:36AM +0700, Robert Elz wrote:
> which is harmless, unless the shell is badly breaking the command
> execution rules of POSIX (zsh does I believe) but because for any
> shell that follows those rules, it is impossible to invoke a function
> with a '/' in its name.
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 allow function names to contain almost
any
On Thu, Feb 02, 2023 at 03:02:41PM -0500, 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
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 leaning toward "denied".
I'd be
On Thu, Feb 02, 2023 at 04:47:34PM +1000, 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
> ...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't contain any expansions, so
it
Emanuele Torre writes:
> bash-5.1$ a[0] () { echo;}
> bash-5.1$ unset 'a[0]'
Admittedly, I'm running Bash 5.1.0, but the manual page says:
fname () compound-command [redirection]
function fname [()] compound-command [redirection]
...in posix mode, fname must
46 matches
Mail list logo
