On 1/20/19 10:56 PM, pepa65 wrote:
> On 20/1/2019 19:50, Eduardo A. Bustamante López wrote:
>> Changing the behavior of `unset f' to only ever unset variables means
>> potentially breaking existing scripts. Is the inconsistency reported severe
>> enough to make this change?
>
> The alternative
On 21.01.2019 05:26, Robert Elz wrote:
> I think his point is that if unset "unset f" (no flags) works to unset
> function f, if f is not a (set) variable, then it should work every time
> "f" is not a set variable, not only the times when the word "f" happens
> to be of the correct syntax to be
On 20/1/2019 19:50, Eduardo A. Bustamante López wrote:
> Changing the behavior of `unset f' to only ever unset variables means
> potentially breaking existing scripts. Is the inconsistency reported severe
> enough to make this change?
The alternative would be to allow anything (that is not a
Date:Sun, 20 Jan 2019 19:50:35 -0800
From:Eduardo =?iso-8859-1?Q?A=2E_Bustamante_L=F3pez?=
Message-ID: <20190121035035.gc31...@system76-pc.vc.shawcable.net>
| Changing the behavior of `unset f' to only ever unset variables means
| potentially breaking existing
On Mon, Jan 21, 2019 at 09:26:59AM +0700, Robert Elz wrote:
(...)
> I think his point is that if unset "unset f" (no flags) works to unset
> function f, if f is not a (set) variable, then it should work every time
> "f" is not a set variable, not only the times when the word "f" happens
> to be
Date:Sun, 20 Jan 2019 16:02:51 -0500
From:Chet Ramey
Message-ID:
| You should not ignore the variable names case. The behavior of unset
| without arguments is to check for a variable first, then optionally
| check for a function name.
That's fine.
| The
On 21.01.2019 00:02, Chet Ramey wrote:
> On 1/20/19 1:46 PM, Andrey Butirsky wrote:
>> I'm not quite understand what exactly is "intentional".
>> The problem is inconsistent behavior of unset '-f' flag for "normal" and
>> "not-normal" function names (I'm not considering conflicting with
>>
On 1/20/19 4:03 PM, Andrey Butirsky wrote:
> Chet, the sample was run in normal, not POSIX, mode.
> So it allows '1a' but disallows '1'. Pretty odd.
Yeah, it should not reject all digits when not in posix mode. I'll take
a look there.
--
``The lyf so short, the craft so long to lerne.'' -
On 1/20/19 1:46 PM, Andrey Butirsky wrote:
> I'm not quite understand what exactly is "intentional".
> The problem is inconsistent behavior of unset '-f' flag for "normal" and
> "not-normal" function names (I'm not considering conflicting with
> variable names case).
You should not ignore the
Chet, the sample was run in normal, not POSIX, mode.
So it allows '1a' but disallows '1'. Pretty odd.
On 20.01.2019 23:55, Chet Ramey wrote:
> On 1/20/19 10:46 AM, Andrey Butirsky wrote:
>> `1' is not a valid identifier, still:
>> $ function 1 () { :; }
>> bash: `1': not a valid identifier
>>
>>
On 1/20/19 1:22 PM, Ilkka Virta wrote:
> The manual could of course mention something about the accepted function
> names, e.g. "Function names can contain the characters [...], except in
> POSIX mode, where they must be valid shell /names/." I'm not exactly sure
> what the accepted characters
On 1/20/19 10:26 AM, Andrey Butirsky wrote:
> Andreas, I know it will work with the '-f' flag.
> But for others function names, the '-f' unset flag is not required.
> Moreover, it seem confronts with Open Group Base Specification.
When posix mode is enabled, bash restricts function names to valid
On 1/20/19 10:46 AM, Andrey Butirsky wrote:
> `1' is not a valid identifier, still:
> $ function 1 () { :; }
> bash: `1': not a valid identifier
>
> So that is pretty messy..
In posix mode, bash restricts function names to be valid shell identifiers,
as the standard specifies.
--
``The lyf so
On Sun, Jan 20, 2019 at 11:05 AM Andrey Butirsky wrote:
>
> Eduardo, the question is about inconsistent, error-prone implementation.
> Not about the workarounds.
What's the error prone part?
- Declare a function name
- Unset it with 'unset -f'
Eduardo, the question is about inconsistent, error-prone implementation.
Not about the workarounds.
On 20.01.2019 21:59, Eduardo Bustamante wrote:
>> The problem is inconsistent behavior of unset '-f' flag for "normal" and
>> "not-normal" function names (I'm not considering conflicting with
>>
On Sun, Jan 20, 2019 at 10:46 AM Andrey Butirsky wrote:
>
> I'm not quite understand what exactly is "intentional".
Accepting different sets of function names (when POSIX mode is either on/off).
> The problem is inconsistent behavior of unset '-f' flag for "normal" and
> "not-normal" function
I'm not quite understand what exactly is "intentional".
The problem is inconsistent behavior of unset '-f' flag for "normal" and
"not-normal" function names (I'm not considering conflicting with
variable names case).
This is just confusing and makes the scripts error-prone, IMO.
On 20.01.2019
On Sun, Jan 20, 2019 at 06:26:43PM +0300, Andrey Butirsky wrote:
> Andreas, I know it will work with the '-f' flag.
> But for others function names, the '-f' unset flag is not required.
> Moreover, it seem confronts with Open Group Base Specification.
> So I consider it as a bug still.
>
It is
In POSIX mode, Bash disallows names like '1a':
13. Function names must be valid shell names. That is, they may not
contain characters other than letters, digits, and underscores, and may
not start with a digit. Declaring a function with an invalid name
causes a fatal syntax error in
`1' is not a valid identifier, still:
$ function 1 () { :; }
bash: `1': not a valid identifier
So that is pretty messy..
Bug report: https://savannah.gnu.org/support/?109632
On 20.01.2019 18:26, Andrey Butirsky wrote:
> Andreas, I know it will work with the '-f' flag.
> But for others function
Andreas, I know it will work with the '-f' flag.
But for others function names, the '-f' unset flag is not required.
Moreover, it seem confronts with Open Group Base Specification.
So I consider it as a bug still.
On 20.01.2019 18:18, Andreas Schwab wrote:
> On Jan 20 2019, Andrey Butirsky
On Jan 20 2019, Andrey Butirsky wrote:
> |$ unset 1a ||
> ||bash: unset: `1a': not a valid identifier
Use `unset -f'.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely
Hello,
seems like bash allows illegal function names, but refuses to unset them
then:
|$ function 1a () { :; }||
|
|$ declare -f 1a ||
||1a () ||
||{ ||
|| :||
||}||
|
|$ unset 1a ||
||bash: unset: `1a': not a valid identifier
$
GNU bash, version 4.3.48(1)-release
23 matches
Mail list logo
