Re: cp --help: -L doubled
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [adding the German translation team in cc] According to pe...@gmx.at on 5/20/2009 11:05 AM: > When I view cp --help part of it looks like this(its german): > > -L, --dereference symbolischen Verknüpfungen in QUELLE immer > folgen > -n, --no-clobberkeine existierenden Dateien überschreiben > (überstimmt eine vorangehende Option -n) > -L, --dereference symbolischen Verknüpfungen in QUELLE nie folgen > -p genau wie --preserve=mode,ownership,timestamps > --preserve[=ATTR_LIST] angegebene Datei‐Attribute (Voreinstellung: > mode, > > I don't know if I am the only one who is seeing this, but I thought I would > let you know. Thanks for the report. It doesn't happen in English, so it is definitely a problem in the translation file. Perhaps a fuzzy message is at fault. It would also help if you specified which version of coreutils this occurred with, as the translation page claims that all 1398 strings were translated in time for coreutils 7.4. http://translationproject.org/domain/coreutils.html - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -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 iEYEARECAAYFAkoUpZAACgkQ84KuGfSFAYBtggCcDJRyUjtslF03FXOgJd6A7YAo eH4AoK00CEO1PjNnKfiUFVNmDZD2N+0E =wVcl -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] chroot specify user/group feature
Thank you Jim, Pádraig and Andreas for all your suggestions. I took all
of them in consideration. I temporary lent some code from setuidgid.c
and the additional groups are allocated dinamically.
I think that in the future the `set_additional_groups' function should
be moved in a separate library, so it can be shared with setuidgid that
at the moment doesn't support group names but only group IDs and this is
what setuidgid will get back.
Cheers,
Giuseppe
>From 0b305c281fc7575b3989b0f80fe452918cf93f62 Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Fri, 1 May 2009 23:50:11 +0200
Subject: [PATCH] Chroot now accepts the options --userspec and --groups.
* NEWS: Added note about the new chroot features.
* doc/coreutils.texi: Likewise.
* src/chroot.c (main): Added support for --userspec and --groups.
* tests/Makefile.am: Added tests for chroot.
* tests/chroot/credentials: Likewise.
* tests/test-lib.sh: Likewise.
---
NEWS |5 ++
doc/coreutils.texi | 29 +-
src/chroot.c | 133 -
tests/Makefile.am|1 +
tests/chroot/credentials | 43 +++
tests/test-lib.sh|1 +
6 files changed, 206 insertions(+), 6 deletions(-)
create mode 100644 tests/chroot/credentials
diff --git a/NEWS b/NEWS
index 31f1b1a..3af06e4 100644
--- a/NEWS
+++ b/NEWS
@@ -7,6 +7,11 @@ GNU coreutils NEWS-*-
outline -*-
truncate -s failed to skip all whitespace in the option argument in
some locales.
+** New features
+
+ chroot now accepts the options --userspec and --groups.
+
+
* Noteworthy changes in release 7.4 (2009-05-07) [stable]
** Bug fixes
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index b96fdb2..1963c74 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -14144,7 +14144,7 @@ underlying function is non-privileged due to lack of
support in MS-Windows.}
Synopses:
@example
-chroot @var{newroot} [...@var{command} [...@var{args}]@dots{}]
+chroot @var{option} @var{newroot} [...@var{command} [...@var{args}]@dots{}]
chroot @var{option}
@end example
@@ -14157,8 +14157,31 @@ variable or @command{/bin/sh} if not set, invoked with
the @option{-i} option.
@var{command} must not be a special built-in utility
(@pxref{Special built-in utilities}).
-The only options are @option{--help} and @option{--version}. @xref{Common
-options}. Options must precede operands.
+The program accepts the following options. Also see @ref{Common options}.
+Options must precede operands.
+
+...@table @samp
+
+...@itemx --usersp...@var{userspec}
+...@opindex --userspec
+Use the @var{userspec} user and group in the new environment.
+...@var{userspec} is given in the form @var{user}:@var{group}, the group
+can be omitted and in this case the original one will be used.
+
+...@itemx --grou...@var{groups}
+...@opindex --groups
+Specify an additional set of groups @var{groups} to be used by the
+chroot process.
+
+...@end table
+
+By default, @command{chroot} retains the user credentials---usually those
+of the super-user---in the new environment.
+You can modify this behavior via the @option{--userspec=USER:GROUP} option,
+to specify the desired user and/or primary group.
+Supplementary groups can be configured using the @option{--groups=group_list}
+option. If either @option{--userspec} or @option{--groups} is omitted,
+then the original values are kept.
Here are a few tips to help avoid common problems in using chroot.
To start with a simple example, make @var{command} refer to a statically
diff --git a/src/chroot.c b/src/chroot.c
index 6d3fddf..3e0b30d 100644
--- a/src/chroot.c
+++ b/src/chroot.c
@@ -21,17 +21,89 @@
#include
#include
#include
+#include
#include "system.h"
#include "error.h"
#include "long-options.h"
#include "quote.h"
+#include "userspec.h"
+#include "xstrtol.h"
+#include "xalloc.h"
/* The official name of this program (e.g., no `g' prefix). */
#define PROGRAM_NAME "chroot"
#define AUTHORS proper_name ("Roland McGrath")
+#ifndef MAXGID
+#define MAXGID GID_T_MAX
+#endif
+
+enum
+{
+ USERSPEC = UCHAR_MAX + 1,
+ GROUPS
+};
+
+static struct option const long_opts[] =
+{
+ {"userspec", required_argument, NULL, USERSPEC},
+ {"groups", required_argument, NULL, GROUPS},
+ {GETOPT_HELP_OPTION_DECL},
+ {GETOPT_VERSION_OPTION_DECL},
+ {NULL, 0, NULL, 0}
+};
+
+/* Groups is a comma separated list of additional groups. */
+static int
+set_additional_groups (char const *groups)
+{
+ GETGROUPS_T *gids = NULL;
+ size_t n_gids_allocated = 0;
+ size_t n_gids = 0;
+ char *buffer = xstrdup (groups);
+ char const *tmp;
+ int ret;
+
+ for (tmp = strtok (buffer, ","); tmp; tmp = strtok (NULL, ","))
+{
+ struct group *g;
+ unsigned long int value;
+
+ if (xstrtoul (tmp, NULL, 10, &value, "") == LONGINT_OK && value <=
MAXGID)
+{
+ g = getgrgid (value);
+}
+ else
+
Re: [PATCH] chroot specify user/group feature
Pádraig Brady writes: >> +#ifndef MAXGID >> +# define MAXGID GID_T_MAX >> +#endif > > Why add the new MAXGID name? I took this code from the gnulib userspec.c file. I guess there are cases when MAXGID is defined and GID_T_MAX is not, and in such case it is better to use the real value of MAXGID than the maximum value allowed for the gid_t type. Can we assume that every time MAXGID is defined, GID_T_MAX has the right value too? If so, we can remove the same lines from gnulib too. Regards, Giuseppe ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
cp --help: -L doubled
When I view cp --help part of it looks like this(its german): -L, --dereference symbolischen Verknüpfungen in QUELLE immer folgen -n, --no-clobberkeine existierenden Dateien überschreiben (überstimmt eine vorangehende Option -n) -L, --dereference symbolischen Verknüpfungen in QUELLE nie folgen -p genau wie --preserve=mode,ownership,timestamps --preserve[=ATTR_LIST] angegebene Datei‐Attribute (Voreinstellung: mode, I don't know if I am the only one who is seeing this, but I thought I would let you know. -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-aktionspreis/?ac=OM.AD.PD003K11308T4569a ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls reports incorrect file size compared to what debugfs reports for ext3 filesystem
Chris Weston writes: > Yes, the platform is MIPS with a 64-bit Kernel and 32-bit userland. Looks like your ls is an n32 binary, but your strace can only decode o32 traces. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
RE: ls reports incorrect file size compared to what debugfs reports for ext3 filesystem
On Wed, May 20, 2009 at 1:37 AM James Youngman wrote: > On Wed, May 20, 2009 at 1:33 AM, Matthew Woehlke > wrote: > > Chris Weston wrote: > >> > >> I'm trying debug an issue with my one of my disks in my system. I > >> have an ext3 file system mounted and ls -l is reporting an impossible > >> size for two of the files: log_1848_1239927341.core and > >> log_1848_1239927341.core~. The size is 98P. This partition > >> (/dev/sdb2) is only a few GB in size. > > > > Maybe the file is sparse? What does 'stat log_1848_1239927341.core' have > to > > say? > > Chris already posted that in this thread. The file does appear to > be sparse. > > However, the strace output also looks very unusual ... > > r...@localhost:/mnt/sys/external> strace -v ls -l log_1848_1239927341.core > svr4_syscall() = 0 > syscall_6061(0x7fb817ec, 0x3995, 0x3995bf08, 0x3995c58c, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0 > , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0 > syscall_6009(0, 0x1000, 0x3, 0x802, 0, 0x20, 0, 0x3996, 0, > 0x3996, 0, 0x39964010, > 0, 0x39936db0, 0, 0, 0x39948628, 0, 0, 0, 0, 0, 0, 0x2000, 0, > 0x3995c288, 0, 0, 0, 0 > , 0, 0x3995ca68) = 0x2aaa8000 > svr4_fork() = -1 ERRNO_6002 (Unknown error > 6002) > svr4_fork() = -1 ERRNO_6002 (Unknown error > 6002) > > [...] > > svr4_syscall() = -1 ERRNO_6001 (Unknown error > 6001) > -rwxrwxrwx 1 root root 109775240942714880 Apr 30 08:12 _1848_123 > 9927341.core > svr4_evtrapret()= -1 ERRNO_6003 (Unknown error > 6003) > svr4_syscall() = 6011 > svr4_syscall() = -1 ERRNO_6003 (Unknown error > 6003) > svr4_syscall() = -1 ERRNO_6205 (Unknown error > 6205) > Process 2697 detached > > > ... which leads me to on the one hand wonder if the platform is MIPS, > but on the other hand wonder if something else is going on, since the > strace output seems to contain so many unknown errno values and the > strace output doesn't seem to end with an exit syscall. > Yes, the platform is MIPS with a 64-bit Kernel and 32-bit userland. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: tail +n does not work under Linux?
Eric Blake wrote: COUNT runs into length problems - adding 4 characters per instance builds up fast. I'll try with NUM instead. As it is, I already had to rephrase things since "nth" is a word, but "count'th" and "num'th" are not. s/N/K/ ? :-) Is "K'th" item too awkward? (Or some other letter that isn't 'N'?) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Use the --force, Luke -- Riccardo Iaconelli ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls reports incorrect file size compared to what debugfs reports for ext3 filesystem
James Youngman wrote: On Wed, May 20, 2009 at 1:33 AM, Matthew Woehlke wrote: Please do not quote my e-mail address unobfuscated in message bodies. Chris Weston wrote: I'm trying debug an issue with my one of my disks in my system. I have an ext3 file system mounted and ls -l is reporting an impossible size for two of the files: log_1848_1239927341.core and log_1848_1239927341.core~. The size is 98P. This partition (/dev/sdb2) is only a few GB in size. Maybe the file is sparse? What does 'stat log_1848_1239927341.core' have to say? Chris already posted that in this thread. The file does appear to be sparse. Ah, sorry. Missed it in all the strace noise ;-). So... except that my ext3 doesn't seem to allow files of 5T or larger, I'd say nothing is wrong here. (While I didn't see anything in mke2fs, I can't rule out an option when creating the FS to allow files of that size.) However, the strace output also looks very unusual ... [snip strace] which leads me to on the one hand wonder if the platform is MIPS, but on the other hand wonder if something else is going on, since the strace output seems to contain so many unknown errno values and the strace output doesn't seem to end with an exit syscall. Strange indeed. Doesn't strace usually contain calls other than system()? :-) (It does here, anyway, but of course I am on garden-variety x86_64.) -- Matthew Use the --force, Luke -- Riccardo Iaconelli ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: tail +n does not work under Linux?
Maybe a slight rewording of the man page could highlight this? (eg add another reference to the info page for this trick) What do you think about the attached patch to the --help output (and thus man page)? Thanks for taking my comment into account! It is indeed clearer with your proposal, I'll let you decide between CNT, COUNT or NUM :-) I have noticed a typo in my name (it's Christophe). Would it possible to add a short reference to the info doc inside the man page? I know there is already one at the end, but as there is a special note about 'tail -CNT', I think that something like: "Look at the full texinfo manual for a compatibility note for this option" could be added at the -c, -n and -f options. It's a bit heavy, but I think it would help. - tail +COUNT is supported on "older systems". Older than what? How do I know whether I am using a "older system" or not? "older systems" being those that failed to define _POSIX2_VERSION, or defined it to the older value, or when you are using the environment variable to select the older behavior. Is there a way to know which default POSIX version is used by coreutils? I have check the build logs, and saw nothing. Look for something like this: configure:12516: checking for desired default level of POSIX conformance configure:12527: result: none-specified In my case, I neither had the environment variable set at configure time, nor did my system headers set _POSIX2_VERSION to either recognized value (in other words, my system intentionally admits that it is not yet compliant to either version). I guess there are three accepted values these days, now that POSIX 2008 is finalized; maybe our docs need to be updated to mention the value required by the latest POSIX version. I have built coreutils-7.4 under RHEL 3 and 4, and Solaris 8, without defining _POSIX2_VERSION before starting the build. In each case, configure reported "none-specified", but the Solaris build has chosen a different default. This is confusing when we want to use the same commands on different systems. Do you suggest rebuiling with POSIX2_VERSION defined at least under Solaris, so that all my environments behave the same? I would like to be able to know at runtime which is the default chosen, it would at least help debugging such issues for users which are not very familiar with such things. (I am not very familiar, but more than other users) Thanks for your work, Christophe. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] chroot specify user/group feature
Andreas Schwab wrote: > Jim Meyering writes: >> diff --git a/tests/chroot/credentials b/tests/chroot/credentials >> index f3e7a32..fd87a86 100644 >> --- a/tests/chroot/credentials >> +++ b/tests/chroot/credentials >> @@ -29,13 +29,15 @@ require_root_ >> fail=0 >> >> # Verify that root credentials are kept. >> -test `chroot / whoami` == root || fail=1 >> -test "`groups`" == "`chroot / groups`" || fail=1 >> +test $(chroot / whoami) == root || fail=1 >> +test "$(groups)" == "$(chroot / groups)" || fail=1 > > This should use = instead of ==. Yes, indeed. Thanks! ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] chroot specify user/group feature
Pádraig Brady wrote:
> Giuseppe Scrivano wrote:
>> diff --git a/src/chroot.c b/src/chroot.c
>> +
>> +#ifndef GID_T_MAX
>> +# define GID_T_MAX TYPE_MAXIMUM (gid_t)
>> +#endif
>
> The above is redundant and already done in system.h
Good catch.
>> +#ifndef MAXGID
>> +# define MAXGID GID_T_MAX
>> +#endif
>
> Why add the new MAXGID name?
I presumed it was in case MAXGID is smaller than GID_T_MAX.
>> + if (userspec)
>> +{
>> + uid_t uid;
>> + gid_t gid;
>> + char *user;
>> + char *group;
>> + const char *err = parse_user_spec (userspec, &uid, &gid, &user,
>> &group);
>> + if (err)
>> +{
>> + perror (err);
>> + exit (1);
>> +}
>
> Probably should use error(EXIT_FAILURE, ...) instead of perror();
Another good one.
Thanks.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] chroot specify user/group feature
Giuseppe Scrivano wrote:
> diff --git a/src/chroot.c b/src/chroot.c
> +
> +#ifndef GID_T_MAX
> +# define GID_T_MAX TYPE_MAXIMUM (gid_t)
> +#endif
The above is redundant and already done in system.h
> +
> +#ifndef MAXGID
> +# define MAXGID GID_T_MAX
> +#endif
Why add the new MAXGID name?
> + if (userspec)
> +{
> + uid_t uid;
> + gid_t gid;
> + char *user;
> + char *group;
> + const char *err = parse_user_spec (userspec, &uid, &gid, &user,
> &group);
> + if (err)
> +{
> + perror (err);
> + exit (1);
> +}
Probably should use error(EXIT_FAILURE, ...) instead of perror();
cheers,
Pádraig.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] chroot specify user/group feature
Jim Meyering writes: > diff --git a/tests/chroot/credentials b/tests/chroot/credentials > index f3e7a32..fd87a86 100644 > --- a/tests/chroot/credentials > +++ b/tests/chroot/credentials > @@ -29,13 +29,15 @@ require_root_ > fail=0 > > # Verify that root credentials are kept. > -test `chroot / whoami` == root || fail=1 > -test "`groups`" == "`chroot / groups`" || fail=1 > +test $(chroot / whoami) == root || fail=1 > +test "$(groups)" == "$(chroot / groups)" || fail=1 This should use = instead of ==. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] chroot specify user/group feature
Giuseppe Scrivano wrote:
> this is an updated version for the previous patch. I added
> documentation and new tests.
>
> Since I don't use short-named options, there are not conflicts with -u,
> -g and -G used by different chroot implementations.
> In my first version -g has a different meaning than the -g on FreeBSD
> and OpenBSD; now I removed this option and I kept only the long-named
> version --groups.
Hi Giuseppe,
Almost there.
I've made some small changes with the patches below.
Please read through them, then squash into your own patch so you have
a single change-set, then address the FIXME I added, and compare your
code to what's done in the helper program, src/setuidgid.c, since it
performs a very similar task.
Also, when I started to compare, I noticed that you used NGROUPS,
while setuidgid.c allocates space dynamically. I think we had problems
with early versions using NGROUPS.
>From 39f569d6f502096a5f9988ba8e378695a9b087c6 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Wed, 20 May 2009 15:21:20 +0200
Subject: [PATCH 1/5] tweak help, const, formatting
---
src/chroot.c | 23 ++-
1 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/src/chroot.c b/src/chroot.c
index ca9ac00..94aebf5 100644
--- a/src/chroot.c
+++ b/src/chroot.c
@@ -26,8 +26,8 @@
#include "system.h"
#include "error.h"
#include "long-options.h"
-#include "userspec.h"
#include "quote.h"
+#include "userspec.h"
#include "xstrtol.h"
#ifndef GID_T_MAX
@@ -44,7 +44,11 @@
#define AUTHORS proper_name ("Roland McGrath")
-enum { USERSPEC = UCHAR_MAX + 1, GROUPS};
+enum
+ {
+USERSPEC = UCHAR_MAX + 1,
+GROUPS
+ };
static struct option const long_opts[] =
{
@@ -56,12 +60,13 @@ static struct option const long_opts[] =
};
/* Groups is a comma separated list of additional groups. */
-static int set_additional_groups (const char *groups)
+static int
+set_additional_groups (char const *groups)
{
gid_t groups_id [NGROUPS];
int ngroups = 0;
char *buffer = xstrdup (groups);
- const char *tmp;
+ char const *tmp;
for (tmp = strtok (buffer, ","); tmp; tmp = strtok (NULL, ","))
{
@@ -114,8 +119,8 @@ Run COMMAND with root directory set to NEWROOT.\n\
"), stdout);
fputs (_("\
- --userspec, specify the userspec in the form USER:GROUP\n\
- --groups, specify the additional groups as g1,g2,..,gn\n\
+ --userspec=USER:GROUP specify user and group (ID or name) to use\n\
+ --groups=G_LISTspecify supplementary groups as g1,g2,..,gN\n\
"), stdout);
fputs (HELP_OPTION_DESCRIPTION, stdout);
@@ -133,8 +138,8 @@ int
main (int argc, char **argv)
{
int c;
- const char *userspec = NULL;
- const char *groups = NULL;
+ char const *userspec = NULL;
+ char const *groups = NULL;
initialize_main (&argc, &argv);
set_program_name (argv[0]);
@@ -197,7 +202,7 @@ main (int argc, char **argv)
gid_t gid;
char *user;
char *group;
- const char *err = parse_user_spec (userspec, &uid, &gid, &user, &group);
+ char const *err = parse_user_spec (userspec, &uid, &gid, &user, &group);
if (err)
{
perror (err);
--
1.6.3.1.149.gbc70c
>From 1312b100431a9851a954ffa84b234fd371077941 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Wed, 20 May 2009 15:31:21 +0200
Subject: [PATCH 2/5] size_t ngroups
---
src/chroot.c | 35 ++-
1 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/src/chroot.c b/src/chroot.c
index 94aebf5..7a61095 100644
--- a/src/chroot.c
+++ b/src/chroot.c
@@ -45,10 +45,10 @@
#define AUTHORS proper_name ("Roland McGrath")
enum
- {
-USERSPEC = UCHAR_MAX + 1,
-GROUPS
- };
+{
+ USERSPEC = UCHAR_MAX + 1,
+ GROUPS
+};
static struct option const long_opts[] =
{
@@ -63,8 +63,8 @@ static struct option const long_opts[] =
static int
set_additional_groups (char const *groups)
{
- gid_t groups_id [NGROUPS];
- int ngroups = 0;
+ gid_t groups_id[NGROUPS];
+ size_t ngroups = 0;
char *buffer = xstrdup (groups);
char const *tmp;
@@ -153,18 +153,19 @@ main (int argc, char **argv)
parse_long_options (argc, argv, PROGRAM_NAME, PACKAGE_NAME, Version,
usage, AUTHORS, (char const *) NULL);
- while ((c = getopt_long (argc, argv, "+", long_opts, NULL)) != -1)
+ while ((c = getopt_long (argc, argv, "+", long_opts, NULL)) != -1)
{
- switch (c) {
- case USERSPEC:
-userspec = optarg;
-break;
- case GROUPS:
-groups = optarg;
-break;
- default:
-usage (EXIT_FAILURE);
- }
+ switch (c)
+{
+case USERSPEC:
+ userspec = optarg;
+ break;
+case GROUPS:
+ groups = optarg;
+ break;
+default:
+ usage (EXIT_FAILURE);
+}
}
if (argc <= optind)
--
1.6.3.1.149.gbc70c
>From b4774ce8725b0ac552658d2fa17b593c0f9335ca Mon Sep 17 00:00:00 2001
From: Jim Meyering
D
Re: tail +n does not work under Linux?
Pádraig Brady draigBrady.com> writes:
> > - -n, --lines=Noutput the last N lines, instead of the last %
d;\n\
> > - or use +N to output lines starting with the
Nth\n\
> > + -n, --lines=CNT output the last CNT lines, instead of the last %
d;\n\
> > + or use +CNT to skip the first CNT-1 lines\n\
> >--max-unchanged-stats=N\n\
>
> CNT doesn't read too well :)
> How about COUNT or NUM?
COUNT runs into length problems - adding 4 characters per instance builds up
fast. I'll try with NUM instead. As it is, I already had to rephrase things
since "nth" is a word, but "count'th" and "num'th" are not.
> What about the texi docs?
They already used @var{count} rather than @var{n} in some instances, but I will
go ahead and sweep these to make them all consistent.
> Would one change head -n docs also for consistency?
Sure, sounds good.
> What about the other instances of N in tail --help?
For --max-unchanged-stats, I actually WANT to keep N. After all, you can't
use --max-unchanged-stats=1k, nor can you use --max-unchanged-stats=+2 to mean
start at the second item. For all other instances of N in tail, my first patch
already caught them.
I'll work on respinning this patch to cover more territory.
--
Eric Blake
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: tail +n does not work under Linux?
Eric Blake wrote: > > What do you think about the attached patch to the --help output (and thus > man page)? Yes there are too many "N"s. > - -n, --lines=Noutput the last N lines, instead of the last > %d;\n\ > - or use +N to output lines starting with the Nth\n\ > + -n, --lines=CNT output the last CNT lines, instead of the last > %d;\n\ > + or use +CNT to skip the first CNT-1 lines\n\ >--max-unchanged-stats=N\n\ CNT doesn't read too well :) How about COUNT or NUM? What about the texi docs? Would one change head -n docs also for consistency? What about the other instances of N in tail --help? cheers, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: tail +n does not work under Linux?
Eric Blake wrote:
...
...
> "), stdout);
> printf (_("\
> - -n, --lines=Noutput the last N lines, instead of the last
> %d;\n\
> - or use +N to output lines starting with the Nth\n\
> + -n, --lines=CNT output the last CNT lines, instead of the last
> %d;\n\
> + or use +CNT to skip the first CNT-1 lines\n\
>--max-unchanged-stats=N\n\
> with --follow=name, reopen a FILE which has not\n\
> changed size after N (default %d) iterations\n\
> @@ -264,9 +265,9 @@ Mandatory arguments to long options are mandatory for
> short options too.\n\
> fputs (VERSION_OPTION_DESCRIPTION, stdout);
> fputs (_("\
> \n\
> -If the first character of N (the number of bytes or lines) is a `+',\n\
> -print beginning with the Nth item from the start of each file, otherwise,\n\
> -print the last N items in the file. N may have a multiplier suffix:\n\
> +If the first character of CNT (the number of bytes or lines) is a `+',\n\
> +print beginning with the CNT item from the start of each file, otherwise,\n\
> +print the last CNT items in the file. CNT may have a multiplier suffix:\n\
> b 512, kB 1000, K 1024, MB 1000*1000, M 1024*1024,\n\
> GB 1000*1000*1000, G 1024*1024*1024, and so on for T, P, E, Z, Y.\n\
> \n\
That is a fine improvement.
My only reservation is with "beginning with the CNT item" vs.
"... the Nth item". Using "N" seems more natural, and "Nth"
reads better than "CNT" or "CNT'th".
In spite of that, you're welcome to push it as-is.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
bomb out quicker if cannot set date
$ date -s date: cannot set date: Operation not permitted Wed May 20 11:11:00 CST 2009 OK, then please don't print out that date afterward. Just bomb out. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: tail +n does not work under Linux?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Christophe LYON on 5/12/2009 2:19 AM:
> On 11.05.2009 20:28, Bob Proulx wrote:
>> It is only because 'n' and 'N' are different cases of the same letter
>> that people's minds play tricks on them.
>
> Indeed.
> Maybe a slight rewording of the man page could highlight this?
> (eg add another reference to the info page for this trick)
What do you think about the attached patch to the --help output (and thus
man page)?
> After reading those 2 paragraphs several times, there are still a few
> things not completely clear:
> - tail -COUNT is described as obsolete, but supported when it does not
> conflict with the new standard. But has _POSIX2_VERSION any influence on
> this support?
In the latest coreutils, there is no influence. The POSIX folks made it
clear that while 'count -12' is no longer mandated (because it conflicts
with the argument guidelines, which state that 'app -12' is equivalent to
'app -1 -2' which is equivalent to 'app -2 -1' which is equivalent to 'app
- -21', but obviously 'count -12' and 'count -21' aren't equivalent), it is
also not forbidden. Yes, there was a window of coreutils releases where
this syntax was outright rejected, depending on _POSIX2_VERSION, but that
is no longer the case.
> - tail +COUNT is supported on "older systems". Older than what? How do I
> know whether I am using a "older system" or not?
"older systems" being those that failed to define _POSIX2_VERSION, or
defined it to the older value, or when you are using the environment
variable to select the older behavior.
>
> Is there a way to know which default POSIX version is used by coreutils?
> I have check the build logs, and saw nothing.
Look for something like this:
configure:12516: checking for desired default level of POSIX conformance
configure:12527: result: none-specified
In my case, I neither had the environment variable set at configure time,
nor did my system headers set _POSIX2_VERSION to either recognized value
(in other words, my system intentionally admits that it is not yet
compliant to either version). I guess there are three accepted values
these days, now that POSIX 2008 is finalized; maybe our docs need to be
updated to mention the value required by the latest POSIX version.
- --
Don't work too hard, make some time for fun as well!
Eric Blake e...@byu.net
-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
iEYEARECAAYFAkoT+KkACgkQ84KuGfSFAYC+jACgp9GZK9xNe0dum1EhhAK46frZ
8ekAoNckxgnvJSWF+Smi2xrF1G5LzAqm
=ZFMV
-END PGP SIGNATURE-
>From 81556e44f12489532bd5a0c445dab12db4f3b115 Mon Sep 17 00:00:00 2001
From: Eric Blake
Date: Wed, 20 May 2009 06:32:10 -0600
Subject: [PATCH] tail: make --help less ambiguous
* src/tail.c (usage): Use -n CNT, not -n N, to avoid confusion.
Reported by Chrisophe Lyon.
---
src/tail.c | 17 +
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/src/tail.c b/src/tail.c
index fe34600..c58d830 100644
--- a/src/tail.c
+++ b/src/tail.c
@@ -1,5 +1,6 @@
/* tail -- output the last part of file(s)
- Copyright (C) 1989, 90, 91, 1995-2006, 2008 Free Software Foundation, Inc.
+ Copyright (C) 1989, 90, 91, 1995-2006, 2008-2009 Free Software
+ Foundation, Inc.
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -226,8 +227,8 @@ With no FILE, or when FILE is -, read standard input.\n\
Mandatory arguments to long options are mandatory for short options too.\n\
"), stdout);
fputs (_("\
- -c, --bytes=Noutput the last N bytes; alternatively, use +N to\n\
- output bytes starting with the Nth of each file\n\
+ -c, --bytes=CNT output the last CNT bytes; or, use +CNT to\n\
+ skip the first CNT-1 bytes of each file\n\
"), stdout);
fputs (_("\
-f, --follow[={name|descriptor}]\n\
@@ -237,8 +238,8 @@ Mandatory arguments to long options are mandatory for short
options too.\n\
-F same as --follow=name --retry\n\
"), stdout);
printf (_("\
- -n, --lines=Noutput the last N lines, instead of the last %d;\n\
- or use +N to output lines starting with the Nth\n\
+ -n, --lines=CNT output the last CNT lines, instead of the last
%d;\n\
+ or use +CNT to skip the first CNT-1 lines\n\
--max-unchanged-stats=N\n\
with --follow=name, reopen a FILE which has not\n\
changed size after N (default %d) iterations\n\
@@ -264,9 +265,9 @@ Mandatory arguments to long options are mandatory for short
options too.\n\
fputs (VERSION_OPTION_DESCRIPTION, stdout);
fputs (_("\
\n\
-If the first character o
Re: ls reports incorrect file size compared to what debugfs reports for ext3 filesystem
On Wed, May 20, 2009 at 1:33 AM, Matthew Woehlke wrote: > Chris Weston wrote: >> >> I'm trying debug an issue with my one of my disks in my system. I >> have an ext3 file system mounted and ls -l is reporting an impossible >> size for two of the files: log_1848_1239927341.core and >> log_1848_1239927341.core~. The size is 98P. This partition >> (/dev/sdb2) is only a few GB in size. > > Maybe the file is sparse? What does 'stat log_1848_1239927341.core' have to > say? Chris already posted that in this thread. The file does appear to be sparse. However, the strace output also looks very unusual ... r...@localhost:/mnt/sys/external> strace -v ls -l log_1848_1239927341.core svr4_syscall() = 0 syscall_6061(0x7fb817ec, 0x3995, 0x3995bf08, 0x3995c58c, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0 syscall_6009(0, 0x1000, 0x3, 0x802, 0, 0x20, 0, 0x3996, 0, 0x3996, 0, 0x39964010, 0, 0x39936db0, 0, 0, 0x39948628, 0, 0, 0, 0, 0, 0, 0x2000, 0, 0x3995c288, 0, 0, 0, 0 , 0, 0x3995ca68) = 0x2aaa8000 svr4_fork() = -1 ERRNO_6002 (Unknown error 6002) svr4_fork() = -1 ERRNO_6002 (Unknown error 6002) [...] svr4_syscall() = -1 ERRNO_6001 (Unknown error 6001) -rwxrwxrwx 1 root root 109775240942714880 Apr 30 08:12 _1848_123 9927341.core svr4_evtrapret()= -1 ERRNO_6003 (Unknown error 6003) svr4_syscall() = 6011 svr4_syscall() = -1 ERRNO_6003 (Unknown error 6003) svr4_syscall() = -1 ERRNO_6205 (Unknown error 6205) Process 2697 detached ... which leads me to on the one hand wonder if the platform is MIPS, but on the other hand wonder if something else is going on, since the strace output seems to contain so many unknown errno values and the strace output doesn't seem to end with an exit syscall. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
