bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: unset does not remove functions like a[b] unless -f is specified


From: Koichi Murase
Subject: Re: unset does not remove functions like a[b] unless -f is specified
Date: Sun, 5 Feb 2023 10:27:10 +0900

2023年2月5日(日) 5:04 Chet Ramey <chet.ramey@case.edu>:
> 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 functions with slashes in their names.

The version I tried seems to allow it with the construct ``function
name { list; }'':

$ yash --version
Yet another shell, version 2.53
Copyright (C) 2007-2022 magicant
This is free software licensed under GNU GPL version 2.
You can modify and redistribute it, but there is NO WARRANTY.
$
$ yash -c 'function a/b/c { echo hello; }; typeset -f'
function a/b/c()
{
   echo hello
}

although it doesn't with the POSIX function declaration:

$ yash -c 'a/b/c() { echo hello; }; typeset -f'
yash -c:1: syntax error: invalid function name

> > If a non-POSIX (ksh-like) shell script defines any functions with
> > names that have a slash and conflict with the real executable files
> > the script wants to run, the script should be responsible for any
> > problems caused by it. If the script wants to run the executable, the
> > script obviously shouldn't define the function with the same name as
> > the executable path.
>
> This breaks down in the face of function libraries like the one you've
> built. Your statement is correct if the script knows all the functions
> it has defined at the time it goes to execute the file in question.

Hmm, you are right. So, one needs to assume that the external shell
libraries/frameworks, which the shell application relies on, do not
define the functions with the names conflicting with the paths that
the application or other libraries/frameworks use.

But I think that is the same for the normal libraries without
functions with slashes in their names. Badly designed
libraries/frameworks can always overwrite the basic utilities with the
shell functions. A carefully designed library/framework should define
its functions in a certain "namespace" by a consistent prefix, so the
user or other libraries/frameworks can avoid using conflicting names.

A difference between the function names with and without slashes would
be that the user probably intends to make sure to call the executable
file when the user uses the absolute path, such as /bin/echo. In that
sense, maybe we could disallow overriding the behavior of the absolute
path starting with a slash, and other special paths like `./*' and
`../*' while allowing the other forms of the function names such as
`mylib/*'.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]