Re: RFC: changing the "+" in ls -l output to be "." or "+"
Vikram Noel Ambrose <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> wrote: ... if (SELinux, with no other MAC or ACL) use '.' else if (any other combination of alternate access methods) use '+' ... >>> Here's sample output, running on an SELinux system: >>> >>> $ src/ls -ldgo [ac]* >>> -rw-r--r--. 1 42625 2008-04-02 19:31 aclocal.m4 >>> drwxr-xr-x. 24096 2008-04-02 19:31 autom4te.cache >>> -rw-r--r--. 11597 2008-03-21 16:35 cfg.mk >>> -rw-r--r--. 1 1417195 2008-04-02 19:33 config.log >>> -rwxr-xr-x. 1 71225 2008-04-02 19:33 config.status >>> -rwxr-xr-x. 1 1846424 2008-04-02 19:31 configure >>> -rw-r--r--. 1 12014 2008-03-25 23:55 configure.ac >>> > > This is so confusing. What is so horribly wrong with a capital S for > SELinux or A for ACL? A desire for compatibility makes "+" look good. "." is appealing for SELinux-only because it's inconspicuous. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: "mkdir -p" in Makefile fails with installwatch of checkinstall in Mandriva 2009.0
vatbier <[EMAIL PROTECTED]> wrote: > Description of problem: > Mandriva 2009.0. > I use checkinstall to make an .rpm of x11vnc-0.9.4 > (http://www.karlrunge.com/x11vnc/ ): > ./configure > make > checkinstall > Checkinstall fails because the command "mkdir -p" in a Makefile fails with > installwatch of checkinstall. > > Output of checkininstall: > test -z "/usr/local/bin" || mkdir -p -- "/usr/local/bin" > /usr/bin/install -c 'x11vnc' '/usr/local/bin/x11vnc' > test -z "/usr/local/man/man1" || mkdir -p -- "/usr/local/man/man1" > mkdir: cannot create directory "/usr/local/man": No such file or directory > make[3]: *** [install-man1] Error 1 Thanks for the report, but this is not a problem with install, but rather with whatever DLL you're using -- it sounds like it's from installwatch. If you can produce such a failure in mkdir without setting LD_PRELOAD, then *that* would be a bug in coreutils' install. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: RFC: changing the "+" in ls -l output to be "." or "+"
Jim Meyering wrote: A desire for compatibility makes "+" look good. "." is appealing for SELinux-only because it's inconspicuous. Speaking as a fairly new SELinux user/admin, having a "." next to every file in my ls output is just as useful or non-useful as having a "+" next to them, so does it really buy anything? I end up needing -Z either way. Based on the kind of real-world problems I've had, the most useful thing ls could tell me about a file on my SELinux system would be that it *should* have a label and *doesn't*, something like: if ( selinux_enabled ) if ( label == NULL || label == fs.defaultlabel ) use "!" else use " " else if ( anything else ) use "+" ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: RFC: changing the "+" in ls -l output to be "." or "+"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Mike Edenfield on 10/24/2008 7:19 AM: > Based on the kind of real-world problems I've had, the most useful thing > ls could tell me about a file on my SELinux system would be that it > *should* have a label and *doesn't*, something like: > > if ( selinux_enabled ) > if ( label == NULL || label == fs.defaultlabel ) > use "!" > else > use " " Unfortunately, that would violate POSIX, which requires ' ' in the case when no alternate access controls are in force. And SELinux contexts count as an alternate access control. "The shall be a single if there is no alternate or additional access control method associated with the file; otherwise, a printable character shall be used." http://www.opengroup.org/onlinepubs/009695399/utilities/ls.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 iEYEARECAAYFAkkBzw8ACgkQ84KuGfSFAYCXAACeN4uUaHlCuBXUMFeJLsBDyShJ AGIAniTtjas6Urnz/P92Vhr/JFx19oZC =ibH3 -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH]: chmod - do inform about using different mode than requested with SGID/SUID/sticky bits without permissions to change them
Hello,
as reported in
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/187315 by Aaron
Toponce , chmod could display confusing messages when used for
SGID/SUID/sticky bits without permissions to change them.
e.g. with non-root sudoers user following scenario
mkdir tmp;sudo chown .root tmp;ls -ld tmp;chmod -v 2755 tmp;ls -ld tmp;
would lead to:
drwxrwxr-x 2 Reset root 4096 24. říj 17.33 tmp
mode of `tmp' changed to 2755 (rwxr-sr-x)
drwxr-xr-x 2 Reset root 4096 24. říj 17.33 tmp
So user is informed that sticky bit was set even if it was not.
After my patch output will be:
drwxrwxr-x 2 Reset root 4096 24. říj 17.35 tmp
can't change mode of `tmp' to 2755 (rwxr-sr-x), using 0755 (rwxr-xr-x)
mode of `tmp' changed to 0755 (rwxr-xr-x)
drwxr-xr-x 2 Reset root 4096 24. říj 17.35 tmp
That should reduce user's confusion and clarify what's really done by
chmod command.
Greetings,
Ondřej Vašík
From 4eaf35f250ab6eec036b7ab21a482a76289f8303 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Ond=C5=99ej=20Va=C5=A1=C3=ADk?= <[EMAIL PROTECTED]>
Date: Fri, 24 Oct 2008 17:24:09 +0200
Subject: [PATCH] chmod: inform in verbose if used mode for chmod was different than requested
* chmod (process_file): Display a message when SUID, SGID or sticky bit change
was requested but not performed. Suggested by Aaron Toponce
* NEWS: Mention that change.
---
NEWS|3 +++
src/chmod.c | 37 +++--
2 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/NEWS b/NEWS
index 3fc0349..86f415b 100644
--- a/NEWS
+++ b/NEWS
@@ -23,6 +23,9 @@ GNU coreutils NEWS-*- outline -*-
Rm was improved directly, while the others inherit the improvement
from the newer version of fts in gnulib.
+ chmod now displays a message when SUID, SGID or sticky bit change was
+ requested, but not performed.
+
comm now verifies that the inputs are in sorted order. This check can
be turned off with the --nocheck-order option.
diff --git a/src/chmod.c b/src/chmod.c
index 80fc363..87f8199 100644
--- a/src/chmod.c
+++ b/src/chmod.c
@@ -259,8 +259,41 @@ process_file (FTS *fts, FTSENT *ent)
if (verbosity != V_off)
{
- bool changed = (chmod_succeeded
- && mode_changed (file, old_mode, new_mode));
+ bool mode_change = mode_changed (file, old_mode, new_mode);
+ bool changed = (chmod_succeeded && mode change);
+
+ if (chmod_succeeded && ((old_mode ^ new_mode) & CHMOD_MODE_BITS))
+{
+
+ /* Changed to another mode than requested */
+ struct stat new_stats;
+ char perms_requested[12];
+ char perms_actual[12];
+
+ if (stat (file, &new_stats) != 0)
+{
+ if (!force_silent)
+error (0, errno, _("getting new attributes of %s"),
+ quote (file));
+ ok = false;
+}
+
+ strmode (new_mode, perms_requested);
+ perms_requested[10] = '\0';
+ strmode (new_stats.st_mode, perms_actual);
+ perms_actual[10] = '\0';
+ printf(
+_("can't change mode of %s to %04lo (%s), using %04lo (%s)\n"),
+quote (file),
+(unsigned long int) (new_mode & CHMOD_MODE_BITS),
+&perms_requested[1],
+(unsigned long int) (new_stats.st_mode & CHMOD_MODE_BITS),
+&perms_actual[1]);
+
+/* Change mode to actual mode after change for verbose output */
+new_mode = new_stats.st_mode;
+ }
+
if (changed || verbosity == V_high)
{
--
1.5.6.1.156.ge903b
signature.asc
Description: Toto je digitálně podepsaná část zprávy
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
group-list warning
During the window of buggy autoconf, I saw this evidence of a latent bug for platforms that lack getgroups: group-list.c: In function `print_group_list': group-list.c:89: warning: control reaches end of non-void function OK to commit? From: Eric Blake <[EMAIL PROTECTED]> Date: Fri, 24 Oct 2008 11:42:29 -0600 Subject: [PATCH] group-list: avoid compiler warning * src/group-list.c (print_group_list) [!HAVE_GETGROUPS]: Always return value. --- src/group-list.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/group-list.c b/src/group-list.c index 96438d9..3547ed6 100644 --- a/src/group-list.c +++ b/src/group-list.c @@ -83,9 +83,9 @@ print_group_list (const char *username, ok = false; } free (groups); -return ok; } #endif /* HAVE_GETGROUPS */ + return ok; } -- 1.6.0.2 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: group-list warning
Eric Blake <[EMAIL PROTECTED]> wrote: > During the window of buggy autoconf, I saw this evidence of a latent bug for > platforms that lack getgroups: > > group-list.c: In function `print_group_list': > group-list.c:89: warning: control reaches end of non-void function > > OK to commit? > > From: Eric Blake <[EMAIL PROTECTED]> > Date: Fri, 24 Oct 2008 11:42:29 -0600 > Subject: [PATCH] group-list: avoid compiler warning > > * src/group-list.c (print_group_list) [!HAVE_GETGROUPS]: Always return value. Good one ;-) Please do. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
remove --bignum from 'factor'
Here's a patch to remove the --bignum and --no-bignum options from
'factor'. The case for removing --bignum isn't as strong as that for
'expr', but still, it seems to me that these options are not needed and
complicate the documentation unnecessarily.
Remove --bignum and --no-bignum from 'factor'.
* doc/coreutils.texi (factor invocation): Remove --bignum, --no-bignum.
* src/factor.c (algorithm, ALGORITHM_CHOICE, USE_BIGNUM, NO_USE_BIGNUM):
Remove; all uses removed.
(extract_factors_multi): Remove, replacing with
(print_factors_multi): New function, with signature similar to that
of new signature of print_factors_single.
(print_factors_single): Migrate checking code to caller.
(print_factors): Use GMP if it's available; don't bother asking user.
Improve accuracy of check for "large" numbers.
(long_options, main): Remove support for --bignum.
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 6459870..9c02428 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -14652,15 +14652,6 @@ The @command{factor} command supports only a small
number of options:
Print a short help on standard output, then exit without further
processing.
[EMAIL PROTECTED] --bignum
-Always use unlimited precision arithmetic via the GNU MP library.
-By default, @command{factor} selects between using GNU MP and using
-native operations on the basis of the length of the number to be factored.
-
[EMAIL PROTECTED] --no-bignum
-Always use limited-precision native operations, not GNU MP.
-This causes @command{factor} to fail for larger inputs.
-
@item --version
Print the program version on standard output, then exit without further
processing.
diff --git a/src/factor.c b/src/factor.c
index 7d0a7eb..8ccefd5 100644
--- a/src/factor.c
+++ b/src/factor.c
@@ -49,15 +49,6 @@
static bool verbose = false;
-typedef enum
- {
-ALGO_AUTOSELECT, /* default */
-ALGO_GMP, /* --bignum */
-ALGO_SINGLE/* --no-bignum */
- } ALGORITHM_CHOICE;
-static ALGORITHM_CHOICE algorithm = ALGO_AUTOSELECT;
-
-
#if HAVE_GMP
static mpz_t *factor = NULL;
static size_t nfactors_found = 0;
@@ -266,52 +257,6 @@ S4:
mpz_clear (x);
mpz_clear (y);
}
-
-/* Arbitrary-precision factoring */
-static bool
-extract_factors_multi (char const *s)
-{
- unsigned int division_limit;
- size_t n_bits;
- mpz_t t;
-
- mpz_init (t);
- if (1 != gmp_sscanf (s, "%Zd", t))
-{
- error (0, 0, _("%s is not a valid positive integer"), quote (s));
- return false;
-}
-
- printf ("%s:", s);
-
- if (mpz_sgn (t) == 0)
-{
- mpz_clear (t);
- return true; /* 0; no factors */
-}
-
- /* Set the trial division limit according to the size of t. */
- n_bits = mpz_sizeinbase (t, 2);
- division_limit = MIN (n_bits, 1000);
- division_limit *= division_limit;
-
- factor_using_division (t, division_limit);
-
- if (mpz_cmp_ui (t, 1) != 0)
-{
- debug ("[is number prime?] ");
- if (mpz_probab_prime_p (t, 3))
- {
- emit_factor (t);
- }
- else
- {
- factor_using_pollard_rho (t, 1);
- }
-}
- mpz_clear (t);
- return true;
-}
#endif
/* The maximum number of factors, including -1, for negative numbers. */
@@ -379,30 +324,18 @@ factor_wheel (uintmax_t n0, size_t max_n_factors,
uintmax_t *factors)
}
/* Single-precision factoring */
-static bool
-print_factors_single (char const *s)
+static void
+print_factors_single (uintmax_t n)
{
uintmax_t factors[MAX_N_FACTORS];
- uintmax_t n;
- size_t n_factors;
+ size_t n_factors = factor_wheel (n, MAX_N_FACTORS, factors);
size_t i;
char buf[INT_BUFSIZE_BOUND (uintmax_t)];
- strtol_error err;
- if ((err = xstrtoumax (s, NULL, 10, &n, "")) != LONGINT_OK)
-{
- if (err == LONGINT_OVERFLOW)
- error (0, 0, _("%s is too large"), quote (s));
- else
- error (0, 0, _("%s is not a valid positive integer"), quote (s));
- return false;
-}
- n_factors = factor_wheel (n, MAX_N_FACTORS, factors);
printf ("%s:", umaxtostr (n, buf));
for (i = 0; i < n_factors; i++)
printf (" %s", umaxtostr (factors[i], buf));
putchar ('\n');
- return true;
}
#if HAVE_GMP
@@ -450,67 +383,93 @@ free_factors (void)
nfactors_found = 0;
}
+/* Arbitrary-precision factoring */
+static void
+print_factors_multi (mpz_t t)
+{
+ mpz_out_str (stdout, 10, t);
+ putchar (':');
+
+ if (mpz_sgn (t) != 0)
+{
+ /* Set the trial division limit according to the size of t. */
+ size_t n_bits = mpz_sizeinbase (t, 2);
+ unsigned int division_limit = MIN (n_bits, 1000);
+ division_limit *= division_limit;
+
+ factor_using_division (t, division_limit);
+
+ if (mpz_cmp_ui (t, 1) != 0)
+ {
+ debug ("[is number prime?] ");
+ if (mpz_probab_prime_p (t, 3))
+ emit_factor (t);
+ else
+ factor_using_pollard_rho (t, 1);
+ }
+}
+
+ mpz_clear (t)
Re: [PATCH]: chmod - do inform about using different mode than requested with SGID/SUID/sticky bits without permissions to change them
Ondřej Vašík <[EMAIL PROTECTED]> writes:
> - bool changed = (chmod_succeeded
> - && mode_changed (file, old_mode, new_mode));
> + bool mode_change = mode_changed (file, old_mode, new_mode);
> + bool changed = (chmod_succeeded && mode change);
> +
> + if (chmod_succeeded && ((old_mode ^ new_mode) & CHMOD_MODE_BITS))
> +{
> +
> + /* Changed to another mode than requested */
This doesn't look right to me. First, surely there's no need to invoke
mode_changed if chmod_succeeded is false. Second, ((old_mode ^
new_mode) & CHMOD_MODE_BITS) doesn't tell us whether we changed to
another mode than requested; mode_change tells us that.
> + struct stat new_stats;
> + char perms_requested[12];
> + char perms_actual[12];
> +
> + if (stat (file, &new_stats) != 0)
Third, this means we've invoked 'stat' twice on the file afterwards,
once here, and once in mode_changed. We should invoke 'stat' only in
mode_changed.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: remove --bignum from 'factor'
Paul Eggert wrote: > Here's a patch to remove the --bignum and --no-bignum options from > 'factor'. The case for removing --bignum isn't as strong as that for > 'expr', but still, it seems to me that these options are not needed and > complicate the documentation unnecessarily. > > > Remove --bignum and --no-bignum from 'factor'. +1 In general there should be a very strong case required for adding new options. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
seq regression on x86 in coreutils 7.0
Here's the bug:
$ seq 9223372036854775807 9223372036854775808
9223372036854775807
9223372036854775808
9223372036854775809
This is Debian stable x86, compiled with GCC 4.3.2.
This worked correctly in older 'seq' versions.
The problem is that the 2008-04-14 seq patch introduced an abs_rel_diff
function that isn't numerically accurate. I looked into why that
function was introduced; it was to work around a bug in Solaris 8 and
some other older systems, where strold ("0.9000") <
strold ("0.9"). We shouldn't worry about working around numeric bugs
like these in C libraries in older systems, unless the bugs are likely
to come up in real applications, which is not the case here. Better to
modify the test case to not tickle the bug in the buggy C library.
We can't easily add the above test case, since it's not portable to
hosts where long double == double.
Here's a patch:
Undo workaround for Solaris 8 floating-point bug that introduced other bugs.
* src/seq.c: Don't include , .
(abs_rel_diff): Remove.
(print_numbers): Test for equality, not for an epsilonish value.
This reverts the change of 2008-04-14, which broke 'seq' on the x86;
for example, it causes "seq 9223372036854775807 9223372036854775808"
to incorrectly output 3 numbers instead of 2. It's better to punish obsolescent
hosts that have incorrectly-working floating-point than to punish
correctly-working hosts.
* tests/misc/seq: Use 0.9, rather than 0.9000,
to avoid tickling a bug in Solaris 8 strtold, which converts "0.9" and
"0.9" correctly, but incorrectly converts "0.9000"
to a smaller value.
diff --git a/src/seq.c b/src/seq.c
index b41aab6..3ae158b 100644
--- a/src/seq.c
+++ b/src/seq.c
@@ -20,8 +20,6 @@
#include
#include
#include
-#include
-#include
#include "system.h"
#include "c-strtod.h"
@@ -258,14 +256,6 @@ long_double_format (char const *fmt, struct layout *layout)
return NULL;
}
-/* Return the absolute relative difference from x to y. */
-static double
-abs_rel_diff (double x, double y)
-{
- double s = (y == 0.0 ? 1 : y);
- return fabs ((y - x) / s);
-}
-
/* Actually print the sequence of numbers in the specified range, with the
given or default stepping and format. */
@@ -310,7 +300,7 @@ print_numbers (char const *fmt, struct layout layout,
x_str[x_strlen - layout.suffix_len] = '\0';
if (xstrtold (x_str + layout.prefix_len, NULL, &x_val, c_strtold)
- && abs_rel_diff (x_val, last) < DBL_EPSILON)
+ && x_val == last)
{
char *x0_str = NULL;
if (asprintf (&x0_str, fmt, x0) < 0)
diff --git a/tests/misc/seq b/tests/misc/seq
index 8e76f42..2271322 100755
--- a/tests/misc/seq
+++ b/tests/misc/seq
@@ -47,7 +47,10 @@ my @Tests =
{OUT_SUBST => 's,^-0\.0$,0.0,'},
],
['float-5', qw(0.8 1e-1 0.9), {OUT => [qw(0.8 0.9)]}],
- ['float-6', qw(0.8 0.1 0.9000), {OUT => [qw(0.8 0.9)]}],
+ # Don't append lots of zeros to that 0.9000...; for example, changing the
+ # number to 0.9000 tickles a bug in Solaris 8 strtold
+ # that would cause the test to fail.
+ ['float-6', qw(0.8 0.1 0.9),{OUT => [qw(0.8 0.9)]}],
['wid-1', qw(.8 1e-2 .81), {OUT => [qw(0.80 0.81)]}],
['wid-2', qw(.8 1e-7 .801), {OUT => [qw(0.800 0.801)]}],
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
