Re: Bash git repository on savannah

[Pádraig Brady]

On 11/28/11 8:34 AM, Chet Ramey wrote:
> On 11/28/11 4:48 AM, Roman Rakus wrote:
> > On 11/28/2011 06:28 AM, Mike Frysinger wrote:
> >>> I don't think I'll push every change to git as soon as it happens, but
> >>> >  I'm thinking about fairly frequent commits to a `bash-devel' sort of
> >>> >  tree.  The question is whether or not enough people would be interested
> >>> >  in that to make the frequency worth it.
> >> i would;)
> >> -mike
> > me too
>
> OK, that's three. :-)

I'd also appreciate each change pushed to the devel git branch.

Having 20 years of history in the coreutils git repo
has been invaluable for ongoing development.

thanks,
Pádraig.

Re: gnu parallel in the bash manual

[John Kearney]

Am 03.03.2013 01:40, schrieb Chet Ramey:
>> this is actually more disturbing.
>>
>> ls | parallel mv {} destdir
>>
>> find -type f -print0 | xargs -0 -I{} -P  /bin/mv {} 
> If we're really going to pick nits here, those two aren't really identical.
>
> You'd probably want something like
>
> find . -depth 1 \! -name '.*' -print0
>
> to start.
>
> Chet
>
Sure your right what I showed wasn't a 1 to 1 functional replacement,
but then again most times I see ppl using a ls | syntax they actually
don't intend that functionality, its a side effect of them not knowing
how to use a better syntax.
The example is bad anyway as you normally don't want to parallelize disk
io , due to seek overhead and io bottle neck congestion. This example
will be slower and more likely to damage your disk than simply using mv
on its own. but thats another discussion.

with regards to nit picking, considering how much effort is made on this
mailing list and help-bash to give filename safe examples, its hardly
nitpicking to expect the examples in the bash manual to be written to
the same standard.

documentation... readonly help is not accurate

[Gotmy Nick]

Hello,

   Sorry if this has been reported earlier, but I can't find nothing
related in the archives.

  $ help readonly | grep -- '-p'
  readonly: readonly [-aAf] [name[=value] ...] or readonly -p
-pdisplay a list of all readonly variables and functions

  $ echo $BASH_VERSION
  4.2.37(1)-release

   I think the description should say "or" instead of "and". I think
it's the sorter way to clarify the behavior.

   This is, it will not print readonly functions unless called with
-fp, and in such case, it will not print variables, so in my opinion,
using "or" could be more accurate than "and".

   In the man page, it says... "If no name arguments are given, or if
the -p option is supplied, a list of all readonly names is printed."
but in practice it only prints variables (including arrays and
associative arrays). The only thing it says about -f is "If the -f
option is supplied, the functions corresponding to the names are so
marked.". Maybe it could be better something like "If the -f option is
supplied, restricts _name_ to functions" or something similar.

   On "help declare" uses in the descriptions "restrict action ..."
and points to "NAME", while "help readonly" uses "refer to ..."
(indexed array, associative, etc), maybe it needs a review for clarity
and consistency. Also, for completion, maybe the "description" line of
"help readonly" or "help -d readonly" (as well as for "help declare")
could be updated from "variables" to "variables or functions".

   A lot of thanks.


Best regards

-- 
Iñigo Tejedor Arrondo