On 10/2/11 3:43 PM, Stephane CHAZELAS wrote:
> [*] actually, bash does some (undocumented) preprocessing on the
> regexps, so even the regex(3) reference is misleading here.
Not really. The words are documented to undergo quote removal, so
they undergo quote removal. That turns \1 into 1, for i
On 9/19/11 2:35 PM, Stephane CHAZELAS wrote:
>> Thanks for the report. This looks like an independent reimplementation of
>> the "exponentiation by squaring" method. I did a little looking around,
>> and it's the best algorithm out there. I used a slightly different but
>> equivalent implementa
2011-09-17, 13:39(+00), Stephane CHAZELAS:
> 2011-09-17, 13:06(+00), Stephane CHAZELAS:
>> 2011-09-16, 17:17(-07), William Park:
>>> 145557834293068928043467566190278008218249525830565939618481
>>> is awfully big number! :-)
>>
>> 3**2**62 is 3**(2**62), 3**4611686018427387904, not a number you
>>
2011-10-01, 06:54(-05), Dan Douglas:
[...]
> f() {
> local -i x y
> while read -rN1 "x[y++]"; do
> printf '%d ' "${1}" >&2# keep track of which job this is.
> done
> printf "${#x[@]} " # Print the total number of reads by each
> job.
if you add a echo >&2 "
2011-09-19, 09:27(-04), Chet Ramey:
> On 9/16/11 4:39 PM, Nicolas ARGYROU wrote:
>
>> Bash Version: 4.0
>> Patch Level: 33
>> Release Status: release
>>
>> Description:
>> The algorithm used to calculate x to the power of y: x**y
>> takes O(y) time which is way too long on systems using 64
2011-10-1, 14:39(-08), rogerx@gmail.com:
[...]
> I took some time to examine the three regex references:
>
> 1)
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_04
> Written more like a technical specification of regex. Great if your're
> going to be mo
2011-09-17, 13:06(+00), Stephane CHAZELAS:
> 2011-09-16, 17:17(-07), William Park:
>> 145557834293068928043467566190278008218249525830565939618481
>> is awfully big number! :-)
>
> 3**2**62 is 3**(2**62), 3**4611686018427387904, not a number you
> can represent with 64bits, nor any reasonable numbe
2011-09-16, 17:17(-07), William Park:
> 145557834293068928043467566190278008218249525830565939618481
> is awfully big number! :-)
3**2**62 is 3**(2**62), 3**4611686018427387904, not a number you
can represent with 64bits, nor any reasonable number of bits,
not (3**2)**62.
Certainly not a number
2011-08-25, 12:19(-07), Linda Walsh:
[...]
> ` Greg Wooledge wrote:
>> On Wed, Aug 24, 2011 at 06:51:32PM -0700, Linda Walsh wrote:
>>
>>> BTW, Thomas -- what is the Character that comes after 'De' in your
>>> name? I read it as hex '0xc282c2' which doesn't seem to be valid unicode.
>>>
>
2011-09-14, 09:46(+01), Wheatley, Martin R:
[...]
> Description:
> The contents of the environment variable TMOUT are used are the
> default timeout for the read builtin command when reading from
> a TTY or pipe AND as a shell command input idle time.
>
> This can lead to ra
2011-08-17, 08:24(-04), Greg Wooledge:
> On Tue, Aug 16, 2011 at 03:41:19PM -0700, Linda Walsh wrote:
>> Ken Irving wrote:
>> >Maybe this?
>> >today_snaps=( ${snap_prefix} )
>
>> but as you mention, that will put them into an arraysorry "imprecise
>> terminology" list for me is some n
2011-08-18, 12:44(+02), Patrick:
[...]
>> $ VAR=foo sh -c 'VAR=bar; env' | grep VAR
>> VAR=foo
>> $ VAR=foo sh -c 'VAR=bar; export VAR; env' | grep VAR
>> VAR=bar
> Interresting! I do not have the bourne shell installed. Bash tries to
> mimic it when called as "sh", but it does not produce the "co
2011-08-14, 02:43(+00), Michael Witten:
[...]
>> Please read BashFAQ/006: http://mywiki.wooledge.org/BashFAQ/006
>
> "no force in the universe can put NUL bytes into shell strings usefully"
>
> Ain't that the goddamn Truth!
No, zsh supports NUL bytes in its strings happily. It's even in
the defaul
2011-08-18, 04:10(+02), Patrick:
> On 17.08.2011 20:53, Stephane CHAZELAS wrote:
>> 2011-08-17, 08:32(+02), Francky Leyn:
>>> On 8/16/2011 10:53 PM, Stephane CHAZELAS wrote:
>>> 2) If VAR coincides with an environment variable, and in the
>>> script I change it value, is this then propagated t
2011-08-17, 08:32(+02), Francky Leyn:
> On 8/16/2011 10:53 PM, Stephane CHAZELAS wrote:
>> 2011-08-16, 22:24(+02), Francky Leyn:
>> [...]
>>> VAR=FALSE
>>> # some command line procesing, that can set VAR to "TRUE"
>>> if [ $VAR = TRUE ]; then
>>> ...
>>> fi
>>>
>>> Must I effectively write that VAR
2011-08-16, 22:24(+02), Francky Leyn:
[...]
> VAR=FALSE
> # some command line procesing, that can set VAR to "TRUE"
> if [ $VAR = TRUE ]; then
> ...
> fi
>
> Must I effectively write that VAR=FALSE?
> Or will the script work fine without?
Yes, you must write it, because bash may inherit a VAR vari
2011-08-15, 17:15(+02), Francky Leyn:
> Hello,
>
> if you have a variable, say VAR,
> and you don't assign it a value,
> and afterwards you test it,
> what is the value of $VAR then?
>
> random, or an empty string?
[...]
Upon startup, the shell makes one shell variable per environment
variable who
It worked for a while after I reported the issue and then it
stopped again. That's very frustrating.
--
Stephane
18 matches
Mail list logo
