helpThe GNU Bourne-Again SHell - Support: sr #110419, Fix inconsistant identifier names...

 
 

sr #110419: Fix inconsistant identifier names for functions and variables in future BASH release

Submitter:  Paxsali <paxsali>
Submitted:  Fri 08 Jan 2021 06:48:30 AM UTC
 
Category:  None Priority:  5 - Normal
Severity:  4 - Important Status:  Wont Do
Privacy:  Public Assigned to:  None
Open/Closed:  Open Operating System:  None
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

Thu 14 Jan 2021 08:19:24 PM UTC, comment #1: 

There isn't any good reason why the allowed namespace for functions should be different than what's allowed for commands,
the obvious exception being `/', since that alters the command search behavior, and a few other cases that bash excludes to make life a little easier.

The examples you give aren't convincing. You can use a function named `-f' just fine, and view it with the usual `declare -f -- -f'. Nor do you provide specifics or a rationale for your assertion that it's "highly misguided and potentially dangerous."

Chet Ramey <chet>
Project Administrator
Fri 08 Jan 2021 06:48:30 AM UTC, original submission:  

Hello,

I find it a big problem in terms of both aethetics and usability that there are two different rules for valid names (aka identifiers) in bash.

The rules for variable names are different that those for functions and I see no strong argument why that should be the case.

You can do stuff like the famous fork-bomb, because of it.

But you can also block you functionality that would otherwise be accessible.

Consider the following example:

$ -f() { echo hello world;}
$ -f
hello world
$ --force() { echo "hello world";}
$ --force
hello world

$ declare -f -f
[declare builtin prints ALL function definitions to console, not just that of "-f(). however, it included both functions "-f()" and "--force()" in it's output.]

I even saw some people writing code in bash and naming their functions something like "banana::printb() { ...;}".
Obviously this must be inspired from their previous programming languages, like Perl and it's module structure and how it's referenced during imports (use...).
But I find this highly misguided and potentially dangerous.

There are some weird cases that I cannot recall from memory, but it did happen to me that some code didn't work, because of the way I variable substition on function names and it was broken, if the function name contained a minus or a colon (possibly other chars would have the same effect).

You can even declare function which start with a digit, something that otherwise is not valid for variables.

$ 0f=1 # not a valid variable name / asignment
0f=1: command not found
$ 0f() { echo hello world;}
$ declare -f 0f
0f ()
{
    echo hello world
}

I don't know what the history is why this is even allowed and possibly there is or was some old standard to blame for this, there usually always is some kind of excuse for things that obvious.

However, at some point I believe it must be possible to leave the old, ugly stuff behind. No idea what your plans are about the manjor releases of Bash 6.0 or 7.0, but at some point in the future I believe this situation needs to be resolved - and yes, I am aware it WILL break (some) code.

Kindly asking for consideration / discussion / feedback.

Knock yourselves out.

Cheers,
Pax.

Paxsali <paxsali>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by chet (Posted a comment)
  • -email is unavailable- added by paxsali (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

     

     

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-01-14 chet StatusNone Wont Do

    Back to the top


    Powered by Savane 3.9