New option for ln, firmlinks!
Howdy,
The following hack implements the --firm/-m option for ln so that it
will create firm links. Now, most GNU/Linux people won't be familiar
with the concept, and I'm not really sure how to explain it either.
The best example I can think of that explains the difference between
symlinks and firmlinks is the following:
hurd:/home/ams/coreutils/coreutils/src# ./ln -s /ams/foo symlink
hurd:/home/ams/coreutils/coreutils/src# ./ln -m /ams/foo firmlink
hurd:/home/ams/coreutils/coreutils/src# cd symlink
hurd:/home/ams/coreutils/coreutils/src/symlink# ls ..
foo hurd.obj lost+found oskit.obj sub-hurd
hurd:/home/ams/coreutils/coreutils/src/symlink# cd ../firmlink
hurd:/home/ams/coreutils/coreutils/src/firmlink# ls ..
CVS
Makefile
Makefile.am
[..snip...]
hurd:/home/ams/coreutils/coreutils/src/firmlink# ls
hurd:/home/ams/coreutils/coreutils/src/firmlink# ls /ams/foo
hurd:/home/ams/coreutils/coreutils/src/firmlink# touch foo
hurd:/home/ams/coreutils/coreutils/src/firmlink# ls -l
total 0
-rw-r--r--1 root root0 Jan 25 02:48 foo
hurd:/home/ams/coreutils/coreutils/src/firmlink# ls -l /ams/foo
total 0
-rw-r--r--1 root root0 Jan 25 02:48 foo
hurd:/home/ams/coreutils/coreutils/src/firmlink#
As you see, a firmlink is more or less a "real" link, and doesn't
exhibit the sometimes awkward behaviour of symbolic links (`ls ..' is
one such example).
Note that I didn't bother in creating a NEWS entry, or updating the
manual. This is mostly a hack that I just wanted to share and get
some comments about. For example, firmlink() should be moved into
libc, _HURD_FIRMLINK should be defined in , propor
autoconf checks should be created so that ln will compile on system
that don't support firmlinks, etc.
2004-01-24 Alfred M. Szmidt <[EMAIL PROTECTED]>
Added new option for `ln', --firm.
* src/ln.c (firm_link): New variable.
(long_options): Support new option `--firm'.
(_HURD_FIRMLINK): New macro.
(hurd_fail, firmlink): New functions.
(do_link, usage, main): Support new option `--firm'.
(do_link): Allow the creation of firmlinks for directories.
*** src/ln.c.~1.132.~ Sat Oct 18 03:05:47 2003
--- src/ln.cSun Jan 25 02:32:05 2004
***
*** 96,107
enum backup_type backup_type;
/* A pointer to the function used to make links. This will point to either
!`link' or `symlink'. */
static int (*linkfunc) ();
/* If nonzero, make symbolic links; otherwise, make hard links. */
static int symbolic_link;
/* If nonzero, ask the user before removing existing files. */
static int interactive;
--- 96,110
enum backup_type backup_type;
/* A pointer to the function used to make links. This will point to either
!`link', `symlink' or `firmlink'. */
static int (*linkfunc) ();
/* If nonzero, make symbolic links; otherwise, make hard links. */
static int symbolic_link;
+ /* If nonzero, make firm links; otherwise make hard links. */
+ static int firm_link;
+
/* If nonzero, ask the user before removing existing files. */
static int interactive;
***
*** 133,138
--- 136,142
{"suffix", required_argument, NULL, 'S'},
{"target-directory", required_argument, NULL, TARGET_DIRECTORY_OPTION},
{"symbolic", no_argument, NULL, 's'},
+ {"firm", no_argument, NULL, 'm'},
{"verbose", no_argument, NULL, 'v'},
{"version-control", required_argument, NULL, 'V'}, /* Deprecated. FIXME. */
{GETOPT_HELP_OPTION_DECL},
***
*** 140,145
--- 144,234
{NULL, 0, NULL, 0}
};
+ /* Snatched from glibc; and modified for firm links and some sort of
+stand-aloneness. Should really be moved back into libc as a real
+call. */
+
+ #include
+ #include
+ #include
+ #include
+ #include
+
+ #define _HURD_FIRMLINK _HURD "firmlink"
+
+ int
+ hurd_fail (error_t err)
+ {
+ switch (err)
+ {
+ case EMACH_SEND_INVALID_DEST:
+ case EMIG_SERVER_DIED:
+ /* The server has disappeared! */
+ err = EIEIO;
+ break;
+
+ case KERN_NO_SPACE:
+ err = ENOMEM;
+ break;
+
+ case KERN_INVALID_ARGUMENT:
+ err = EINVAL;
+ break;
+
+ case 0:
+ return 0;
+
+ default:
+ break;
+ }
+
+ errno = err;
+ return -1;
+ }
+
+ int
+ firmlink (const char *from, const char *to)
+ {
+ error_t err;
+ file_t dir, node;
+ char *name;
+ const size_t len = strlen (from) + 1;
+ char buf[sizeof (_HURD_FIRMLINK) + len];
+ mode_t umask = getumask ();
+
+ /* A firmlink is a file whose translator is "/hurd/firmlink\0target\0". */
+
+ memcpy (buf, _HURD_FIRMLINK, sizeof (_HURD_FIRMLINK));
+ memcpy (&buf[sizeof (_HURD_FIRMLINK)], from, len);
+
+ dir = file_name_split (to, &name);
+ if (dir == MACH_PORT_NULL)
+ return -1;
+
+ /* Create a new, unlinked node in the target directory. */
+ err = d
Re: New option for ln, firmlinks!
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes: > Howdy, > > The following hack implements the --firm/-m option for ln so that it > will create firm links. Now, most GNU/Linux people won't be familiar > with the concept, and I'm not really sure how to explain it either. > The best example I can think of that explains the difference between > symlinks and firmlinks is the following: > > hurd:/home/ams/coreutils/coreutils/src# ./ln -s /ams/foo symlink > hurd:/home/ams/coreutils/coreutils/src# ./ln -m /ams/foo firmlink > hurd:/home/ams/coreutils/coreutils/src# cd symlink > hurd:/home/ams/coreutils/coreutils/src/symlink# ls .. > foo hurd.obj lost+found oskit.obj sub-hurd > hurd:/home/ams/coreutils/coreutils/src/symlink# cd ../firmlink > hurd:/home/ams/coreutils/coreutils/src/firmlink# ls .. > CVS > Makefile > Makefile.am > [..snip...] This looks similar to bind mounts in Linux. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: New option for ln, firmlinks!
> hurd:/home/ams/coreutils/coreutils/src# ./ln -s /ams/foo symlink > hurd:/home/ams/coreutils/coreutils/src# ./ln -m /ams/foo firmlink > hurd:/home/ams/coreutils/coreutils/src# cd symlink > hurd:/home/ams/coreutils/coreutils/src/symlink# ls .. > foo hurd.obj lost+found oskit.obj sub-hurd > hurd:/home/ams/coreutils/coreutils/src/symlink# cd ../firmlink > hurd:/home/ams/coreutils/coreutils/src/firmlink# ls .. > CVS > Makefile > Makefile.am > [..snip...] This looks similar to bind mounts in Linux. Are those the same thing as union file-systems (BSD has them, and the Hurd has a alpha translator for it written by Moritz Schulte; it was called shadow file-systems before)? Cheers. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: ls --color feature request: ordinary files uncoloured
Jim Meyering <[EMAIL PROTECTED]> wrote:
>>I think it would be better for plain files to not have any ANSI
>>escape sequences around them, and for colouring to apply only to
>>directories, *.gz and so on.
>>Shall I send a patch for this?
>
>Please do.
diff -ru coreutils-5.0.91/src/ls.c coreutils-5.0.91.new/src/ls.c
--- coreutils-5.0.91/src/ls.c 2003-07-27 07:33:36.0 +0100
+++ coreutils-5.0.91.new/src/ls.c 2004-01-24 18:13:49.334955240 +
@@ -253,7 +253,7 @@
static int file_interesting (const struct dirent *next);
static uintmax_t gobble_file (const char *name, enum filetype type,
int explicit_arg, const char *dirname);
-static void print_color_indicator (const char *name, mode_t mode, int linkok);
+static bool print_color_indicator (const char *name, mode_t mode, int linkok);
static void put_indicator (const struct bin_str *ind);
static int put_indicator_direct (const struct bin_str *ind);
static int length_of_file_name_and_frills (const struct fileinfo *f);
@@ -499,6 +499,13 @@
static int print_with_color;
+/* Whether we used any colors in the output so far. If so, we will
+ need to restore the default color later. If not, we will need to
+ print some stuff (prep_non_filename_text ()) before using color for
+ the first time. */
+
+static bool used_color = false;
+
enum color_type
{
color_never, /* 0: default or --color=never */
@@ -517,13 +524,13 @@
enum indicator_no
{
-C_LEFT, C_RIGHT, C_END, C_NORM, C_FILE, C_DIR, C_LINK, C_FIFO, C_SOCK,
+C_LEFT, C_RIGHT, C_END, C_RESET, C_NORM, C_FILE, C_DIR, C_LINK, C_FIFO, C_SOCK,
C_BLK, C_CHR, C_MISSING, C_ORPHAN, C_EXEC, C_DOOR
};
static const char *const indicator_name[]=
{
-"lc", "rc", "ec", "no", "fi", "di", "ln", "pi", "so",
+"lc", "rc", "ec", "rs", "no", "fi", "di", "ln", "pi", "so",
"bd", "cd", "mi", "or", "ex", "do", NULL
};
@@ -539,8 +546,9 @@
{ LEN_STR_PAIR ("\033[") },/* lc: Left of color sequence */
{ LEN_STR_PAIR ("m") },/* rc: Right of color sequence */
{ 0, NULL }, /* ec: End color (replaces lc+no+rc) */
-{ LEN_STR_PAIR ("0") },/* no: Normal */
-{ LEN_STR_PAIR ("0") },/* fi: File: default */
+{ LEN_STR_PAIR ("0") },/* rs: Reset to ordinary colors */
+{ 0, NULL }, /* no: Normal */
+{ 0, NULL }, /* fi: File: default */
{ LEN_STR_PAIR ("01;34") },/* di: Directory: bright blue */
{ LEN_STR_PAIR ("01;36") },/* ln: Symlink: bright cyan */
{ LEN_STR_PAIR ("33") }, /* pi: Pipe: yellow/brown */
@@ -993,7 +1001,8 @@
signal (sig, SIG_IGN);
#endif
- restore_default_color ();
+ if (used_color)
+restore_default_color ();
/* SIGTSTP is special, since the application can receive that signal more
than once. In this case, don't set the signal handler to the default.
@@ -1051,7 +1060,6 @@
may have just reset it -- e.g., if LS_COLORS is invalid. */
if (print_with_color)
{
- prep_non_filename_text ();
/* Avoid following symbolic links when possible. */
if (color_indicator[C_ORPHAN].string != NULL
|| (color_indicator[C_MISSING].string != NULL
@@ -1208,7 +1216,7 @@
}
/* Restore default color before exiting */
- if (print_with_color)
+ if (used_color)
{
put_indicator (&color_indicator[C_LEFT]);
put_indicator (&color_indicator[C_RIGHT]);
@@ -3271,8 +3279,8 @@
print_name_with_quoting (const char *p, mode_t mode, int linkok,
struct obstack *stack)
{
- if (print_with_color)
-print_color_indicator (p, mode, linkok);
+ const bool used_color_this_time
+= print_with_color && print_color_indicator (p, mode, linkok);
if (stack)
PUSH_CURRENT_DIRED_POS (stack);
@@ -3282,7 +3290,7 @@
if (stack)
PUSH_CURRENT_DIRED_POS (stack);
- if (print_with_color)
+ if (used_color_this_time)
prep_non_filename_text ();
}
@@ -3294,7 +3302,7 @@
else
{
put_indicator (&color_indicator[C_LEFT]);
- put_indicator (&color_indicator[C_NORM]);
+ put_indicator (&color_indicator[C_RESET]);
put_indicator (&color_indicator[C_RIGHT]);
}
}
@@ -3354,7 +3362,8 @@
DIRED_PUTCHAR (c);
}
-static void
+/* Returns whether any color sequence was printed. */
+static bool
print_color_indicator (const char *name, mode_t mode, int linkok)
{
int type = C_FILE;
@@ -3406,16 +3415,32 @@
}
}
}
-
- put_indicator (&color_indicator[C_LEFT]);
- put_indicator (ext ? &(ext->seq) : &color_indicator[type]);
- put_indicator (&color_indicator[C_RIGHT]);
+
+ {
+const struct bin_str *const s
+ = ext ? &(ext->seq) : &color_indicator[type];
+if (s->string != NULL)
+ {
+ put_indicator (&color_indicator[C_LEFT]);
+ put_indica
Re: bug in hostname
Paul Jarc wrote: > A hostname program does not need to talk to the network at all. The > kernel keeps exactly one hostname in memory, and the hostname program > gets/sets it via gethostname()/sethostname(). It's fine to also > provide access to any names found in DNS, but that isn't central. Partially agree. I agree with the first part. But the -f, --fqdn in particular must use DNS if the real hostname is not already fully qualified. The lack of that functionality is one things that started a previous thread recently. If hostname is getting redone then it would be best to handle this case. > When it comes to DNS, there can be multiple names, but there need not > be any "primary" name among them. There can be, and often is, but > it's also possible that all may have equal standing. If all you have > to start with is an IP address, though, then you're probably only > going to find one name from there anyway. This is one of the reasons that personally I prefer setting the hostname to the fully qualifed domain name. It just seems cleaner. There is no ambiguity. Others disagree and try to do the reverse DNS mappings to find the fqdn. But that can be incorrect in a number of ways as you imply. > >> - why some programs expect IP addresses with brackets and some don't? > > Unless both kinds of programs invoke "hostname -i", we don't need to > care about that. It would seem to be easier to add the brackets than to remove them. I personally can't think of any case of a program using 'hostname -i' which would be correct. Or that 127.0.0.1 would not always be just as correct. What is returned if the machine has multiple network addresses? How would returning the first IP address always be correct in the presence of multiple network devices? I would deprecate that option. Or at least warn against it strongly. Bob ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: New option for ln, firmlinks!
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes: >> hurd:/home/ams/coreutils/coreutils/src# ./ln -s /ams/foo symlink >> hurd:/home/ams/coreutils/coreutils/src# ./ln -m /ams/foo firmlink >> hurd:/home/ams/coreutils/coreutils/src# cd symlink >> hurd:/home/ams/coreutils/coreutils/src/symlink# ls .. >> foo hurd.obj lost+found oskit.obj sub-hurd >> hurd:/home/ams/coreutils/coreutils/src/symlink# cd ../firmlink >> hurd:/home/ams/coreutils/coreutils/src/firmlink# ls .. >> CVS >> Makefile >> Makefile.am >> [..snip...] > >This looks similar to bind mounts in Linux. > > Are those the same thing as union file-systems I don't know much about union file-systems, but AFAIK they are different from bind mounts. A bind mount is created by "mount -o bind /foo /bar" and causes the tree under /foo to be overlayed over /bar, with the former contents of /bar being hidden. It's like a regular mount, except that the source is not (a filesystem on) a block device, but a directory. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: New option for ln, firmlinks!
I don't know much about union file-systems, but AFAIK they are different from bind mounts. A bind mount is created by "mount -o bind /foo /bar" and causes the tree under /foo to be overlayed over /bar, with the former contents of /bar being hidden. It's like a regular mount, except that the source is not (a filesystem on) a block device, but a directory. It does sound a bit similar to firmlinks. But firmlinks work on any kind of type of file (directories, symlinks, ...). I don't know if this bind file-system can be used across chroots, but firmlinks can. Cheers. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: New option for ln, firmlinks!
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes: >I don't know much about union file-systems, but AFAIK they are >different from bind mounts. A bind mount is created by "mount -o >bind /foo /bar" and causes the tree under /foo to be overlayed over >/bar, with the former contents of /bar being hidden. It's like a >regular mount, except that the source is not (a filesystem on) a >block device, but a directory. > > It does sound a bit similar to firmlinks. But firmlinks work on any > kind of type of file (directories, symlinks, ...). I don't know if > this bind file-system can be used across chroots, but firmlinks can. You can also bind-mount a regular file (and probably other types, I didn't try yet). The only difference to firmlinks is, at it seems, that the destination must already exist and it must be of the same type as the source. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: New option for ln, firmlinks!
You can also bind-mount a regular file (and probably other types, I didn't try yet). The only difference to firmlinks is, at it seems, that the destination must already exist and it must be of the same type as the source. Not entirerly true, the source and destination aren't the same in any way, the source just has a translator attached to it that transmits all file-system calls to the destination. But other than that, it does seem that they are quite the same. Was it possible to jump out of a chroot with bind's? I might note that `ln --firm TARGET LINK_NAME' is sugar for `settrans -cp TARGET /hurd/firmlink LINK_NAME`. The same really goes when using --symbolic; but with s/firm/sym/. But symbolic links are optimised a bit in the file-system, i.e. they aren't treated as "real" translators. Cheers. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: New option for ln, firmlinks!
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes: >You can also bind-mount a regular file (and probably other types, I >didn't try yet). The only difference to firmlinks is, at it seems, >that the destination must already exist and it must be of the same >type as the source. > > Not entirerly true, the source and destination aren't the same in any > way, The last sentence above was attributed to bind mounts, not to firmlinks. > Was it possible to jump out of a chroot with bind's? Not sure what you mean. A bind-mountpoint behaves like any other mountpoint. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: New option for ln, firmlinks!
> Was it possible to jump out of a chroot with bind's? Not sure what you mean. A bind-mountpoint behaves like any other mountpoint. Well, can you do the something along the following with bind-mountpoints (using settrans to be clear): $ settrans -ac /new-root/etc /hurd/firmlink /etc $ chroot /new-root $ cat /etc/passwd And get the content of REAL-ROOT/etc/passwd for example? Cheers. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: New option for ln, firmlinks!
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes: > Well, can you do the something along the following with > bind-mountpoints (using settrans to be clear): > > $ settrans -ac /new-root/etc /hurd/firmlink /etc > $ chroot /new-root > $ cat /etc/passwd > > And get the content of REAL-ROOT/etc/passwd for example? Yes. The binding is evaluated at mount-time. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: New option for ln, firmlinks!
> Well, can you do the something along the following with > bind-mountpoints (using settrans to be clear): > > $ settrans -ac /new-root/etc /hurd/firmlink /etc > $ chroot /new-root > $ cat /etc/passwd > > And get the content of REAL-ROOT/etc/passwd for example? Yes. The binding is evaluated at mount-time. Corking, maybe something like this could be added to libc when/if firmlink() moves there and then make --firm work with that too. Cheers! ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: bug in hostname
[EMAIL PROTECTED] (Bob Proulx) wrote: > But the -f, --fqdn in particular must use DNS if the real hostname > is not already fully qualified. Well, that's one way it can try to go about it. There's also getdomainname(), on systems that have it, or uname(). One might also argue that it would be reasonable to just fail or give the short name - i.e., it's the admin's responsibility to make "hostname -f" work, by setting the kernel's hostname to the fqdn. > This is one of the reasons that personally I prefer setting the > hostname to the fully qualifed domain name. It just seems cleaner. > There is no ambiguity. Yep. paul ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
coreutils-5.1.2 released
This is a bug-fix-only release. I hope to make a `stable' release pretty soon, so if you know of any outstanding bugs, please report (or re-report) them ASAP. Here are the compressed sources: ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.1.2.tar.gz (6.2MB) ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.1.2.tar.bz2 (4.1MB) http://fetish.sf.net/coreutils-5.1.2.tar.gz (6.2MB) http://fetish.sf.net/coreutils-5.1.2.tar.bz2 (4.1MB) And here are xdelta-style diffs: ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.1.1-5.1.2.xdelta (256KB) http://fetish.sf.net/coreutils-5.1.1-5.1.2.xdelta (256KB) Here are GPG detached signatures: ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.1.2.tar.gz.sig ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.1.2.tar.bz2.sig http://fetish.sf.net/coreutils-5.1.2.tar.gz.sig http://fetish.sf.net/coreutils-5.1.2.tar.bz2.sig Here are the MD5 and SHA1 signatures: 742002ec256aa47e67614425f9914bba coreutils-5.1.2.tar.gz 91a983a0f45d290f1a9ec00f51c58e4c coreutils-5.1.2.tar.bz2 a2d8e59ce28b9ed9102ea4a76afd580c coreutils-5.1.1-5.1.2.xdelta 0c9fd272547b441ba3b823495bbf88861a281d0f coreutils-5.1.2.tar.gz bab590c6daebbd27e0aa25a22213a332fc9bb3f5 coreutils-5.1.2.tar.bz2 f9223b17c4774c54040c6eb10ba83c31731cd91f coreutils-5.1.1-5.1.2.xdelta NEWS * Major changes in release 5.1.2 (2004-01-25): ** Bug fixes rmdir -p exits with status 1 on error; formerly it sometimes exited with status 0 when given more than one argument. nohup now always exits with status 127 when it finds an error, as POSIX requires; formerly it sometimes exited with status 1. Several programs (including cut, date, dd, env, hostname, nl, pr, stty, and tr) now always exit with status 1 when they find an error; formerly they sometimes exited with status 2. factor no longer reports a usage error if stdin has the wrong format. paste no longer infloops on ppc systems (bug introduced in 5.1.1) ChangeLog entries: ** ChangeLog ** 2004-01-25 Jim Meyering <[EMAIL PROTECTED]> * Version 5.1.2. * Makefile.maint (signatures): Comment out definition. 2004-01-23 Jim Meyering <[EMAIL PROTECTED]> * Makefile.maint (header_regexp): Add exitfail. * man/Makefile.am (EXTRA_DIST): Add help2man. Reported by Nelson H. F. Beebe. * man/Makefile.am (.x.1): Prefix help2man invocation with `$(PERL) --' so it works on systems with Perl installed somewhere other than in /usr/bin. * src/paste.c (paste_parallel): Declare local, chr, to be of type `int', not `char', since it must hold EOF. This bug would make paste infloop on some systems. Test failures reported by Nelson H. F. Beebe and Christian Krackowizer. 2004-01-22 Jim Meyering <[EMAIL PROTECTED]> * tests/rmdir/fail-perm: New file. Test for just-fixed rmdir bug. * tests/rmdir/Makefile.am (TESTS): Add fail-perm. * man/help2man: Fix it so using --info-page='coreutils PROG' works. * man/Makefile.am (.x.1): Invoke our own (tweaked) copy of help2man. Use --info-page='coreutils PROG' option. Now, readlink.1 refers the user to `info coreutils readlink' rather than to `info readlink'. Reported by Matt Swift. 2004-01-21 Paul Eggert <[EMAIL PROTECTED]> Exit status cleanup. * src/basename.c (usage): Use EXIT_SUCCESS, not 0, for clarity. * src/cat.c, src/chgrp.c, src/chmod.c, src/chown.c, src/chroot.c, * src/cksum.c, src/comm.c, src/cp.c, src/csplit.c, src/cut.c, * src/date.c, src/dd.c, src/df.c, src/dircolors.c, src/dirname.c, * src/du.c, src/echo.c, src/env.c, src/expand.c, src/expr.c, * src/factor.c, src/fmt.c, src/fold.c, src/head.c, src/hostid.c, * src/hostname.c, src/id.c, src/install.c, src/join.c, src/kill.c, * src/link.c, src/ln.c, src/logname.c, src/ls.c, src/md5sum.c, * src/mkdir.c, src/mkfifo.c, src/mknod.c, src/mv.c, src/nice.c, * src/nl.c, src/nohup.c, src/od.c, src/paste.c, src/pathchk.c, * src/pinky.c, src/pr.c, src/printenv.c, src/printf.c, src/pwd.c, * src/rm.c, src/rmdir.c, src/seq.c, src/setuidgid.c, src/shred.c, * src/sleep.c, src/sort.c, src/split.c, src/stat.c, src/stty.c, * src/su.c, src/sum.c, src/sync.c, src/tac.c, src/tail.c, src/tee.c, * src/test.c, src/touch.c, src/tr.c, src/tsort.c, src/tty.c, * src/uname.c, src/unexpand.c, src/uniq.c, src/unlink.c, src/uptime.c, * src/users.c, src/wc.c, src/who.c, src/whoami.c, src/yes.c: Likewise. * src/cat.c (usage): Don't bother normalizing exit status since the arg is already the correct exit status now. * src/cksum.c, src/comm.c, src/csplit.c, src/cut.c, * src/dircolors.c, src/expand.c, src/fmt.c, src/fold.c, src/hea
