bashdb-devel

Re: [Bashdb-devel] munge_list

[R. B. <ro...@pa...>]

Masatake informs:
> I'm reading readarray.c.
>
> I have two questions.
>
> 1. Is the function provided by munge_list needed anyway?

Well, it's used as the first statement of readarray_builtin. But is it
really, really *needed*? Gee, I don't know. One could argue that
readarray altogether is not needed. For example SuSE packman packages
bashdb, and it doesn't use readarray. :-)

The form of that option models how head and tail work, e.g.:
  head -10 /etc/motd

>    I'd like to remove because this option parsing policy(function)
>    is not widly used in bash.

Ok. If there's someone out there that objects, that's why there's this
mailling list. A guess is that there isn't much use of readarray
outside of bashdb. So as long as bashdb still works without my having
to patch it (but I don't mind if however you do the patching should
there need to be any), I don't mind.

>
> 2. What does the * stand for in the following doc string:
>
>    "readarray [-t] [-c *count*] [-C callback] [-n *lines*] [-O *origin*] *file* *array_variable*"
>
>    `*'s are needed in *count*, *lines*, *origin*, *file* and *array_variable*?

This was to indicate a variable - something which is not typed in
exactly but represents the kind of thing you'd type in. For example, not
the string "*count*" but some sort of number, like 10. The use of
putting a word surrounded by asterisks to indicate an italicized word
I think was common in mailing lists like this one (See the first
paragraph of my reply above) and in older forms of email before the
days of HTML and other encodings.

>    I'd like to remove it because this notation is not popular
>    in bash.

Sure. 

> Tell me the backgrounds if there are.

I am not sure I understand exactly what you mean here; but with luck
I've done that somewhere in the above verbiage.

Re: [Bashdb-devel] munge_list

[Masatake Y. <je...@gy...>]

Hi,

> > I'm reading readarray.c.
> >
> > I have two questions.
> >
> > 1. Is the function provided by munge_list needed anyway?
> 
> Well, it's used as the first statement of readarray_builtin. But is it
> really, really *needed*? Gee, I don't know. One could argue that
> readarray altogether is not needed. For example SuSE packman packages
> bashdb, and it doesn't use readarray. :-)
> 
> The form of that option models how head and tail work, e.g.:
>   head -10 /etc/motd

I understand the intent.
I removed munge_list from the in-cvs version of bashdb. However, I'll check
how bash's builtins handles options again.

> >    I'd like to remove because this option parsing policy(function)
> >    is not widly used in bash.
> 
> Ok. If there's someone out there that objects, that's why there's this
> mailling list. A guess is that there isn't much use of readarray
> outside of bashdb. So as long as bashdb still works without my having
> to patch it (but I don't mind if however you do the patching should
> there need to be any), I don't mind.

If readarray is a command independent of bash, I think readarray should 
have munge_list.

> >
> > 2. What does the * stand for in the following doc string:
> >
> >    "readarray [-t] [-c *count*] [-C callback] [-n *lines*] [-O *origin*] *file* *array_variable*"
> >
> >    `*'s are needed in *count*, *lines*, *origin*, *file* and *array_variable*?
> 
> This was to indicate a variable - something which is not typed in
> exactly but represents the kind of thing you'd type in. For example, not
> the string "*count*" but some sort of number, like 10. The use of
> putting a word surrounded by asterisks to indicate an italicized word
> I think was common in mailing lists like this one (See the first
> paragraph of my reply above) and in older forms of email before the
> days of HTML and other encodings.
> 
> >    I'd like to remove it because this notation is not popular
> >    in bash.
> 
> Sure. 
> 
> > Tell me the backgrounds if there are.
> 
> I am not sure I understand exactly what you mean here; but with luck
> I've done that somewhere in the above verbiage.

