Re: touch command
Bob Proulx wrote: > [EMAIL PROTECTED] wrote: >> I am not really sure if it is a bug, but the line command >> "touch" seems incapable of changing the timestamp of a >> link (on a related issue, "tar" does not usually recover >> the timestamp of links). > > There is no lutimes(2) call and therefore way way to set the times on > a symlink. This is why touch does not have a -h option. Since > lchmod(2) is available the chmod command has a -h option and uses it > to change the owner of the symlink. Could this be simulated by removing and recreating the link? Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: touch command
Eric Blake <[EMAIL PROTECTED]> writes: > According to Bob Proulx on 8/27/2007 6:55 PM: >> There is no lutimes(2) call and therefore way way to set the times on >> a symlink. This is why touch does not have a -h option. Since >> lchmod(2) is available the chmod command has a -h option and uses it >> to change the owner of the symlink. > > But note that the next revision of POSIX will be adding futimensat, which > WILL support setting the (cosmetic) timestamp of symlinks. It's already supported by Linux (since 2.6.22) and glibc (since 2.6). Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP 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
FYI, stat recognizes more file system types; reflect a gnulib renaming
For details, see http://git.sv.gnu.org/r/gnulib.git Here are ChangeLog entries: 2007-08-28 Jim Meyering <[EMAIL PROTECTED]> Reflect renaming: mreadlink-with-size -> areadlink-with-size. * bootstrap.conf: Update module name. * src/copy.c (copy_internal): Update header and function names. * src/ls.c (get_link_name): Likewise. * src/readlink.c (main): Likewise. * src/stat.c (print_stat): Likewise. Add file system type names and magic numbers from "man 2 statfs". * src/stat.c (human_fstype): Also handle BEFS, BFS, BINFMT_MISC, FUSECTL, HUGETLBFS, NFSD and OPENPROM. 2007-08-27 Jim Meyering <[EMAIL PROTECTED]> Add some file system type names and magic numbers from glibc. * src/stat.c (human_fstype): Add any file system names and values present in glibc's linux_fsinfo.h but not in this list. Alphabetize the S_* names and capitalize the hexadecimal constants. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: touch command
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Pádraig Brady on 8/28/2007 2:37 AM: >> There is no lutimes(2) call and therefore way way to set the times on >> a symlink. This is why touch does not have a -h option. Since >> lchmod(2) is available the chmod command has a -h option and uses it >> to change the owner of the symlink. > > Could this be simulated by removing and recreating the link? Not in the general case (think 'touch -m -d yesterday file', which changes only the modification time, and to a time other than now). - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG1BBc84KuGfSFAYARAlntAJ9EmSYBdagKw46JLbCH5e4LXc1HZQCeJ3Nj S0A7Y0DYA1PeTZJVTBr0DXw= =9Deh -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: /usr/bin/test message forgets newline
JM> [note that only "[" accepts an OPTION. ] Ah, fine print. Land mine. JM> DESCRIPTION JM>Exit with the status determined by EXPRESSION. perhaps repeat the [note that only "[" accepts an OPTION. ] here. JM>--help display this help and exit JM>--version JM> output version information and exit ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
/usr/bin/test message forgets newline
/usr/bin/test neglects adding the trailing newline for this message at least: # /usr/bin/test -d 1 2 3 2>&1|od -c 000 / u s r / b i n / t e s t : e 020 x t r a a r g u m e n t ` 2 040 ' 041 P.S., $ /usr/bin/test --help $ /usr/bin/test --version do nothing, in contrast to the man page. (But not the Info page.) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: /usr/bin/test message forgets newline
[EMAIL PROTECTED] wrote: > /usr/bin/test neglects adding the trailing newline for this message at > least: > > # /usr/bin/test -d 1 2 3 2>&1|od -c > 000 / u s r / b i n / t e s t : e > 020 x t r a a r g u m e n t ` 2 > 040 ' > 041 Thanks. FYI, that's been fixed upstream for a while. > P.S., > $ /usr/bin/test --help > $ /usr/bin/test --version > do nothing, in contrast to the man page. (But not the Info page.) Thanks, but the upstream manual (as well as the one I see on Debian unstable) says this: [note that only "[" accepts an OPTION. ] NAME test - check file types and compare values SYNOPSIS test EXPRESSION test [ EXPRESSION ] [ ] [ OPTION DESCRIPTION Exit with the status determined by EXPRESSION. --help display this help and exit --version output version information and exit ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: /usr/bin/test message forgets newline
[EMAIL PROTECTED] wrote: > JM> [note that only "[" accepts an OPTION. ] > Ah, fine print. Land mine. > JM> DESCRIPTION > JM>Exit with the status determined by EXPRESSION. > perhaps repeat the > [note that only "[" accepts an OPTION. ] > here. > JM>--help display this help and exit > > JM>--version > JM> output version information and exit I went ahead and added a note, hoping it'll forestall further reports like this. However, remember that the authoritative doc is the info document. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Command line parsing of ls with genparse
> 1. The usage function for the ls command has the following >explanation for the -F, --classify command liune switch: >"append indicator (one of */=>@|) to entries". Can you rewrite it as "append indicator (one of *" "/=>@|) to entries", and rely on string concatenation to produce the same output? -- Eric Blake -- View this message in context: http://www.nabble.com/-PATCH--Command-line-parsing-of-ls-with-genparse-tf4343050.html#a12372776 Sent from the Gnu - Coreutils - Discuss mailing list archive at Nabble.com. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Command line parsing of ls with genparse
On Tue, Aug 28, 2007 at 10:48:55AM -0700, Eric Blake-1 wrote: > > > 1. The usage function for the ls command has the following > >explanation for the -F, --classify command liune switch: > >"append indicator (one of */=>@|) to entries". > > Can you rewrite it as "append indicator (one of *" "/=>@|) to entries", > and rely on string concatenation to produce the same output? > > -- Eric Blake In the present version of genparse new strings are always printed in new lines. For example (also from the ls commmand): d / directory flag"list directory entries instead of contents," " and do not dereference symbolic links" in the genparse (.gp) file is translated into -d, --directorylist directory entries instead of contents,\n\ and do not dereference symbolic links\n\ in the generated usage() function. Or NONE / group-directories-first flag"" "group directories before files" could be used to generate --group-directories-first\n\ group directories before files\n\ in the usage() function. So presently it doesn't work, but your idea is not bad. I will think about it again and maybe change genparse such that multiple comment strings in the same line will simply be concatenated. Michael ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Command line parsing of ls with genparse
> 2. ls.c depends ls-clp.h (the generated parser)
>ls-clp.h depends on ls.gp (the genparse file)
>ls.gp depends on ls.c because ls.gp is embedded as a comment in ls.c
>-> There is a circular dependency!
That seems wrong to me. Isn't it really:
ls$(EXEEXT) directly depends on ls.o and ls-clp.o
ls.o directly depends on ls.c and ls-clp.h
ls-clp.o directly depends on ls-clp.c and ls-clp.h
ls-clp.c directly depends on ls.gp
ls-clp.h directly depends on ls.gp
ls.gp directly depends on ls.c
No cycle there, even though ls.c is an indirect
dependency of ls$(EXEEXT) through more than one
leg of the transitive closure.
> +++ coreutils-6.9/src/ls.c2007-08-26 19:58:20.0 +0200
> @@ -76,7 +76,6 @@
> # define SA_RESTART 0
> #endif
>
> -#include "system.h"
> #include
Why are you deleting this include? Without it, how do you ensure
that is pulled in before anything else? If you intend for
ls-clp.h to fill this role, then it must be included before any
system files. Also, are you sure you are not falling foul of
any 'make distcheck' rules in Makefile.maint?
> + Cmdline(&cmdline, argc, argv);
GNU coding standards want a space between the function
name and open (.
> - case 'w':
> - {
> - unsigned long int tmp_ulong;
> - if (xstrtoul (optarg, NULL, 0, &tmp_ulong, NULL) != LONGINT_OK
> - || ! (0 < tmp_ulong && tmp_ulong <= SIZE_MAX))
> - error (LS_FAILURE, 0, _("invalid line width: %s"),
> - quotearg (optarg));
[Side issue, not a problem with your patch, but your
patch highlights the problem - why are we using plain
error instead of xstrtol_error? It means this particular
error message loses some quality.]
> +/* Extract the following section an process it with genparse
> + (see http://genparse.sourceforge.net) in order to generate a parser
> + for the command line arguments and a usage function for printing a
> help
> + screen. */
> +
> +/* genparse file starts here
> +#include
> +#include "system.h"
> +#include "ls.h"
> +
> +#exit_value LS_FAILURE
I know the C standard requires this, but in practice, are all
C preprocessors tolerant of comments that contain lines
that look like preprocessing directives but which are not?
> +NONE / help flag"display this help and exit"
> +NONE / version flag"output version information and
> exit"
It looks like one drawback of using genparse is that you lose
the system.h magic that ensures consistency between all
the apps with --help and --version, since you can't really
use the preprocessor macros *_HELP_OPTION_* here.
> +Report bugs to <__STRING__(PACKAGE_BUGREPORT)>.
What happened to the TRANSLATOR comment that reminds
them to add a second line, including the address to report
translation bugs to? Also, it isn't very obvious how this
will affect xgettext extraction of strings that need
translation. Are you sure you haven't broken things
for other locales? Would the generated ls-clp.c need
to be added to POTFILES.in, or is your intent still to
have all translatable strings reside in ls.c?
--
Eric Blake
--
View this message in context:
http://www.nabble.com/-PATCH--Command-line-parsing-of-ls-with-genparse-tf4343050.html#a12375174
Sent from the Gnu - Coreutils - Discuss mailing list archive at Nabble.com.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Command line parsing of ls with genparse
Eric Blake-1 scripsit: > > 2. ls.c depends ls-clp.h (the generated parser) > >ls-clp.h depends on ls.gp (the genparse file) > >ls.gp depends on ls.c because ls.gp is embedded as a comment in ls.c > >-> There is a circular dependency! > > That seems wrong to me. Isn't it really: Indeed. People tend to believe that .c files depend on .h files that they include, but in fact they don't; the .o file depends on both the .c file and the .h file. See "Recursive Make Considered Harmful" for a discussion of this. -- Eric Raymond is the Margaret Mead John Cowan of the Open Source movement.[EMAIL PROTECTED] --Bruce Perens, http://www.ccil.org/~cowan some years ago ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Command line parsing of ls with genparse
Eric Blake-1 <[EMAIL PROTECTED]> wrote:
>> -case 'w':
>> - {
>> -unsigned long int tmp_ulong;
>> -if (xstrtoul (optarg, NULL, 0, &tmp_ulong, NULL) != LONGINT_OK
>> -|| ! (0 < tmp_ulong && tmp_ulong <= SIZE_MAX))
>> - error (LS_FAILURE, 0, _("invalid line width: %s"),
>> - quotearg (optarg));
>
> [Side issue, not a problem with your patch, but your
> patch highlights the problem - why are we using plain
> error instead of xstrtol_error? It means this particular
> error message loses some quality.]
You're right that technically xstrtol_error is better -- more
specific about why a string is invalid -- and I'll probably make
the change, but I can't help lamenting the small degradation in
quality of the English diagnostic:
Current:
$ ls -w999
ls: invalid line width: 999
[Exit 2]
Probable new diagnostic:
$ ./ls -w999
./ls: -w argument `999' too large
[Exit 2]
As you probably noticed, it's needed at least in many places.
A quick search shows many other cases like that.
$ grep -A5 -E 'xstrto(u?l|i?max) \(' *.c|grep -w error|wc -l
32
Do you feel like working on that?
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
EXIT_FAIL vs. EXIT_FAILURE
system.h currently has:
/* Exit statuses for programs like 'env' that exec other programs.
EXIT_FAILURE might not be 1, so use EXIT_FAIL in such programs. */
enum
{
EXIT_FAIL = 1,
But gnulib's stdlib_.h has:
/* Tandem/NSK and other platforms that define EXIT_FAILURE as -1 interfere
with proper operation of xargs. */
#ifndef EXIT_FAILURE
# define EXIT_FAILURE 1
#elif EXIT_FAILURE != 1
# undef EXIT_FAILURE
# define EXIT_FAILURE 1
#endif
In other words, thanks to gnulib, EXIT_FAILURE is guaranteed to be 1. Is there
any reason to keep EXIT_FAIL in coreutils sources any more?
--
Eric Blake
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: EXIT_FAIL vs. EXIT_FAILURE
Eric Blake <[EMAIL PROTECTED]> wrote:
> system.h currently has:
>
> /* Exit statuses for programs like 'env' that exec other programs.
>EXIT_FAILURE might not be 1, so use EXIT_FAIL in such programs. */
> enum
> {
> EXIT_FAIL = 1,
>
> But gnulib's stdlib_.h has:
>
> /* Tandem/NSK and other platforms that define EXIT_FAILURE as -1 interfere
>with proper operation of xargs. */
> #ifndef EXIT_FAILURE
> # define EXIT_FAILURE 1
> #elif EXIT_FAILURE != 1
> # undef EXIT_FAILURE
> # define EXIT_FAILURE 1
> #endif
>
> In other words, thanks to gnulib, EXIT_FAILURE is guaranteed to be 1. Is
> there
> any reason to keep EXIT_FAIL in coreutils sources any more?
No.
Good catch. Thansk!
I was going to say "Send a patch! :-)",
but figured it'd be quicker to do it myself, in this case:
>From 35755454e45a6cbab4c711353131df483d89a979 Mon Sep 17 00:00:00 2001
From: Jim Meyering <[EMAIL PROTECTED]>
Date: Wed, 29 Aug 2007 00:13:16 +0200
Subject: [PATCH] Use EXIT_FAILURE, not EXIT_FAIL, now that EXIT_FAILURE is
always 1.
* src/system.h (EXIT_FAIL): Remove definition.
* src/chroot.c (main): EXIT_FAIL -> EXIT_FAILURE.
* src/env.c (main): Likewise.
* src/nice.c (main): Likewise.
* src/su.c (change_identity, main): Likewise.
* src/tty.c (main): Likewise.
Suggestion from Eric Blake.
Signed-off-by: Jim Meyering <[EMAIL PROTECTED]>
---
ChangeLog| 11 +++
src/chroot.c | 10 +-
src/env.c|4 ++--
src/nice.c | 14 +++---
src/su.c | 14 +++---
src/system.h |4 +---
src/tty.c|2 +-
7 files changed, 34 insertions(+), 25 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 80d08a1..015bad9 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2007-08-29 Jim Meyering <[EMAIL PROTECTED]>
+
+ Use EXIT_FAILURE, not EXIT_FAIL, now that EXIT_FAILURE is always 1.
+ * src/system.h (EXIT_FAIL): Remove definition.
+ * src/chroot.c (main): EXIT_FAIL -> EXIT_FAILURE.
+ * src/env.c (main): Likewise.
+ * src/nice.c (main): Likewise.
+ * src/su.c (change_identity, main): Likewise.
+ * src/tty.c (main): Likewise.
+ Suggestion from Eric Blake.
+
2007-08-28 Jim Meyering <[EMAIL PROTECTED]>
* src/test.c (usage): Note that [ honors --help and --version,
diff --git a/src/chroot.c b/src/chroot.c
index 67bf074..4d23fab 100644
--- a/src/chroot.c
+++ b/src/chroot.c
@@ -70,25 +70,25 @@ main (int argc, char **argv)
bindtextdomain (PACKAGE, LOCALEDIR);
textdomain (PACKAGE);
- initialize_exit_failure (EXIT_FAIL);
+ initialize_exit_failure (EXIT_FAILURE);
atexit (close_stdout);
parse_long_options (argc, argv, PROGRAM_NAME, GNU_PACKAGE, VERSION,
usage, AUTHORS, (char const *) NULL);
if (getopt_long (argc, argv, "+", NULL, NULL) != -1)
-usage (EXIT_FAIL);
+usage (EXIT_FAILURE);
if (argc <= optind)
{
error (0, 0, _("missing operand"));
- usage (EXIT_FAIL);
+ usage (EXIT_FAILURE);
}
if (chroot (argv[optind]) != 0)
-error (EXIT_FAIL, errno, _("cannot change root directory to %s"), argv[1]);
+error (EXIT_FAILURE, errno, _("cannot change root directory to %s"),
argv[1]);
if (chdir ("/"))
-error (EXIT_FAIL, errno, _("cannot chdir to root directory"));
+error (EXIT_FAILURE, errno, _("cannot chdir to root directory"));
if (argc == optind + 1)
{
diff --git a/src/env.c b/src/env.c
index 52e24aa..14a62d0 100644
--- a/src/env.c
+++ b/src/env.c
@@ -146,7 +146,7 @@ main (int argc, char **argv)
bindtextdomain (PACKAGE, LOCALEDIR);
textdomain (PACKAGE);
- initialize_exit_failure (EXIT_FAIL);
+ initialize_exit_failure (EXIT_FAILURE);
atexit (close_stdout);
while ((optc = getopt_long (argc, argv, "+iu:", longopts, NULL)) != -1)
@@ -161,7 +161,7 @@ main (int argc, char **argv)
case_GETOPT_HELP_CHAR;
case_GETOPT_VERSION_CHAR (PROGRAM_NAME, AUTHORS);
default:
- usage (EXIT_FAIL);
+ usage (EXIT_FAILURE);
}
}
diff --git a/src/nice.c b/src/nice.c
index 4624e48..7892fea 100644
--- a/src/nice.c
+++ b/src/nice.c
@@ -104,7 +104,7 @@ main (int argc, char **argv)
bindtextdomain (PACKAGE, LOCALEDIR);
textdomain (PACKAGE);
- initialize_exit_failure (EXIT_FAIL);
+ initialize_exit_failure (EXIT_FAILURE);
atexit (close_stdout);
parse_long_options (argc, argv, PROGRAM_NAME, GNU_PACKAGE, VERSION,
@@ -135,7 +135,7 @@ main (int argc, char **argv)
i += optind - 1;
if (optc == '?')
- usage (EXIT_FAIL);
+ usage (EXIT_FAILURE);
else if (optc == 'n')
adjustment_given = optarg;
else /* optc == -1 */
@@ -151,7 +151,7 @@ main (int argc, char **argv)
enum { MIN_ADJUSTMENT = 1 - 2 * NZERO, MAX_ADJUSTMENT = 2 * NZERO - 1 };
long int tmp;
if (LONGINT_OVERFLOW < xstrtol (adjustment_given, NULL, 10, &tmp, ""))
- error (EXIT_FAIL, 0, _("invalid adjustment %s"),
+ error (E
Re: touch command
Hi, Thank you all for your enlightening comments. Best regards, Paulo Nogueira ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Command line parsing of ls with genparse
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Michael Geng on 8/28/2007 12:33 PM: > > In the present version of genparse new strings are always printed > in new lines. For example (also from the ls commmand): > > d / directory flag"list directory entries instead of > contents," > " and do not dereference symbolic > links" Why not make genparse a bit smarter, and let the user supply free-form text as the option description. Genparse should then wrap it to fit an 80-column screen before generating the resulting usage() in the .c file. Then the above example would simply be: d / directory flag \ "list directory entries instead of contents, and do not dereference symbolic links" with the __GNU_GLOSSARY__(29) being the formatting hint of where the auto-wrapping should occur in the output English text. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG1OM/84KuGfSFAYARAt2kAKCwODGWB8MgUxtnltO0O9HFdUCThwCdGEGH 3IWLqYyRObHty4aDcxJX4oo= =y+0l -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
