Chet Ramey writes:
> --- 228,239
> *r++ = '\'';
>
> ! s = str;
> ! slen = strlen (str);
slen isn't used subsequently.
> ***
> *** 267,270
> --- 290,324
> }
>
> + #if defined (HANDLE_MULTIBYTE)
> + int
> + ansic_wshouldquote (string)
> + const char
On 3/18/12 1:26 PM, dennis.birkh...@rwth-aachen.de wrote:
> Bash Version: 4.2
> Patch Level: 24
> Release Status: release
>
> Description:
> Some UTF-8 multibyte characters are not printed correctly but UTF-8
> generally works as the "ä" in "März" (displayed via ls) works.
>
> Repeat-By
On 3/19/12 8:39 AM, Greg Wooledge wrote:
> On Fri, Mar 16, 2012 at 06:15:35PM -0400, Chet Ramey wrote:
>> Turn on history with `set -o history' and set HISTFILE and HISTSIZE as you
>> like. You can probably set some of the right variables in .ssh/environment
>> and set BASH_ENV to a file that wil
On 3/19/12 6:13 PM, Geir Hauge wrote:
> 2012/3/19 Chet Ramey :
>> I will look at optimizing that function, but it's always going to take time
>> to plow through 300K when you have to split it into words. (There's not
>> actually any word splitting of consequence happening with your second
>> examp
2012/3/19 Chet Ramey :
> I will look at optimizing that function, but it's always going to take time
> to plow through 300K when you have to split it into words. (There's not
> actually any word splitting of consequence happening with your second
> example using the pipeline.)
Letting compgen do
On 03/19/2012 02:15 PM, Stefano Lattarini wrote:
> On 03/19/2012 08:54 PM, Lane Schwartz wrote:
>> Hi,
>>
>> If I have a file that contains a bash script, is there any
>> straightforward way of determining whether that script can be parsed
>> successfully as a Bash script, without actually running
On 3/15/12 3:38 PM, Richard Neill wrote:
> Dear Bob,
>
> Thanks for your explanation. I do understand what is going on and why. But
> my point was that compgen has an implicit internal "grep" that is much less
> efficient than actual grep. Why is the performance of compgen's
> sorting/filtering al
On 3/14/12 1:44 PM, Richard Neill wrote:
> 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
On 03/19/2012 08:54 PM, Lane Schwartz wrote:
> Hi,
>
> If I have a file that contains a bash script, is there any
> straightforward way of determining whether that script can be parsed
> successfully as a Bash script, without actually running the file?
>
Yes: the "-n" option. Simple examples:
Hi,
If I have a file that contains a bash script, is there any
straightforward way of determining whether that script can be parsed
successfully as a Bash script, without actually running the file?
Here's the context. There is another tool (a workflow management
utility) which allows users to pro
I've boiled the problem down to this:
A=
B=q
echo "x${A+${B#q*}}x" | sed -nel
Excluding the newline, the output I expect is "xx", but instead there
is a delete character \177 between the two "x" characters.
After much experimenting, the important triggers are:
* The entire ${A...} substituti
Am 19.03.2012 13:39, schrieb Greg Wooledge:
On Fri, Mar 16, 2012 at 06:15:35PM -0400, Chet Ramey wrote:
There is nothing stopping you from using history in a non-interactive
shell -- it's just not enabled by default.
Turn on history with `set -o history' and set HISTFILE and HISTSIZE as you
lik
On Fri, Mar 16, 2012 at 06:15:35PM -0400, Chet Ramey wrote:
> There is nothing stopping you from using history in a non-interactive
> shell -- it's just not enabled by default.
>
> Turn on history with `set -o history' and set HISTFILE and HISTSIZE as you
> like. You can probably set some of the
13 matches
Mail list logo
