On 11/15/11 07:29, abdallah clark wrote:
Maybe it's a manpower issue
We are short of people and time, yes. I've found your
comments to be helpful in pointing out places where the
--help output (man pages) could be clearer. We've fixed the SIZE sentence
and I'd like to go onto the next issue.
On 11/15/11 08:36, Jim Meyering wrote:
Undoing it seems best.
OK, done.
Eric Blake wrote:
SIZE is an integer with an optional suffix (example: 10MB). Suffixes are:
KB 1000, K 1024, MB 1000*1000, M 1024*1024, and so on for G, T, P, E, Z, Y.
I didn't jump in the discussion yet, but personally also find the
multiplication confusing. I know, there's already been a
On 11/15/11 08:45, Voelker, Bernhard wrote:
-KB 1000, K 1024, MB 1000*1000, M 1024*1024, and so on for G, T, P, E, Z,
Y.\n\
+KB (1000), K (1024), MB (1000KB), M (1024K), and so on for G, T, P, E, Z,
Y.\n\
That would be fine with me. (I find them equally confusing. :-)
On Tue, 15 Nov 2011 16:28:35 -, Paul Eggert egg...@cs.ucla.edu wrote:
+ /* On GNU/Hurd hosts, getuid etc. can fail and return -1.
+ However, on GNU/Linux hosts, uid_t is an unsigned value and
+ getuid etc. can return the positive value (uid_t) -1. To
+ handle
On 11/15/2011 10:25 AM, Bjartur Thorlacius wrote:
On Tue, 15 Nov 2011 16:28:35 -, Paul Eggert egg...@cs.ucla.edu wrote:
+ /* On GNU/Hurd hosts, getuid etc. can fail and return -1.
+ However, on GNU/Linux hosts, uid_t is an unsigned value and
+ getuid etc. can return
Bjartur Thorlacius wrote:
Paul Eggert wrote:
+ /* On GNU/Hurd hosts, getuid etc. can fail and return -1.
+ However, on GNU/Linux hosts, uid_t is an unsigned value and
+ getuid etc. can return the positive value (uid_t) -1. To
+ handle both cases correctly,
Eric Blake wrote:
On 11/15/2011 10:25 AM, Bjartur Thorlacius wrote:
On Tue, 15 Nov 2011 16:28:35 -, Paul Eggert egg...@cs.ucla.edu wrote:
+ /* On GNU/Hurd hosts, getuid etc. can fail and return -1.
+ However, on GNU/Linux hosts, uid_t is an unsigned value and
+
On 11/15/2011 11:12 AM, Ruediger Meier wrote:
I also think the multiplier version is a bit easier to read.
My preferred one would be something like this:
-SIZE is an integer with an optional suffix (example: 10MB). Suffixes are:\n\
-KB 1000, K 1024, MB 1000*1000, M 1024*1024, and so on for
Jim Meyering wrote:
Eric Blake wrote:
Also, I tend to see etc. used primarily in the context of a list, when
at least two items have already been given (so that it is more obvious
what similar items have been omitted from the list). It's hard to see
what similar functions are implied
Eric Blake wrote:
On 11/15/2011 11:12 AM, Ruediger Meier wrote:
I also think the multiplier version is a bit easier to read.
My preferred one would be something like this:
-SIZE is an integer with an optional suffix (example: 10MB). Suffixes
are:\n\
-KB 1000, K 1024, MB 1000*1000, M
On 11/15/2011 11:25 AM, Bob Proulx wrote:
Perhaps it may be easier to read as:
On GNU/Hurd hosts, identification functions (getuid, getgid, etc.) can
fail and return -1.
I prefer that, too. Thanks.
Would you care to adjust it?
Perhaps the latin abbrevation can be removed here? I don't
Mike Frysinger wrote:
On Tuesday 15 November 2011 16:48:38 Jim Meyering wrote:
I've noticed a few references in recent commit logs like this:
See additional discussion in Bug#9939.
My preference has been to use the slightly more verbose
http://bugs.gnu.org/D, on the principle that
Hi Paul,
Paul Eggert egg...@cs.ucla.edu skribis:
- if (GETID_MAY_FAIL euid == -1 !use_real
+ if (euid 0 !use_real
!just_group !just_group_list !just_context)
error (EXIT_FAILURE, errno, _(cannot get effective UID));
On GNU/Hurd, no error would ever be
Gentlemen:
This situation is frustrating, but I'll exercise patience and comply.
May I suggest, first of all, that if someone tells you they don't
understand, trust them. If you were to show that SIZE paragraph to
someone in your families who were not familiar with *nix, then it may
be clearer
[please don't top-post on technical lists]
On 11/15/2011 08:29 AM, abdallah clark wrote:
So, here goes.
SIZE may be (or may be an integer optionally followed by) one
of following:
KB 1000, K 1024, MB 1000*1000, M 1024*1024, and so on for G, T,
P, E, Z, Y.
That's a run-on
Paul Eggert wrote:
On 11/15/11 08:45, Voelker, Bernhard wrote:
-KB 1000, K 1024, MB 1000*1000, M 1024*1024, and so on for G, T, P, E, Z,
Y.\n\
+KB (1000), K (1024), MB (1000KB), M (1024K), and so on for G, T, P, E, Z,
Y.\n\
That would be fine with me. (I find them equally confusing. :-)
On 11/15/2011 09:59 AM, Paul Eggert wrote:
On 11/15/11 05:07, Ludovic Courtès wrote:
On GNU/Hurd, no error would ever be raised (since uid_t is unsigned),
Ouch. Thanks, now I understand Roland's suggestion.
How about this patch instead?
else
{
+ /* POSIX says getuid etc.
Paul Eggert wrote:
On 11/15/11 05:07, Ludovic Courtès wrote:
On GNU/Hurd, no error would ever be raised (since uid_t is unsigned),
Ouch. Thanks, now I understand Roland's suggestion.
How about this patch instead?
id: handle (uid_t) -1 more portably
* src/id.c (GETID_MAY_FAIL): Remove.
On 11/15/11 09:10, Jim Meyering wrote:
I like that. Thanks!
You're welcome; I pushed it.
Similar fixes are needed for groups.c,
install.c, su.c, test.c, and whoami.c,
due to the possibility of getuid etc.
failing on GNU/Hurd.
I'll add this to my list of things to do, and
post a patch here,
On 11/15/2011 11:25 AM, Jim Meyering wrote:
Eric Blake wrote:
On 11/15/2011 11:12 AM, Ruediger Meier wrote:
I also think the multiplier version is a bit easier to read.
My preferred one would be something like this:
-SIZE is an integer with an optional suffix (example: 10MB). Suffixes
Seems like 'cc' didn't work...
Original Message
Subject:[sr #107876] ISSUE: (Unverifyed Bug in 8.13).
Date: Tue, 15 Nov 2011 18:28:13 +
From: Linda A. Walsh invalid.nore...@gnu.org
To: Linda A. Walsh g...@tlinx.org
URL:
Original Message
Subject: [sr #107875] BUG cp -u corrupts 'fs'' information if
interupted; can't recover on future invoctions
Date: Tue, 15 Nov 2011 17:58:23 +
From: Linda A. Walsh invalid.nore...@gnu.org
To: Linda A. Walsh
URL:
On Tuesday 15 November 2011, Eric Blake wrote:
On 11/15/2011 11:25 AM, Jim Meyering wrote:
Eric Blake wrote:
On 11/15/2011 11:12 AM, Ruediger Meier wrote:
I also think the multiplier version is a bit easier to read.
My preferred one would be something like this:
-SIZE is an integer
Thanks for your thoughtful suggestions.
I like many of the ideas and hope that somebody can find the time
to code them up. Here are some more-detailed comments.
On 11/15/11 11:07, Linda Walsh wrote:
3). use posix_fallocate (if available) to allocate sufficient space for the
copy
This seems
On 11/15/11 12:46, Linda A. Walsh wrote:
Better than leaving *doo doo* in a file
Sometimes, but not always. I can think of plausible cases where I'd
rather have a partial copy than no copy at all. As an extreme example,
if I'm doing 'cp /dev/tty A', I do not want A removed on interrupt
Paul Eggert wrote:
A) catch INT ( catchable signals), and remove any files that are
'incomplete'
That might cause trouble in other cases. For example, cp A B where
B already exists.
===
Am **only** suggesting this where 'B' has already been opened
and truncated by stuff being
Hmmm Dang strange processes on bugs... can't submit directly bug
can just by
emailing it to the email list? ... (bureaucracy!)
Linda Walsh wrote:
This should be filed under bugs, not under support, but it seems that
users of
the core utilis are ot allowed to find bugs...convenient.
I found yet-another tricky bug in that id.c code,
and fixed it as follows:
From 5ca593e87eb1361b4696dd1e002a8ee310a5d1f6 Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Tue, 15 Nov 2011 13:23:24 -0800
Subject: [PATCH] id: fix bug when euid != ruid
* src/id.c (main): Report an
On 11/15/2011 08:23 PM, Paul Eggert wrote:
Thanks for your thoughtful suggestions.
I like many of the ideas and hope that somebody can find the time
to code them up. Here are some more-detailed comments.
On 11/15/11 11:07, Linda Walsh wrote:
3). use posix_fallocate (if available) to
Paul Eggert wrote:
On 11/15/11 12:46, Linda A. Walsh wrote:
Better than leaving *doo doo* in a file
Sometimes, but not always. I can think of plausible cases where I'd
rather have a partial copy than no copy at all. As an extreme example,
if I'm doing 'cp /dev/tty A', I do not want A
On 11/15/2011 07:06 PM, Linda Walsh wrote:
Seems like 'cc' didn't work...
Original Message
Subject: [sr #107876] ISSUE: (Unverifyed Bug in 8.13).
Date: Tue, 15 Nov 2011 18:28:13 +
From: Linda A. Walsh invalid.nore...@gnu.org
To: Linda A. Walsh
On Tuesday 15 November 2011, Eric Blake wrote:
From e36e6f2c6e95d6e23be805f7bab6c596b1818d22 Mon Sep 17 00:00:00
[...]
-SIZE is an integer with an optional suffix (example: 10MB).
Suffixes are:\n\
-KB 1000, K 1024, MB 1000*1000, M 1024*1024, and so on for G, T, P,
E, Z, Y.\n\
+SIZE is an
[Thought I send out rspns to this, but can't find it in my outgo,
so...recomposing/sending,
sorry for delay)
On 11/15/11 12:46, Linda A. Walsh wrote:
Better than leaving *doo doo* in a file
Sometimes, but not always. I can think of plausible cases where I'd
rather have a partial
On 11/15/11 19:33, Linda A. Walsh wrote:
Why don't we
focus on the specific problem mentioned which was using it in the context of
the -u flag, (and with -a/-r and/or a wildcard), where you expect it to
update
contents of 'Dst' with 'Src'.
I'd rather not have a heuristic that says cp
Linda A. Walsh wrote:
Hmmm Dang strange processes on bugs... can't submit directly bug
can just by
emailing it to the email list? ... (bureaucracy!)
Linda Walsh wrote:
This should be filed under bugs, not under support, but it seems that users
of
the core utilis are ot allowed to
36 matches
Mail list logo
