From a post here I learned that bash (and zsh) allows a hyphen as
part of a function identifier.

Script:
f-g() { echo 2; return 2; }
f=7 g=3
echo $(( f-g ))
echo $( f-g )
c-d=9

Output:
4
2
...: c-d=9: command not found

Do you consider that a sensible extension?

Janis

On 3/18/2022 7:01 PM, Janis Papanagnou wrote:
> From a post here I learned that bash (and zsh) allows a hyphen as
> part of a function identifier.
>
> Script:
> f-g() { echo 2; return 2; }
> f=7 g=3
> echo $(( f-g ))
> echo $( f-g )
> c-d=9
>
> Output:
> 4
> 2
> ...: c-d=9: command not found
>
>
> Do you consider that a sensible extension?

No, IMHO allowing more than C symbols (alphanumeric and underscore chars
starting with an alpha or underscore) for function and script names is
pointless, error-prone and annoying (trying to call foo_bar when the
script is named foo-bar or vice-versa). This appears to be a case of
"what can we do" over "what should we do".

Ed.

In comp.unix.shell, Ed Morton <mortonspam@gmail.com> wrote:
> On 3/18/2022 7:01 PM, Janis Papanagnou wrote:
>> From a post here I learned that bash (and zsh) allows a hyphen as
>> part of a function identifier.

Aliases and functions seem to share nearly the same namespace that
filenames have. I use ^? and ^H as alias names to set the backspace
stty setting. The actual control characters, not the common display
form.

Ksh:

alias ="stty erase '^?'"
alias ="stty erase '^H'"

(In bash, I can set both aliases, but the ^? generates a "command not
found" error. ^H works. In ksh, both work.)

> > Script:
> > f-g() { echo 2; return 2; }
> > f=7 g=3
> > echo $(( f-g ))
> > echo $( f-g )
> > c-d=9
> >
> > Output:
> > 4
> > 2
> > ...: c-d=9: command not found

Variable names have a different set of rules, to be more "sensible".

> > Do you consider that a sensible extension?

Yes, since shell functions and aliases may be used to replace commands
on the path, they should have the same rules for the identifiers.

> No, IMHO allowing more than C symbols (alphanumeric and underscore chars
> starting with an alpha or underscore) for function and script names is
> pointless, error-prone and annoying (trying to call foo_bar when the
> script is named foo-bar or vice-versa). This appears to be a case of
> "what can we do" over "what should we do".

Or you haven't thought through the "replace a command on path" use.

Bash:
$ unalias [
$ [[ $HOME ]] && echo ja
ja
$ [ $HOME ] && echo ja
ja
$ alias [=[[
$ [ $HOME ] && echo ja
bash: conditional binary operator expected
bash: syntax error near `]'
$ [ $HOME ]] && echo ja
ja
$
Ksh gives me an error trying to use [ as an alias name. Bash lets me
define and use a function [, ksh tells me the name is invalid.

Bash:
$ unalias [
$ function [ { echo yo; }
$ [
yo
$

Elijah
------
is unlikely to use exotic alias or function names except for very niche tasks

On 19.03.2022 03:35, Eli the Bearded wrote:
> In comp.unix.shell, Ed Morton <mortonspam@gmail.com> wrote:
>> On 3/18/2022 7:01 PM, Janis Papanagnou wrote:
>>> Script:
>>> f-g() { echo 2; return 2; }
>>> f=7 g=3
>>> echo $(( f-g ))
>>> echo $( f-g )
>>> c-d=9
>>>
>>> Output:
>>> 4
>>> 2
>>> ...: c-d=9: command not found
>>> Do you consider that a sensible extension?
>
> Yes, since shell functions and aliases may be used to replace commands
> on the path, they should have the same rules for the identifiers.

Interesting thought.

But on the OS-level (defining commands) you can use almost every
existing character to specify names of commands.

Janis

On 19.03.2022 02:23, Ed Morton wrote:
> On 3/18/2022 7:01 PM, Janis Papanagnou wrote:
>> From a post here I learned that bash (and zsh) allows a hyphen as
>> part of a function identifier.
>>
>> Script:
>> f-g() { echo 2; return 2; }
>> f=7 g=3
>> echo $(( f-g ))
>> echo $( f-g )
>> c-d=9
>>
>> Output:
>> 4
>> 2
>> ...: c-d=9: command not found
>>
>>
>> Do you consider that a sensible extension?
>
> No, IMHO allowing more than C symbols (alphanumeric and underscore chars
> starting with an alpha or underscore) for function and script names is
> pointless, error-prone and annoying (trying to call foo_bar when the
> script is named foo-bar or vice-versa). This appears to be a case of
> "what can we do" over "what should we do".

What I found disturbing with the above showed sample code is that the
lexical parsing isn't deterministic any more; in one context "f-g" is
tokenized as ID("f") OP("-") ID("g") and in the other context it's
ID("f-g"). Apart from the language parsing aspect it's also harder
for the coder (or code maintainer) to correctly interpret such code.

Janis

>
> Ed.