Re: Possible bug with grep/sed/tail?

[Pádraig Brady]

Jim Meyering wrote:
> Pádraig Brady <[EMAIL PROTECTED]> wrote:
>> Jim Meyering wrote:
 What about adding buffer control to all coretuils filters.
 Is that still a desired feature do you think?
>>> I don't relish the idea of adding an option or feature
>>> to each and every filter in coreutils.  Especially
>>> considering that this approach solves the problem --
>>> albeit with requirement on gcc and LD_PRELOAD.
>>> Maybe we can relax that requirement...
>> A general tool would be much better than adding options
>> to all filters, hence why I originally asked to have this
>> added to glibc.
>>
>> I wonder would it be useful to have a "Modified command invocation"
>> command that set the LD_PRELOAD environment variable to point
>> to a lib installed, and also set other environment variables
>> to control the buffering depending on command line options.
>>
>> For example if we called the command stdbuf, then
>> the following pipeline would be line buffered:
>>
>> tail -f access.log | stdbuf --fd=1 --size=1 cut -d' ' -f1 | uniq
>>
>> size=0 => unbuffered
>> size=1 => line buffered
>> size>1 -> specific buffer size
>>
>> Also we could have aliases for stdin stdout, linebuffered, ...
>>
>> We still have the requirement on LD_PRELOAD, but
>> that's not too bad I think?
> 
> I like that.  The "stdbuf" name sounds fine, too.
> Though maybe use --size=-1 to indicate line buffering,
> (or even a separate --line-buffered option),
> rather than usurping --size=1.
> 
> Sounds like you've just volunteered ;-)

Um Ok so :)

Thinking a little more about it, the interface above
is probably a little too general.

I'm now thinking of 3 options: stdbuf -i -o -e
The usual use case is: stdbuf -ol
But you could also do: stdbuf -i4096 -o8192
We would warn about redundant combos like: stdbuf -il

Pádraig.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Possible bug with grep/sed/tail?

