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 Aus
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,
> > unfortunately
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 conclus
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
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
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 functio
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 thos
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.
unic
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 c
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 undecid
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 perfect
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 gu
> ...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 als
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
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 argument if it exists.
bash-5.1$ declare -
47 matches
Mail list logo