Re: unset does not remove functions like a[b] unless -f is specified
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 argument if it exists. Thanks for the report. I agree with this if the array variable doesn't exist. If the array variable exists, and this is simply trying to unset an unset element, it should not attempt to unset a shell function. This is mostly theoretical, anyway. You don't see function names like this in real life. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: unset does not remove functions like a[b] unless -f is specified
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‐ able by that name, a function with that name, if any, is unset. So taking that text strictly, "unset a[0]" should attempt to remove the variable a[0], and if it does not exist, attempt to remove the function a[0] that name. As long as there isn't an existing array variable a. In this theoretical exercise, trying to remove an unset subscript and actually removing a shell function would be worse. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: unset does not remove functions like a[b] unless -f is specified
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't contain any expansions, so
it also shouldn't contain `backticks` or <(command substitutions).
Why not? If you want a shell function name that contains characters that
are special to word expansions, quote them on invocation:
`backtick` ()
{
echo $FUNCNAME
}
\`backtick\`
They're just nonsensical.
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.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: unset does not remove functions like a[b] unless -f is specified
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 leaning toward "denied". I'd be perfectly fine if function names had to be "names", and my memory is that old versions of Bash enforced that. That is the opposite of how it went. From the beginning, bash had very few limitations on function names (dollar sign, unquoted, all digits, etc.). It was when I added posix mode changes between bash-1.13 and bash-1.14 that the restrictions on names came in. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: unset does not remove functions like a[b] unless -f is specified
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 doesn't import function names containing slashes from the environment. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: unset does not remove functions like a[b] unless -f is specified
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 allow function names to contain almost any character at all. See below. There's no good reason to reduce the possible function namespace below what's allowed for external commands. | A case might be made that slashes should also be disallowed, That (and \0) are the exceptions. But not because: | because it allows exported function names like /bin/echo to be | inherited by a script, Bash doesn't import functions with slashes in their names. 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. Bash doesn't allow them to be created in POSIX mode. 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. The rules for executing commands require that any command name with a '/' in it simply be handed to exec*() as is - it can never be a built in command, can never be a function, and never searches PATH. It's kind of redundant, since POSIX doesn't allow the application to have function names that contain slashes in the first place. That POSIX explicitly says the name space for function names is allowed to be extended is a strong hint that it ought to be - and definitely means that this is not an extension that needs to be disabled in "posix mode". Earlier versions of the standard required the function name to be a NAME, while acknowledging extensions were possible. I don't think it changed to be an application requirement until 2001, at which point it wasn't useful to change. After all, at that point we were almost ten years in with posix mode! Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: unset does not remove functions like a[b] unless -f is specified
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
haven't applied reverse patches of 1.14.*), it already supports a
slash in function names outside the `-o posix' mode:
$ bash-1.14 -c 'func/name() { echo a; }; func/name'
a
so the support for the function names has a history of mostly thirty years.
Bash has allowed slashes in function names since the beginning: 1988.
I can see a case for posix mode disallowing execution of functions whose
names contain a slash, but default mode has always allowed it.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: unset does not remove functions like a[b] unless -f is specified
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 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.
| It's kind of redundant, since POSIX doesn't allow the application to have
| function names that contain slashes in the first place.
Well, kind of - a portable application cannot assume that function names
that are not "name"s will work - but the shell is allowed to support more
than that:
An implementation may allow other characters in a function name
as an extension.
and if the application knows that the implementation permits it, is able to
make use of whatever extra characters the implementation allows. The
script would not be portable, or not to all conforming shells, but that
might not matter.
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. In posix mode (any shell
that conforms) has no wriggle room on that one. ./a.out is required
to execute the "a.out" file in the current directory, and the existence
of a function named "./a.out" isn't permitted to stop it, even if the
implementation allows a function of that name to be defined. Scripts
should be able to rely upon that.
| Earlier versions of the standard required the function name to be a NAME,
| while acknowledging extensions were possible.
It still does. There are a few places in the standard where extensions
are strongly hinted at as being possible - and many other places where
various implementations have extended things that the standard doesn't
even hint at (eg: the ${var/...} extensions that exist - POSIX doesn't
even suggest that those added operators are possible, but if not defined
to mean something they would just be errors - so implementations can add
that kind of thing safely (no conforming application will accidentally be
using that syntax expecting something else to happen).
The point of all of this is that if all shells started adopting a MUCH
wider character set for function names, perhaps the next revision of the
standard (not the one coming next year or whenever - but the one after
that, Issue 9, perhaps in the mid or late 2030's [I am guessing]) might
be able to alter the definition so the function name is just a word, rather
than a NAME, ie: the same syntax as a command-name in a simple command.
kre
Re: unset does not remove functions like a[b] unless -f is specified
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, the '<' would be an operator (redirection operator) (or with bash extensions, <( is probably the operator there - doesn't matter here) - operators cannot be part of a word, that violates the tokenisation rules. But if quoted, they're just characters. In that case they would form a word. I'm not sure why bash prohibits quotes around function names, to allow names containing operators, and white space, as well as the expansion characters ($ ` * ? and [), and the quote characters themselves. Is there something about the implementation which would fail if that rule was removed? kre
Re: unset does not remove functions like a[b] unless -f is specified
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 of redundant, since POSIX doesn't allow the application to have | function names that contain slashes in the first place. Well, kind of - a portable application cannot assume that function names that are not "name"s will work - but the shell is allowed to support more than that: An implementation may allow other characters in a function name as an extension. and if the application knows that the implementation permits it, Sure. There's just no portable way to find out. You have to rely on extra- standard mechanisms. 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. | Earlier versions of the standard required the function name to be a NAME, | while acknowledging extensions were possible. It still does. In a different way. The original versions offered no wiggle room: "fname ... shall be a name." Post-2001 versions shifted the burden: "the application shall ensure that it is a name." Implementations could offer other characters, but the standard in place when I added posix mode required a function name to be a name, so that's what bash enforced. This is 1992 or thereabouts, remember. The point of all of this is that if all shells started adopting a MUCH wider character set for function names, perhaps the next revision of the standard (not the one coming next year or whenever - but the one after that, Issue 9, perhaps in the mid or late 2030's [I am guessing]) might be able to alter the definition so the function name is just a word, rather than a NAME, ie: the same syntax as a command-name in a simple command. "But a man's reach should exceed his grasp, or what's a heaven for?" Bash already allows that much wider character set, with a couple of documented exceptions that have been around since 1988. It seems like most shells don't, according to your previous message. It's time for them to catch up. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: unset does not remove functions like a[b] unless -f is specified
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 the < like a $ in this case. If unquoted, the '<' would be an operator (redirection operator) (or with bash extensions, <( is probably the operator there - doesn't matter here) - operators cannot be part of a word, that violates the tokenisation rules. It's not an operator. It's a word expansion, just like $(). It doesn't delimit words, and it doesn't require quoting. It's not documented to be one of the disallowed characters (character sequence in this case), and probably should not be. I'm not sure why bash prohibits quotes around function names, to allow names containing operators, and white space, as well as the expansion characters ($ ` * ? and [), and the quote characters themselves. It's probably inherited from reserved words. The reasons have been lost to time. Is there something about the implementation which would fail if that rule was removed? Probably not. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: unset does not remove functions like a[b] unless -f is specified
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 to disallow the execution of functions with a slash in their names. First, this breaks backward compatibility. As I have mentioned in another reply, I'm using slashes in function names everywhere in my Bash scripts (of course, which is not the POSIX shell scripts). As I am using slashes for namespacing, almost all the shell functions in my shell library contain slashes in their function names. This might be a personal thing, but I'm really unhappy if this incompatible change is made. Anyway, I don't think there is a good reason to break backward compatibility for the feature that Bash had from the very beginning. Also, if a script is intended to be a portable POSIX-shell script, the script will never attempt to define a shell function that has slashes in its function name. So, even though Bash runs the functions whose names contain slashes, it doesn't change any behavior of the portable POSIX-shell scripts. The functions that have slashes in their names are Bash extensions. Is Bash required to strictly follow the POSIX standard even for non-POSIX shell scripts that use Bash extensions? For compatibility among shell implementations, Zsh also seems to support the execution of functions with a slash in their names, though Yash doesn't seem to attempt to run such functions. Also, it seems no one has pointed out this incompatibility with the standard for more than thirty years, which implies that no one including the POSIX people hasn't paid much attention to these detailed behavioral differences. I feel this is just an issue of the wording of the standard and its interpretation. Is it impossible that this is explicitly marked as `unspecified' in the standard? -- Koichi
Re: unset does not remove functions like a[b] unless -f is specified
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 execute a non-built-in utility I think he meant he'll change that for POSIX mode only though -- Oğuz
Re: unset does not remove functions like a[b] unless -f is specified
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 contains at least one , the shell shall execute a
> >non-built-in utility
Yes, I've also checked the POSIX wording, but should that rule also be
applied to the extensions? That is the question ``Is Bash required to
strictly follow ... that use Bash extensions?".
There are similar cases that the interpretation of the command names
can be changed from what is defined by POSIX. The `function' keyword
introduces a special syntax for the function definition, and `[[' also
introduces a special syntax, but these may be interpreted as command
names according to the standard. Also, array assignments `a[i]=x' may
be interpreted as a command name. Actually, for these cases, the POSIX
standard prepares loopholes of marking them `unspecified' as
* 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''
* XCU 2.10.2/7b ``If all the characters in the TOKEN preceding the
first such form a valid name (see XBD Name), the token
ASSIGNMENT_WORD shall be returned. Otherwise, it is unspecified
whether rule 1 is applied or ASSIGNMENT_WORD is returned.''
Wouldn't it be possible to make the result of defining the function
names with slashes unspecified in a similar idea? That is what I was
thinking when I asked the question in the last sentence of my previous
reply.
> I think he meant he'll change that for POSIX mode only though
That makes more sense, but if I'm allowed to express my preference, I
would still be happy if the behavior for the functions with slashes in
their names is kept even in the POSIX mode just as ``function name {
list; }'' and ``[[ expr ]]'' is allowed even in the POSIX mode of
Bash.
I'm maintaining a framework that can be used from the users'
environment where the shell options are not under the control of the
framework, and the POSIX mode might be turned on by the users. The
framework has provided support even with the POSIX mode because it can
temporarily turn off the POSIX mode only during its loading time. This
is possible because Bash has allowed calls of the already-defined
functions with non-POSIX names even in the POSIX mode.
I understand that the reason that Bash can support ``function name {
list; }'' and ``[[ expr ]]'' even in the POSIX mode is that the POSIX
prepares the specific loopholes for them, but I guess the background
of the loopholes is that these are accepted extensions. So, I would be
happy if there would be room for the standard to change the wording of
XCU 2.9.1 so that « the result is unspecified when there is a matching
function name with slashes when the implementation extends the
function namespace as allowed in XCU 2.9.5/para3 ».
Zsh in the ``emulate sh'' mode also seems to continue to support the
calls of functions with slashes in their names. Even if we would
forget about the existing implementations and would make a standard
from scratch, I tend to think it would be reasonable to allow the
calls of functions with slashes in their names as far as defining such
functions is allowed.
--
Koichi