[Jim Meyering]

Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>> So -ol (that's an el) would mean line-buffered stdout?
>> That has to be equivalent to -o -l, and unless you consider
>> ordering and multiple -l options (e.g., "-i -l -o -l" is ugly),
>> then it doesn't let you line-buffer more than one of the three streams.
>
> It would be "+i::o::e::" in getopt parlance; no argument = no buffering,
> argument is "l" = line buffering, argument is numberic = given-size buffer.

Hi Paulo,

When designing new interfaces/tools, it's best to avoid that type of
optional argument.  This is partly a user interface consistency issue
(users are used to -il being equivalent to -i -l), and partly that it's
nonstandard: using "::" like that is a GNU getopt extension.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Possible bug with grep/sed/tail?

[Pádraig Brady]

Jim Meyering wrote:
> Pádraig Brady <[EMAIL PROTECTED]> wrote:
>>
>> I'm now thinking of 3 options: stdbuf -i -o -e
>> The usual use case is: stdbuf -ol
>> But you could also do: stdbuf -i4096 -o8192
>> We would warn about redundant combos like: stdbuf -il
> 
> So -ol (that's an el) would mean line-buffered stdout?
> That has to be equivalent to -o -l

Note -o would require an arg so it's unambiguous.
It's like `ls -w2` working and `ls -w -2` giving an error.

Perhaps it's a policy for lower case parameters
in case -l would ever be needed in future?
In that case would requiring a capital L as a parameter suffice?

> , and unless you consider
> ordering and multiple -l options (e.g., "-i -l -o -l" is ugly),
> then it doesn't let you line-buffer more than one of the three streams.
> 
> How about making -i -o -e mean line-buffered (--input --output --error),
> and -I N -O N -E N specify the less-common cases of no buffering
> or an N-byte buffer size? (--i-buf=N --o-buf=N --e-buf=N)

I'm conscious of making the modifier as unobtrusive as possible.
If we really need to use long options then could we just use:

stdbuf --o=L
stdbuf --i=4096 --o=8192

thanks,
Pádraig.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Possible bug with grep/sed/tail?

[Pádraig Brady]

Paolo Bonzini wrote:
> Jim Meyering wrote:
>> Paolo Bonzini <[EMAIL PROTECTED]> wrote:
 So -ol (that's an el) would mean line-buffered stdout?
 That has to be equivalent to -o -l, and unless you consider
 ordering and multiple -l options (e.g., "-i -l -o -l" is ugly),
 then it doesn't let you line-buffer more than one of the three streams.
>>> It would be "+i::o::e::" in getopt parlance; no argument = no buffering,
>>> argument is "l" = line buffering, argument is numberic = given-size buffer.
>> Hi Paulo,
>>
>> When designing new interfaces/tools, it's best to avoid that type of
>> optional argument.  This is partly a user interface consistency issue
>> (users are used to -il being equivalent to -i -l), and partly that it's
>> nonstandard: using "::" like that is a GNU getopt extension.
> 
> I was just trying to interpret the specification given in the other
> message (not written by me), which I kind of like even though I
> understand your point.  The worse problem, I think, is more that users
> are used to "-io" being equivalent to "-i -o", and "::" does not support
> that.
> 
> Instead of "-il" you could use "-i-" for line buffering ("buffer as if
> the console was the input", and "-" i.e. stdin is often the console),
> but that does not fix the non-standardness of optional arguments and the
> fact that "-io" unintuitively does not work.  I still kind of like the
> syntax, though.

-o- is a neat suggestion to mean line buffering.
However it's ambiguous as stdin and stderr are not line buffered
when connected to a terminal.

Pádraig.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Possible bug with grep/sed/tail?

[Jim Meyering]

Pádraig Brady <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> Pádraig Brady <[EMAIL PROTECTED]> wrote:
>>>
>>> I'm now thinking of 3 options: stdbuf -i -o -e
>>> The usual use case is: stdbuf -ol
>>> But you could also do: stdbuf -i4096 -o8192
>>> We would warn about redundant combos like: stdbuf -il
>>
>> So -ol (that's an el) would mean line-buffered stdout?
>> That has to be equivalent to -o -l
>
> Note -o would require an arg so it's unambiguous.
> It's like `ls -w2` working and `ls -w -2` giving an error.

Oh, then yes, that'd work.

> Perhaps it's a policy for lower case parameters
> in case -l would ever be needed in future?
> In that case would requiring a capital L as a parameter suffice?
>
>> , and unless you consider
>> ordering and multiple -l options (e.g., "-i -l -o -l" is ugly),
>> then it doesn't let you line-buffer more than one of the three streams.
>>
>> How about making -i -o -e mean line-buffered (--input --output --error),
>> and -I N -O N -E N specify the less-common cases of no buffering
>> or an N-byte buffer size? (--i-buf=N --o-buf=N --e-buf=N)
>
> I'm conscious of making the modifier as unobtrusive as possible.
> If we really need to use long options then could we just use:
>
> stdbuf --o=L
> stdbuf --i=4096 --o=8192

Good idea to use capital 'L'.
Please provide both short and long options.
The usual --help would look something like this:

  -i, --input=L_or_SIZE  ...description...
  -o, --ouput=L_or_SIZE  ...
  -e, --error=L_or_SIZE  ...

Then you can use any of -i L, -iL, or --input=L


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Possible bug with grep/sed/tail?

[Jim Meyering]

Pádraig Brady <[EMAIL PROTECTED]> wrote:
...
>>> tail -f access.log | stdbuf --fd=1 --size=1 cut -d' ' -f1 | uniq
>>>
>>> size=0 => unbuffered
>>> size=1 => line buffered
>>> size>1 -> specific buffer size
>>>
>>> Also we could have aliases for stdin stdout, linebuffered, ...
>>>
>>> We still have the requirement on LD_PRELOAD, but
>>> that's not too bad I think?
>>
>> I like that.  The "stdbuf" name sounds fine, too.
>> Though maybe use --size=-1 to indicate line buffering,
>> (or even a separate --line-buffered option),
>> rather than usurping --size=1.
>>
>> Sounds like you've just volunteered ;-)
>
> Um Ok so :)

Good!

> Thinking a little more about it, the interface above
> is probably a little too general.
>
> I'm now thinking of 3 options: stdbuf -i -o -e
> The usual use case is: stdbuf -ol
> But you could also do: stdbuf -i4096 -o8192
> We would warn about redundant combos like: stdbuf -il

So -ol (that's an el) would mean line-buffered stdout?
That has to be equivalent to -o -l, and unless you consider
ordering and multiple -l options (e.g., "-i -l -o -l" is ugly),
then it doesn't let you line-buffer more than one of the three streams.

How about making -i -o -e mean line-buffered (--input --output --error),
and -I N -O N -E N specify the less-common cases of no buffering
or an N-byte buffer size? (--i-buf=N --o-buf=N --e-buf=N)


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Possible bug with grep/sed/tail?

[Paolo Bonzini]

Jim Meyering wrote:
> Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>>> So -ol (that's an el) would mean line-buffered stdout?
>>> That has to be equivalent to -o -l, and unless you consider
>>> ordering and multiple -l options (e.g., "-i -l -o -l" is ugly),
>>> then it doesn't let you line-buffer more than one of the three streams.
>> It would be "+i::o::e::" in getopt parlance; no argument = no buffering,
>> argument is "l" = line buffering, argument is numberic = given-size buffer.
> 
> Hi Paulo,
> 
> When designing new interfaces/tools, it's best to avoid that type of
> optional argument.  This is partly a user interface consistency issue
> (users are used to -il being equivalent to -i -l), and partly that it's
> nonstandard: using "::" like that is a GNU getopt extension.

I was just trying to interpret the specification given in the other
message (not written by me), which I kind of like even though I
understand your point.  The worse problem, I think, is more that users
are used to "-io" being equivalent to "-i -o", and "::" does not support
that.

Instead of "-il" you could use "-i-" for line buffering ("buffer as if
the console was the input", and "-" i.e. stdin is often the console),
but that does not fix the non-standardness of optional arguments and the
fact that "-io" unintuitively does not work.  I still kind of like the
syntax, though.

Paolo


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Possible bug with grep/sed/tail?

[Paolo Bonzini]

> So -ol (that's an el) would mean line-buffered stdout?
> That has to be equivalent to -o -l, and unless you consider
> ordering and multiple -l options (e.g., "-i -l -o -l" is ugly),
> then it doesn't let you line-buffer more than one of the three streams.

It would be "+i::o::e::" in getopt parlance; no argument = no buffering,
argument is "l" = line buffering, argument is numberic = given-size buffer.

Paolo


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: "du -b --files0-from=-" running out of memory

[Jim Meyering]

Jim Meyering <[EMAIL PROTECTED]> wrote:
> Eric Blake <[EMAIL PROTECTED]> wrote:
>> According to Barry Kelly on 11/23/2008 6:24 AM:
>>> I have a problem with du running out of memory.
>>>
>>> I'm feeding it a list of null-separated file names via standard input,
>>> to a command-line that looks like:
>>>
>>>   du -b --files0-from=-
>
> du's --files0-from option reads the entire list of
> file names into memory before processing the first name.

[By the way, this flaw affects wc and sort, too, since
 they have the same --files0-from option and use nearly
 identical code.  Hence the fixes you see below for du.c will
 soon be applied to those other programs.  ]

Here's how the fixed du performs,
operating on a directory produced like this:

  mkdir du-test && cd du-test
  seq --format=%032g 6|xargs touch

I ran du like this:

  for f in new old; do
find . -type f -print0|valgrind --tool=massif \
  --massif-out-file=m.$f -- du.$f -a --files0-from=- > out.$f
  done

The difference is striking:
  old peak usage 21MB
  new peak usage just 12 *KB*




Command:du.old -a --files0-from=-
Massif arguments:   --massif-out-file=m.old
ms_print arguments: m.old



MB
21.21^   #
 |   #: .
 |   #: :.
 |   #: :::
 |   #: ::: : .
 |   #: ::: : : .
 |  .#: ::: : : : .
 |  :#: ::: : : : : .
 |  :#: ::: : : : : : .
 |  :#: ::: : : : : : : .
 |  :#: ::: : : : : : : :.
 |  :#: ::: : : : : : : :: .
 |: :#: ::: : : : : : : :: : .
 |: :#: ::: : : : : : : :: : : .
 |: :#: ::: : : : : : : :: : : :::.
 |: :#: ::: : : : : : : :: : : .
 |  ,   @.: :#: ::: : : : : : : :: : : ::,
 |.., .:@:: @:: :#: ::: : : : : : : :: : : ::@
 |   . .. ::@ ::@:: @:: :#: ::: : : : : : : :: : : ::@
 | ..,.@:: : : :: ::@ ::@:: @:: :#: ::: : : : : : : :: : : ::@
   0 +--->Mi
 0   266.3

Number of snapshots: 55
 Detailed snapshots: [3, 6, 8, 21, 24, 27, 31 (peak), 54]









Command:du.new -a --files0-from=-
Massif arguments:   --massif-out-file=m.new
ms_print arguments: m.new



KB
12.88^,   .  :  :.   :.:
 |# : ::::.:.   ::@::@::@:. ::@: :::  .::.
 |# : ::::  ::@::@::@::   @:  .:@:::   ..:
 |# : ::::  ::@::@::@::   @:  ::@:::   :::
 |# : ::::  ::@::@::@::   @:  ::@:::   :::
 |# : ::::  ::@::@::@::   @:  ::@:::   :::
 |# : ::::  ::@::@::@::   @:  ::@:::   :::
 |# : ::::  ::@::@::@::   @:  ::@:::   :::
 |# : :::: :::@::@::@::   @:  ::@:::   :@:
 |# : ::.:.::: :::@::@::@::.,.@:..::@:::..,:@:
 |# :  :::@::@::@:::@:@:@:@:@:
 |# :  :::@::@::@:::@:@:@:@:@:
 |# :  :::@::@::@:::@:@:@:@:@:
 |# :  :::@::@::@:::@:@:@:@:@:
 |# :  :::@::@::@:::@:@:@:@:@:
 |# :  :::@::@::@:::@:@:@:@:@:
 |# :  :::@::@::@:::@:@:@:@:@:
 |# :  :::@::@::@:::@:@:@:@:@:
 |# :  :::@::@::@:::@:@:@:@:@:
 |# :  :::@::@::@:::@:@:@:@:@:
   0 +--->Mi
 0   231.5

Number of snapshots: 97
 Detailed snapshots: [1 (peak), 26, 29, 34, 54, 64, 74, 84, 94]


Here's the patch.
I'll probably push it tomorrow.

>From 318543c4478d1b7833c9ff6b46974cd262bcf5d4 Mon Sep 17 00:00:00 20

Re: "du -b --files0-from=-" running out of memory

[Pádraig Brady]

Jim Meyering wrote:
> Subject: [PATCH 1/2] argv-iter: new module
> 
> * gl/lib/argv-iter.h: New file.
> * gl/lib/argv-iter.c: New file.
> * gl/modules/argv-iter: New file.

Very useful module!

I see that --files0-from was added to `du` in Mar 2004,
so it's a nice solution to this 4 year old issue.

I notice that argv_iter does a malloc() + memcpy() per entry.
Since the sources are already NUL terminated strings
perhaps it could just return a pointer to a getdelim
realloc'd buffer which was referenced in the argv_iterator struct.

cheers,
Pádraig.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: "du -b --files0-from=-" running out of memory

[Jim Meyering]

Pádraig Brady <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> Subject: [PATCH 1/2] argv-iter: new module
>>
>> * gl/lib/argv-iter.h: New file.
>> * gl/lib/argv-iter.c: New file.
>> * gl/modules/argv-iter: New file.
>
> Very useful module!
>
> I see that --files0-from was added to `du` in Mar 2004,
> so it's a nice solution to this 4 year old issue.

Thanks.
I'm surprised it took so long to bite.

> I notice that argv_iter does a malloc() + memcpy() per entry.
> Since the sources are already NUL terminated strings
> perhaps it could just return a pointer to a getdelim
> realloc'd buffer which was referenced in the argv_iterator struct.

The only per-entry allocation I see is:
  - in argv-mode: strdup
  - in stream-reading mode: getdelim

Did I miss something?

char *
argv_iter (struct argv_iterator *ai, enum argv_iter_err *err)
{
  if (ai->fp)
{
  char *name = NULL;
  size_t buf_len = 0;
  ssize_t len = getdelim (&name, &buf_len, '\0', ai->fp);
  if (len < 0)
{
  free (name);
  *err = feof (ai->fp) ? AI_ERR_EOF : AI_ERR_READ;
  return NULL;
}

  *err = AI_ERR_OK;
  ai->item_idx++;
  return name;
}
  else
{
  if (*(ai->p) == NULL)
{
  *err = AI_ERR_EOF;
  return NULL;
}
  else
{
  *err = AI_ERR_OK;
  return strdup (*(ai->p++));
}
}
}


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: "du -b --files0-from=-" running out of memory

[Pádraig Brady]

Jim Meyering wrote:
> Pádraig Brady <[EMAIL PROTECTED]> wrote:
>> Jim Meyering wrote:
>>> Subject: [PATCH 1/2] argv-iter: new module
>>>
>>> * gl/lib/argv-iter.h: New file.
>>> * gl/lib/argv-iter.c: New file.
>>> * gl/modules/argv-iter: New file.
>> Very useful module!
>>
>> I see that --files0-from was added to `du` in Mar 2004,
>> so it's a nice solution to this 4 year old issue.
> 
> Thanks.
> I'm surprised it took so long to bite.
> 
>> I notice that argv_iter does a malloc() + memcpy() per entry.
>> Since the sources are already NUL terminated strings
>> perhaps it could just return a pointer to a getdelim
>> realloc'd buffer which was referenced in the argv_iterator struct.
> 
> The only per-entry allocation I see is:
>   - in argv-mode: strdup
>   - in stream-reading mode: getdelim
> 
> Did I miss something?

Sorry I was unclear.
strdup() and getdelim(NULL,...) do a malloc() + memcpy()
if you maintain the char* name and size_t buf_len in
the argv_iterator struct, then you can return pointers
to the orig data, and remove the need to free() from the
users of argv_iter().

Pádraig.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: "du -b --files0-from=-" running out of memory

[Jim Meyering]

Pádraig Brady <[EMAIL PROTECTED]> wrote:
>>> I notice that argv_iter does a malloc() + memcpy() per entry.
>>> Since the sources are already NUL terminated strings
>>> perhaps it could just return a pointer to a getdelim
>>> realloc'd buffer which was referenced in the argv_iterator struct.
>>
>> The only per-entry allocation I see is:
>>   - in argv-mode: strdup
>>   - in stream-reading mode: getdelim
>>
>> Did I miss something?
>
> Sorry I was unclear.
> strdup() and getdelim(NULL,...) do a malloc() + memcpy()
> if you maintain the char* name and size_t buf_len in
> the argv_iterator struct, then you can return pointers
> to the orig data, and remove the need to free() from the
> users of argv_iter().

Good suggestion!  Thanks.

diff --git a/gl/lib/argv-iter.c b/gl/lib/argv-iter.c
index 204769a..adaff6f 100644
--- a/gl/lib/argv-iter.c
+++ b/gl/lib/argv-iter.c
@@ -28,6 +28,8 @@ struct argv_iterator
   /* file-mode: fp records position */
   FILE *fp;
   size_t item_idx;
+  char *tok;
+  size_t buf_len;

   /* argv-mode: record just argv and current pointer */
   char **arg_list;
@@ -55,6 +57,9 @@ argv_iter_init_stream (FILE *fp)
   if (!ai)
 return NULL;
   ai->fp = fp;
+  ai->tok = NULL;
+  ai->buf_len = 0;
+
   ai->item_idx = 0;
   ai->arg_list = NULL;
   return ai;
@@ -65,19 +70,16 @@ argv_iter (struct argv_iterator *ai, enum argv_iter_err 
*err)
 {
   if (ai->fp)
 {
-  char *name = NULL;
-  size_t buf_len = 0;
-  ssize_t len = getdelim (&name, &buf_len, '\0', ai->fp);
+  ssize_t len = getdelim (&ai->tok, &ai->buf_len, '\0', ai->fp);
   if (len < 0)
 {
-  free (name);
   *err = feof (ai->fp) ? AI_ERR_EOF : AI_ERR_READ;
   return NULL;
 }

   *err = AI_ERR_OK;
   ai->item_idx++;
-  return name;
+  return ai->tok;
 }
   else
 {
@@ -89,7 +91,7 @@ argv_iter (struct argv_iterator *ai, enum argv_iter_err *err)
   else
 {
   *err = AI_ERR_OK;
-  return strdup (*(ai->p++));
+  return *(ai->p++);
 }
 }
 }
@@ -103,6 +105,8 @@ argv_iter_n_args (struct argv_iterator const *ai)
 void
 argv_iter_free (struct argv_iterator *ai)
 {
+  if (ai->fp)
+free (ai->tok);
   free (ai);
 }

diff --git a/src/du.c b/src/du.c
index 5ed2b12..a1345a7 100644
--- a/src/du.c
+++ b/src/du.c
@@ -968,7 +968,7 @@ main (int argc, char **argv)
case AI_ERR_READ:
  error (0, errno, _("%s: read error"), quote (files_from));
  skip_file = true;
- goto next_file_name;
+ continue;

case AI_ERR_MEM:
  xalloc_die ();
@@ -1016,9 +1016,6 @@ main (int argc, char **argv)
  temp_argv[0] = file_name;
  ok &= du_files (temp_argv, bit_flags);
}
-
-next_file_name:;
-  free (file_name);
 }

   argv_iter_free (ai);


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

[bug #24934] confusing description of -c option

[anonymous]

URL:
  

 Summary: confusing description of -c option
 Project: GNU Core Utilities
Submitted by: None
Submitted on: Tue 25 Nov 2008 11:38:19 PM UTC
Category: None
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

-c option's info documentation states:
`-c BYTES'
`--bytes=BYTES'
 Output the last BYTES bytes, instead of final lines.  However, if
 N starts with a `+', start printing with the Nth byte from the
 start of each file, instead of from the end.  Appending `b'
 multiplies BYTES by 512, `kB' by 1000, `K' by 1024, `MB' by
 1000*1000, `M' by 1024*1024, `GB' by 1000*1000*1000, `GB' by
 1024*1024*1024, and so on for `T', `P', `E', `Z', and `Y'.
-
it is not clear in here what "N" stands for?
Maybe the author wanted to write "BYTES" instead of "N"?

this is in file [coreutils.git] / doc / coreutils.texi




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

[bug #24935] incorrect information regardin size suffixes in -c option

[anonymous]

URL:
  

 Summary: incorrect information regardin size suffixes in -c
option
 Project: GNU Core Utilities
Submitted by: None
Submitted on: Tue 25 Nov 2008 11:46:55 PM UTC
Category: None
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

When describing -c option for tail command it says:

`-c BYTES'
`--bytes=BYTES'
 Output the last BYTES bytes, instead of final lines.  However, if
 N starts with a `+', start printing with the Nth byte from the
 start of each file, instead of from the end.  Appending `b'
 multiplies BYTES by 512, `kB' by 1000, `K' by 1024, `MB' by
 1000*1000, `M' by 1024*1024, `GB' by 1000*1000*1000, `GB' by
 1024*1024*1024, and so on for `T', `P', `E', `Z', and `Y'.

in here 'GB' is equivalent to 1000*1000*1000 and 1024*1024*1024
which is impossible.

this is in file [coreutils.git] / doc / coreutils.texi for tail
documentation.




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

bug report

[Gordon, John (SAIC) (c)]

ran ./configure on coreutils 6.12 and got the following

configure: WARNING: sys/wait.h: present but cannot be compiled
configure: WARNING: sys/wait.h: check for missing prerequisite
headers?
configure: WARNING: sys/wait.h: see the Autoconf documentation
configure: WARNING: sys/wait.h: section "Present But Cannot Be
Compiled"
configure: WARNING: sys/wait.h: proceeding with the preprocessor's
result
configure: WARNING: sys/wait.h: in the future, the compiler will take
precedence
configure: WARNING: ##  ##
configure: WARNING: ## Report this to bug-coreutils@gnu.org ##
configure: WARNING: ##  ##

___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: [PATCH]: ls: add --user-format option for user defined format

[martin f krafft]

Hey,

just chiming in, since Jim alerted me to this thread after
I recently filed http://bugs.debian.org/505979. I think, printf-like
functionality would be very useful to have for very much the same
reasons quoted in this thread, so I won't repeat them here.

The issue Jim raises -- bloat -- is surely a valid one, but I don't
think there's a way around it. Bloat comes with two immediate
dangers: larger size, which isn't really a problem given today's
computation power and storage sizes, and manageability/security.

printf-like functionality in ls is a worthwhile feature, I don't
think there's a debate about that. The question is how to get there.
I think it's either bloating the code and making it work, then
slowly fading out other options which can be nicely implemented with
the new printf-code, or the other way around: rewriting most options
from scratch to use a common printf-infrastructure.

The latter option surely allows for better design, but it's also
guaranteed to take longer and introduce new bugs. The first option,
on the other hand, is based on minimal changes, which are a more
sustainable way forward, given the age and maturity of ls, I think.

In my (possibly not-so) humble opinion, this is separate from fts
tree traversal.

-- 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>  Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"the strength of women comes from the fact
 that psychology cannot explain us.
 men can be analyzed, women merely adored."
-- oscar wilde


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: bug report

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Gordon, John (SAIC) (c) on 11/25/2008 12:58 PM:
> ran ./configure on coreutils 6.12 and got the following
> 
> configure: WARNING: sys/wait.h: present but cannot be compiled
> configure: WARNING: sys/wait.h: check for missing prerequisite
> headers?
> configure: WARNING: sys/wait.h: see the Autoconf documentation
> configure: WARNING: sys/wait.h: section "Present But Cannot Be
> Compiled"

Thanks for the report.  Can you please post the relevant sections of your
config.log (if you don't know which section is relevant, posting the full
file is acceptable, although if it is large, you may want to gzip it
first).  What platform is this on?  Would you mind trying again with a
recent snapshot, to see if it has been fixed in the meantime?
http://lists.gnu.org/archive/html/bug-coreutils/2008-11/msg00096.html

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkss6YACgkQ84KuGfSFAYB2vwCdGZiFpobvEq6LWGCXAnffO32q
1ykAoMEZ9Zt3Xvj1H8+5AvliUzhiiURV
=5N4u
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

sys/wait on Solaris (was: bug report)

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[Please keep the list in the loop; also, a more descriptive subject is
helpful]

According to Gordon, John (SAIC) (c) on 11/25/2008 7:43 PM:
> it's a Sparc Solaris 10.
> if you need specifics, send me the commands you want me to run.
> i'll look for the log tomorrow and will also try a snapshot.
> thanks for the reply.

Right now, the most helpful information is the config.log output.
However, I know Jim has tested recent snapshots on a Solaris 10 machine,
so there is a good chance it has been fixed in the meantime.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkksuqwACgkQ84KuGfSFAYAULwCfV3mmWkf0bpEvfbR9eZ/kqPig
DCAAnj0pGb+8yENq39IfPBabsjI8Bv/h
=97H1
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

what a pitiful explanation for sha1sum

[landon kelsey]

_
Access your email online and on the go with Windows Live Hotmail.
http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_access_112008___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: what a pitiful explanation for sha1sum

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to landon kelsey on 11/25/2008 9:30 PM:
> 
> 

Thanks for the report, I guess.  Unfortunately, the body of your message
is blank, and the subject doesn't quite tell us what you think is wrong
with sha1sum.  Would you care to elaborate?

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkks0+UACgkQ84KuGfSFAYA/2QCeJOV6BDTi29Ygs0WtDJNTyFfH
P2oAnj4VEJO50Q2RLn5ksyrot4382YtS
=OuIo
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils