Jim Meyering meyering.net> writes:
[funky automake version numbers]
>When in doubt, use sort -V from the latest coreutils:
>
>$ printf 'automake-1.10%s\n' .1 a|sort -V
>automake-1.10.1
>automake-1.10a
That's not the result I get:
% printf 'automake-1.10%s\n' .1 a|sort -V
automake-1
Hello, bug-coreutils!
There is a problem with color ls when a background color is used and the line
wraps. It leads to complete new line erased with the background on "bce"
terminals.
(One may argue that rxvt behaves differently, but there are many other bce
terminals)
One fix is to clear to en
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 10/14/2008 7:13 AM:
> Oh! I was using a just-too-old (pre-7.0) version there.
> Thanks for checking and keeping me honest.
> IMHO this means automake is muddying the waters by giving
> something-newer-than automake-1.10.1
On Tuesday 14 October 2008 15:27:54 Eric Blake wrote:
> On the other hand, autoconf's m4_version_compare (which is what automake
> uses to determine if you are using a new enough version, when you request
> 1.10a), treats 1.10a > 1.10.1. In other words, 1.10a is the alpha in
> preparation for 1.11
Eric Blake <[EMAIL PROTECTED]> wrote:
> According to Jim Meyering on 10/14/2008 7:13 AM:
>> Oh! I was using a just-too-old (pre-7.0) version there.
>> Thanks for checking and keeping me honest.
>> IMHO this means automake is muddying the waters by giving
>> something-newer-than automake-1.10.1 the
Hello,
at https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/123423 is proposed
ls enhancement highlighting regular files with hardlinks (1 < nlink). I tried
to implement this enhancement, but I have some questions:
1. Do you think, it would be useful? I think it would.
2. In the report
Kamil Dudka <[EMAIL PROTECTED]> wrote:
> at https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/123423 is proposed
> ls enhancement highlighting regular files with hardlinks (1 < nlink). I tried
> to implement this enhancement, but I have some questions:
>
> 1. Do you think, it would be useful
"Alexander V. Lukyanov" <[EMAIL PROTECTED]> wrote:
> Hello, bug-coreutils!
>
> There is a problem with color ls when a background color is used and the line
> wraps. It leads to complete new line erased with the background on "bce"
> terminals.
> (One may argue that rxvt behaves differently, but t
Eric Blake wrote:
> According to Pádraig Brady on 10/14/2008 3:47 AM:
>>> With native versions of expr, and expr from GNU coreutils prior to
>>> version 7.0, the expansion of lscmd usually begins "-rw-r--r--", but
>>> the leading hyphen does not cause the word to be treated as an option.
>> I think
On Tuesday 2008-10-14 10:17, Jim Meyering wrote:
>>
>> --- ls.c.1 2008-10-14 12:24:39.60505 +0400
>> +++ ls.c 2008-10-14 12:25:48.985396400 +0400
>> @@ -538,7 +538,7 @@
>>{
>> { LEN_STR_PAIR ("\033[") }, /* lc: Left of color sequence */
>> { LEN_STR_PAIR ("m") }
Jim Meyering <[EMAIL PROTECTED]> wrote:
> Simon Josefsson <[EMAIL PROTECTED]> wrote:
>> Jim Meyering <[EMAIL PROTECTED]> writes:
>>
>>> Does anyone object to my installing a server-side hook
>>> that would prevent pushing merge commits on master?
>>> In our experience here (with gnulib.git), pushin
olá, estou tentando ativar uma pasta que está comsua capacidadeesgotada
, os comandos que tenho não liberam espaço para que ela abranovamente para
o usuario. agradeço qualquer ajuda que possa me = enviar.
obrigado
admlocal
___
Bug-cor
Hello,
as I played a bit with the "--color" option of "ls" I found, that some
values of "--color=WHEN" are undocumented.
I saw this proble in coreutils-7.0 beta and in coreutils-6.11, but
probably the problem is much older.
The valid options of "--color=WHEN" are according to the source code
c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Gabriel de Lara - Colegio Estadual on 10/14/2008 11:00 AM:
>olá, estou tentando ativar uma pasta que está comsua capacidade
> esgotada , os comandos que tenho não liberam espaço para que ela abra
> novamente para o usuario. ag
Jim Meyering meyering.net> writes:
>>% printf 'automake-1.10%s\n' .1 a|sort -V
>>automake-1.10a
>>automake-1.10.1
>IMHO this means automake is muddying the waters by giving
>something-newer-than automake-1.10.1 the version string "1.10a".
Or that sort -V is incorrect. Note that Perl's Sort::Ve
Jim Meyering wrote:
> Ed Avis <[EMAIL PROTECTED]> wrote:
>> Jim Meyering meyering.net> writes:
>>
A few tools are required to build coreutils from a git checkout, but
not checked in a friendly way.
>>> The newer automake-1.10a is actually required.
>> Ah, ok, it could do with a comment b
Nelson H. F. Beebe wrote:
> I've just filed a bug report with The Mathworks, vendor of the
> widely-used Matlab matrix algebra system. Their bin/matlab startup
> script (all versions up to current) contains code like this:
>
> if [ `expr "$lscmd" : '.*->.*'` -ne 0 ]; then
>
> With native v
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Pádraig Brady on 10/14/2008 3:47 AM:
>> With native versions of expr, and expr from GNU coreutils prior to
>> version 7.0, the expansion of lscmd usually begins "-rw-r--r--", but
>> the leading hyphen does not cause the word to be treated
Ed Avis <[EMAIL PROTECTED]> wrote:
> Jim Meyering meyering.net> writes:
>
> [funky automake version numbers]
>
>>When in doubt, use sort -V from the latest coreutils:
>>
>>$ printf 'automake-1.10%s\n' .1 a|sort -V
>>automake-1.10.1
>>automake-1.10a
>
> That's not the result I get:
>
>
>> > > if [ ! " $lscmd" ]; then
>> That expression can never be true due to the additional space.
Thanks. We too caught that overzealous edit on my part shortly
after my posting to the bug-coreutils@gnu.org list, and fixed
it locally, using the -z test instead, just as you suggested.
-
There should be a quoted-printable en/decoder, to complement base64.
Let's see what I was using for all these.
#!/bin/sh -e
#jidanni *** replacement for mime-codecs package ***
case $0 in
*qp-encode)perl -MMIME::QuotedPrint -wne 'print encode_qp($_)';;
*qp-decode)perl -MMIME::Quote
I agree with a previous poster that the altered behaviour of expr in
coreutils-7.0 as a result of using getopt() for option parsing is
acceptable, and consistent with many other utilities, and with GNU and
POSIX interpretation of a double-hyphen option.
Here is another problem area with expr (in g
Nelson H. F. Beebe wrote:
> I agree with a previous poster that the altered behaviour of expr in
> coreutils-7.0 as a result of using getopt() for option parsing is
> acceptable, and consistent with many other utilities, and with GNU and
> POSIX interpretation of a double-hyphen option.
I don't ag
Bjoern Voigt wrote:
Hello,
as I played a bit with the "--color" option of "ls" I found, that some
values of "--color=WHEN" are undocumented.
The valid options of "--color=WHEN" are according to the source code
coreutils-7.0/src/ls.c:828:
static char const *const color_args[] =
{
Thanks for reporting that. Clearly it's a matlab bug. But just as
clearly, many scripts out there assume that "expr -1 + 1" evaluates to
zero. We shouldn't break them unnecessarily.
I looked at expr.c and have a somewhat radical suggestion. Let's remove
the --bignum and --no-bignum options, an
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Thanks for reporting that. Clearly it's a matlab bug. But just as
> clearly, many scripts out there assume that "expr -1 + 1" evaluates to
> zero. We shouldn't break them unnecessarily.
>
> I looked at expr.c and have a somewhat radical suggestion. Let's
26 matches
Mail list logo
