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 withou
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 b
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 discu
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 fu
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 tho
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 cra
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, s
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 di
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 th
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 co
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 that
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 mak
19 matches
Mail list logo
