Dear All,
I don't know for certain if this is a bug per se, but I think
"compgen -W" is much slower than it "should" be in the case of a large
(1+) number of options.
For example (on a fast i7 2700 CPU), I measure:
compgen -W "`seq 1 5`" 1794#3.83 s
compgen -W "`seq 1 5 |
If I increase the upper number by a factor of 10, to 50, these times
become, 436 s (yes, really, 7 minutes!) and 0.20 s respectively. This
suggests that the algorithm used by compgen is O(n^2) whereas the
algorithm used by grep is 0(1).
I meant: grep is O(n).
ad it wrong for some time.]
Best wishes,
Richard
Message: 4
Date: Wed, 14 Mar 2012 13:40:36 -0600
From: Bob Proulx
To: bug-bash@gnu.org
Subject: Re: compgen is slow for large numbers of options
Message-ID:<20120314194036.ga12...@hysteria.proulx.com>
Content-Type: text/plain; charset=us-asci
Dear All,
Might I suggest/request that "set +n" should undo the effect of
"set -n" ?
For example:
#!/bin/bash
echo one
set -n
echo two
set +n
echo three
would print:
one
three
Here's why I think it would be useful:
1. Bash do
Dear All,
I hope I'm posting this in the right place, since it it's really a
feature request, rather than a bug report. However, here are a few
things which I think would be nice to have in bash, and easy to implement:
1)substr support for a negative length argument.
For example,
stringZ=ab
Dear Grzegorz,
Thanks for your helpful reply.
Grzegorz Adam Hankiewicz wrote:
On 2006-12-27, Richard Neill <[EMAIL PROTECTED]> wrote:
1)substr support for a negative length argument.
For example,
stringZ=abcdef
echo ${stringZ:2:-1} #prints cde
i.e. ${string:x:y}
returns the
5)An enhancement to read/readline, such that one can specify the initial
value with which the buffer is filled.
Currently, we can do:
read -ep 'Enter your name: ' NAME
and I might type "Richad Neill". #Note the deliberate typo.
If the script recognises this as invalid, the best it ca
Bash Version: 3.2
Patch Level: 13
Release Status: release
Description:
$ echo $((40*40)
-2446744073709551616
Repeat-By:
Do some arithmetic in bash $(()).
If the numbers are out of range, the output will be wrong in
all sorts of inte
Chet Ramey wrote:
Description:
$ echo $((40*40)
-2446744073709551616
Repeat-By:
Do some arithmetic in bash $(()).
If the numbers are out of range, the output will be wrong in
all sorts of interesting ways. No error message is given.
Fix:
Bob Proulx wrote:
Richard Neill wrote:
b)Consistent with other cases, where bash does give warnings. For example:
$ X=$((3+078))
bash: 3+078: value too great for base (error token is "078")
$ echo $?
1
That is not really a comparable case. The problem there is that the
le
Bob Proulx wrote:
Andreas Schwab wrote:
Richard Neill <[EMAIL PROTECTED]> writes:
Are you sure this isn't comparable? After all, in both cases, the user has
submitted something to which bash cannot give a sensible answer. In the
integer-overflow case, bash simply returns the w
Dear All,
In some cases, bash gives exceptionally unhelpful error messages, of the
sort "Unexpected end of file". This is next-to-useless as a debugging
aid, since there is no way to find out where the error really lies.
I'm using bash version: bash-3.2-7mdv2008.1
Here are 2 shell scripts with e
Chet Ramey wrote:
> Richard Neill wrote:
>> Dear All,
>>
>> In some cases, bash gives exceptionally unhelpful error messages, of the
>> sort "Unexpected end of file". This is next-to-useless as a debugging
>> aid, since there is no way to find out wher
Dear All,
When using read, it would be really neat to be able to pre-fill the form
with a default (or previous) value.
For example, a script which wants you to enter your name, and thinks
that my name is Richard, but that I might want to correct it.
Alternatively, this would be useful within a lo
Dear All,
Substrings in bash contain 2 parameters, the start and the length.
Start may be negative, but if length is negative, it throws an error.
My request is that bash should understand negative length. This would be
useful in some occasions, and would be similar to the way PHP does it:
http://
Jan Schampera wrote:
> Richard Neill wrote:
>
>> $ echo ${stringZ:2: -1} #Wish: start at 2, read till
>> ERROR#1 before the end. i.e.
>> # cde
>>
>> $ echo ${stringZ: -3: -1}#Wi
Jan Schampera wrote:
> Richard Neill wrote:
>> Dear All,
>>
>> When using read, it would be really neat to be able to pre-fill the form
>> with a default (or previous) value.
>>
>> For example, a script which wants you to enter your name, and thinks
>&
Dear All,
Might I propose bash should add another operator, >>> for "redirection
into a variable". This would be by analogy with the <<< operator.
For example, we can currently use <<< to save an "echo", by doing this:
TEXT="Hello World"
grep -o 'hello' <<<"$TEXT"
instead of
TE
At the moment, variables set within a subshell can never be accessed by
the parent script. This is true, even for an implicit subshell such as
caused by read.
For example, consider the following (slightly contrived example)
touch example-file
ls -l | while read LINE ; do
i
result.
fi
done
if [ $? != 2 ]; then
echo -e "ERROR: the installed version of 'ffmpeg' was built
without support enabled for $decodeencode_txt $filecodec_txt
'$filecodec_name'.\n"
exit 1
fi
}
--
Thank you. That's a really neat solution - and it would never have
occurred to me. I always think from left to right!
Richard
Paul Jarc wrote:
Richard Neill <[EMAIL PROTECTED]> wrote:
the aim is to parse the output of "ffmpeg -formats" to see whether
certain codecs
Dear All,
Here's a rather controversial request, namely that bash should support
'goto'.
The reason I'd like to see it is to make debugging long scripts easier.
I'm working at the moment on a 2000+ line script, and if I want to test
stuff at the end, I'd really like to have something like th
Bob Proulx wrote:
Richard Neill wrote:
Dear All,
In the future please start a new message for a new thread of
discussion. When you reply to old messages from three months ago
those of us who actually keep months worth of email see the message
threaded with the previous discussion about
Dear All,
Here's an idea that occurred to me. I'm not sure whether it's a great
idea, or a really really stupid one, so please feel free to shoot it
down. Anyway, there are an awful lot of shell scripts where a huge
number of the coreutils get repeatedly called in separate processes.
This cal
Andreas Schwab wrote:
What I'm suggesting is to experimentally build a version of bash which has
mv/cp/ls/stat/grep/ all built in.
This is possible without rebuilding bash, see the documentation of the
`enable' builtin. There are already a few examples in the bash
distribution under exam
Thanks for your reply.
Description:
Bash allows escape characters to be embedded by using the $'\n'
syntax. However, unlike all other $variables,
this doesn't work with embedded newlines. I think it should.
Repeat-By:
X="a$'\n'b c"
echo "$X"
expect to
26 matches
Mail list logo