I understand the intent of `*'. Thank you. I thinks "-C callback" is a kind of variable.
So I think it should be "-C *callback*". Am I right?

I removed them and updated the document string yesterday. 
However, I'll check the other bash builtins.

Masatake

Re: [Bashdb-devel] munge_list

[Rocky B. <roc...@gm...>]

It looks like the convention used for bash builtin help is to use lowercase
unadorned names in the usage but UPPERCASE when describing the option
variable names in the help text.. So something like:

 readarray [-t] [-c count] [-C callback] [-n lines] [-O origin] file
array_variable

Copy the lines from the input file into ARRAY_VARIABLE.

Use the `-n' option to specify COUNT  number of lines to copy.   If -n is
missing or 0 is given as the number all lines are copied.
Use the `-O' option to specify  index ORIGIN to start the array.
 ...

(Or suitably modified to accomodate the current parameters allowed.)

On 8/22/06, Masatake YAMATO <je...@gy...> wrote:
>
> Hi,
>
> > > I'm reading readarray.c.
> > >
> > > I have two questions.
> > >
> > > 1. Is the function provided by munge_list needed anyway?
> >
> > Well, it's used as the first statement of readarray_builtin. But is it
> > really, really *needed*? Gee, I don't know. One could argue that
> > readarray altogether is not needed. For example SuSE packman packages
> > bashdb, and it doesn't use readarray. :-)
> >
> > The form of that option models how head and tail work, e.g.:
> >   head -10 /etc/motd
>
> I understand the intent.
> I removed munge_list from the in-cvs version of bashdb. However, I'll
> check
> how bash's builtins handles options again.
>
> > >    I'd like to remove because this option parsing policy(function)
> > >    is not widly used in bash.
> >
> > Ok. If there's someone out there that objects, that's why there's this
> > mailling list. A guess is that there isn't much use of readarray
> > outside of bashdb. So as long as bashdb still works without my having
> > to patch it (but I don't mind if however you do the patching should
> > there need to be any), I don't mind.
>
> If readarray is a command independent of bash, I think readarray should
> have munge_list.
>
> > >
> > > 2. What does the * stand for in the following doc string:
> > >
> > >    "readarray [-t] [-c *count*] [-C callback] [-n *lines*] [-O
> *origin*] *file* *array_variable*"
> > >
> > >    `*'s are needed in *count*, *lines*, *origin*, *file* and
> *array_variable*?
> >
> > This was to indicate a variable - something which is not typed in
> > exactly but represents the kind of thing you'd type in. For example, not
> > the string "*count*" but some sort of number, like 10. The use of
> > putting a word surrounded by asterisks to indicate an italicized word
> > I think was common in mailing lists like this one (See the first
> > paragraph of my reply above) and in older forms of email before the
> > days of HTML and other encodings.
> >
> > >    I'd like to remove it because this notation is not popular
> > >    in bash.
> >
> > Sure.
> >
> > > Tell me the backgrounds if there are.
> >
> > I am not sure I understand exactly what you mean here; but with luck
> > I've done that somewhere in the above verbiage.
>
> I understand the intent of `*'. Thank you. I thinks "-C callback" is a
> kind of variable.
> So I think it should be "-C *callback*". Am I right?
>
> I removed them and updated the document string yesterday.
> However, I'll check the other bash builtins.
>
> Masatake
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Bashdb-devel mailing list
> Bas...@li...
> https://lists.sourceforge.net/lists/listinfo/bashdb-devel
>

Re: [Bashdb-devel] munge_list

[Masatake Y. <je...@gy...>]

> It looks like the convention used for bash builtin help is to use lowercase
> unadorned names in the usage but UPPERCASE when describing the option
> variable names in the help text.. So something like:
> 
>  readarray [-t] [-c count] [-C callback] [-n lines] [-O origin] file
> array_variable
> 
> Copy the lines from the input file into ARRAY_VARIABLE.
> 
> Use the `-n' option to specify COUNT  number of lines to copy.   If -n is
> missing or 0 is given as the number all lines are copied.
> Use the `-O' option to specify  index ORIGIN to start the array.
>  ...
> 
> (Or suitably modified to accomodate the current parameters allowed.)

Thank you. I've updated the documentation and installed to the cvs 
repository. Could you review the documentation?

Masatake