[gentoo-amd64] Eselect Syntax Bug?

[gentoo-amd64] Eselect Syntax Bug?

[Frank Peters]

I had first noticed this problem some time ago.

Running eselect, a bash script, always fails with the errors:

`ec_do_list-options': not a valid identifier
`ec_do_list-modules': not a valid identifier

This is not surprising.  In bash, any variable or function should not
contain a hyphen because it could be mistaken for the subtraction
operator.  Indeed, replacing these variables with

ec_do_list_options
ec_do_list_modules

completely fixes the problem and allows eselect to do its job normally.

But why has not such an obvious mistake been observed before?

Has anyone else executed an unmodified eselect without error?

Is there more to this issue than meets the eye?

I can't file a bug report on this until I get some confirmation.

Frank Peters

Re: [gentoo-amd64] Eselect Syntax Bug?

[Josh Sled]

[-- Attachment #1: Type: text/plain, Size: 1446 bytes --]

Frank Peters <frank.peters@comcast.net> writes:

> Running eselect, a bash script, always fails with the errors:
>
> `ec_do_list-options': not a valid identifier
> `ec_do_list-modules': not a valid identifier
[…]
> But why has not such an obvious mistake been observed before?
>
> Has anyone else executed an unmodified eselect without error?

What version of bash?  You mentioned using bash 4 and downgrading to
"3.2" in the previous thread.   A bit more detail here would be nice.
What use flags for bash, too?

It works fine, here:

jsled@phoenix [~]$ bash --version
GNU bash, version 3.2.39(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2007 Free Software Foundation, Inc.
jsled@phoenix [~]$ eix -r '^bash$'
[I] app-shells/bash
     Available versions:  3.1_p17 3.2_p39 ~3.2_p48 ~3.2_p48-r1 ~4.0_p10 ~4.0_p10-r1 ~4.0_p17 ~4.0_p17-r1 ~4.0_p24 ~4.0_p28 {afs bashlogger examples net nls plugins vanilla}
     Installed versions:  3.2_p39(03:41:31 AM 05/07/2009)(nls -afs -bashlogger -examples -plugins -vanilla)
     Homepage:            http://cnswww.cns.cwru.edu/~chet/bash/bashtop.html
     Description:         The standard GNU Bourne again shell

jsled@phoenix [~]$ eselect --help
Usage: eselect <global options> <module name> <module options>

Global options:
[…works fine, no errors, &c.…]
jsled@phoenix [~]$

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo ${a}@${b}

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-amd64] Eselect Syntax Bug?

[Frank Peters]

On Mon, 03 Aug 2009 10:27:39 -0400
Josh Sled <jsled@asynchronous.org> wrote:

> It works fine, here:
> 
> jsled@phoenix [~]$ eselect --help
> Usage: eselect <global options> <module name> <module options>
> 
> Global options:
> […works fine, no errors, &c.…]


That's the question.  Why does it work on your system?

If you feel so inclined, would you save the following lines
to a text file in some directory, give the file execute permissions,
and then execute the file.  These lines encapsulate the problem with
the eselect code.


#! /bin/bash
function-one()
{
echo "FOOBAR"
}
function-one


This code fails on my system.  In fact, I booted into my old system,
a non-gentoo system, and the code also failed.  However, after booting
into a Linux rescue disk, that runs from a CD and ramdisk, the code does
not fail.  (All bash versions were 4.x.)

Although this problem is only of minor concern, it has become rather
annoying to me.

USE="net -afs -bashlogger -examples -nls -plugins -vanilla"

But I also compiled with vanilla and the results are the same.

Maybe in time I can gain some more insight into this behavior but
right now I am stumped.

Frank Peters

Re: [gentoo-amd64] Eselect Syntax Bug?

[Frank Peters]

On Mon, 3 Aug 2009 12:17:51 -0400
Frank Peters <frank.peters@comcast.net> wrote:


>  These lines encapsulate the problem with
> the eselect code.
> 
> 
> #! /bin/bash
> function-one()
> {
> echo "FOOBAR"
> }
> function-one
> 
> 
> This code fails on my system.  In fact, I booted into my old system,
> a non-gentoo system, and the code also failed.  However, after booting
> into a Linux rescue disk, that runs from a CD and ramdisk, the code does
> not fail.  (All bash versions were 4.x.)
> 
>

I am responding to my own message.

The code fails on some systems and succeeds on other systems.  Why?

The answer may not be important.  The code seems to be an example
of poor practice.  Check out the second entry at this link:

http://tldp.org/LDP/abs/html/gotchas.html

If the above code is re-written to remove the hyphens and replace
them with underscores, it will not fail on any system.

Thus, the eselect developers should re-write their variables using
underscores and the problem will disappear for everyone.

Frank Peters

Re: [gentoo-amd64] Eselect Syntax Bug?

[Josh Sled]

[-- Attachment #1: Type: text/plain, Size: 943 bytes --]

Frank Peters <frank.peters@comcast.net> writes:
> If you feel so inclined, would you save the following lines
> to a text file in some directory, give the file execute permissions,
> and then execute the file.  These lines encapsulate the problem with
> the eselect code.

Runs fine here.  :(

> But I also compiled with vanilla and the results are the same.

'vanilla' is the one that jumped out at me, too.

> Maybe in time I can gain some more insight into this behavior but
> right now I am stumped.

Very strange, indeed.  I mean, the bash man page is very clear on the
grammar for 'name' (the token-class in question), and it does not admit
'-'.  Maybe see if there's a bash bug or FAQ from that angle?  Plus,
report the bad syntax to the eselect devs, of course.  Even if it works,
it only works accidentally, and is bad form.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo ${a}@${b}

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]