Re: md5sum and filenames containing \
Olivier Delhomme wrote: > Here I have coreutils 5.2.1, debian 3.1 unstable, bash 3.00.16(1) > and I can not reproduce your problem. The hash value is correct and > without the \ at the beginning. On my Debian system the md5sum utility is not the GNU one but is from a different source and is included in the dpkg package. It is a compatibility issue. As you note it does not behave this way. The GNU md5sum is shipped on Debian as md5sum.textutils. In this particular case bash is not involved. I can reproduce the behavior with the latest GNU md5sum 5.3.1. However I also don't know why it is programed that way. It is obviously intentional. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: md5sum and filenames containing \
Olivier Delhomme wrote:
On Sun, 03 Apr 2005 23:34:00 +0100, Steve Lilly was saying :
Dear GNU,
I was testing one of my own scripts for robustness against exotic
filenames containing "\" when I noticed a peculiar behaviour from the
md5sum utility (version 5.2.1). To demonstrate:
[EMAIL PROTECTED] test]$ touch test\\test
[EMAIL PROTECTED] test]$ ls
test\test
[EMAIL PROTECTED] test]$ md5sum *
\d41d8cd98f00b204e9800998ecf8427e test\\test
I have tried this with bash and tcsh. ls confirms the file has a single
\ character. It appears (to me at least) that md5sum is escaping the \
to \\, but I'm baffled as to the extra \ at the beginning of the hash!
Here I have coreutils 5.2.1, debian 3.1 unstable, bash 3.00.16(1)
and I can not reproduce your problem. The hash value is correct and
without the \ at the beginning.
Please could you tell us which is your system and bash version ?
Regards,
Steve Lilly
Regards,
Olivier Delhomme.
GNU bash, version 2.05b.0(1)-release (i386-redhat-linux-gnu)
Fedora Core release 2 (Tettnang)
On a little further investigation, I think I have found the culprit in
md5sum.c:
230:
/* Ignore this line if it is too short.
Each line must have at least `min_digest_line_length - 1' (or one
more, if
the first is a backslash) more characters to contain correct message
digest
information. */
if (s_len - i < min_digest_line_length + (s[i] == '\\'))
return 1;
if (s[i] == '\\')
{
++i;
escaped_filename = 1;
}
693:
/* Output a leading backslash if the file name contains
a newline or backslash. */
if (strchr (file, '\n') || strchr (file, '\\'))
putchar ('\\');
So it appears to be intended behaviour, though why I'm not sure...
Steve Lilly.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: FYI: --help now warns about built-in conflicts
> FYI, > Before, 3 man pages (echo, printf, pwd) included a warning like this: > > NOTE: your shell may have its own version of printf, which usually > supersedes > the version described here. Please refer to your shell's documentation > for details about the options it supports. > > I've put that warning in the --help output of 7 commands (actually, > it's 8.5 if you count `[' and `false'), so it will now appear > automatically in the generated man/*.1 files. If anyone knows of any > other coreutils commands that are built-in, please let me know. tcsh provides nice, nohup, and printenv. Not that csh-variants are POSIX-compliant, but they are often a user's default shell, so these three should also get the warning. > > Initially, I added those three lines at the very top (between the Usage > line(s) > and the short description), since mistaking the man-page as a reference > for the built-in is such a common problem. But I didn't like that. > Now it's at the end, e.g.: Is there any way to get the --help output to put the warning at the end, but the man page to list it at the front? With --help, the last thing printed is most important, but in man pages, the first screenful is most important. What does help2man offer to help us acheive this? Do we need a new section name? -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
I: tee doesn't handle dash properly
Hi, According to NEWS file, "tee -" now writes to standard output instead of to a file named "-". However, tee closes stdout more than once if file is named "-": $ env -i tee - ftp://ftp.altlinux.org/pub/people/ldv/coreutils/coreutils-5.3.1-alt-tee.patch -- ldv pgpw5D5maALtO.pgp Description: PGP signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: md5sum and filenames containing \
On Sun, 03 Apr 2005 23:34:00 +0100, Steve Lilly was saying : > Dear GNU, > > I was testing one of my own scripts for robustness against exotic > filenames containing "\" when I noticed a peculiar behaviour from the > md5sum utility (version 5.2.1). To demonstrate: > > [EMAIL PROTECTED] test]$ touch test\\test > [EMAIL PROTECTED] test]$ ls > test\test > [EMAIL PROTECTED] test]$ md5sum * > \d41d8cd98f00b204e9800998ecf8427e test\\test > > I have tried this with bash and tcsh. ls confirms the file has a single > \ character. It appears (to me at least) that md5sum is escaping the \ > to \\, but I'm baffled as to the extra \ at the beginning of the hash! Here I have coreutils 5.2.1, debian 3.1 unstable, bash 3.00.16(1) and I can not reproduce your problem. The hash value is correct and without the \ at the beginning. Please could you tell us which is your system and bash version ? > Regards, > Steve Lilly Regards, Olivier Delhomme. pgphbwwQ8Oavk.pgp Description: PGP signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
FYI: --help now warns about built-in conflicts
FYI, Before, 3 man pages (echo, printf, pwd) included a warning like this: NOTE: your shell may have its own version of printf, which usually supersedes the version described here. Please refer to your shell's documentation for details about the options it supports. I've put that warning in the --help output of 7 commands (actually, it's 8.5 if you count `[' and `false'), so it will now appear automatically in the generated man/*.1 files. If anyone knows of any other coreutils commands that are built-in, please let me know. I noticed only recently that some versions of zsh provide a builtin-like `stat' module. I've just done this: * src/echo.c (usage): Mention that some shells provide a built-in function by the same name. * src/kill.c (usage): Likewise * src/printf.c (usage): Likewise. * src/pwd.c (usage): Likewise. * src/stat.c (usage): Likewise. * src/test.c (usage): Likewise. * src/true.c (usage): * src/system.h (USAGE_BUILTIN_WARNING): New macro. * man/echo.x: Remove `DESCRIPTION' section, now that --help includes it. * man/printf.x: Likewise. * man/pwd.x: Likewise. Initially, I added those three lines at the very top (between the Usage line(s) and the short description), since mistaking the man-page as a reference for the built-in is such a common problem. But I didn't like that. Now it's at the end, e.g.: Usage: ./echo [OPTION]... [STRING]... Echo the STRING(s) to standard output. -n do not output the trailing newline -e enable interpretation of backslash escapes -E disable interpretation of backslash escapes (default) --help display this help and exit --version output version information and exit If -e is in effect, the following sequences are recognized: \0NNN the character whose ASCII code is NNN (octal) \\ backslash \a alert (BEL) \b backspace \c suppress trailing newline \f form feed \n new line \r carriage return \t horizontal tab \v vertical tab NOTE: your shell may have its own version of echo, which usually supersedes the version described here. Please refer to your shell's documentation for details about the options it supports. Report bugs to . ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: nice: error in help-text about new format
Thanks for your bug report. That hint is removed in coreutils 5.3.0, which you can get here: ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.3.0.tar.gz so the confusion shouldn't occur. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: chmod +++++++++x file
Dan Jacobson <[EMAIL PROTECTED]> writes: > I found I could get away with chmod +x file. Perhaps catch it. POSIX requires support for that. It's weird, but it's probably not worth diagnosing. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: bug in date(1)
John Adams <[EMAIL PROTECTED]> writes:
> Hello,
> I found some weird behavior in the date command version 5.2.1
> date --date=
>displays Sat Apr 2 23:00:00 EST 2005
> while
> date
>displays
> Sun Apr 3 09:56:08 EDT 2005
>
> Seems to be a bug.
Thanks for reporting that. The empty string is supposed to stand for
the start of the current day -- that's in the documentation. I
installed this patch, to both coreutils and gnulib.
2005-04-04 Paul Eggert <[EMAIL PROTECTED]>
* lib/getdate.y (parser_control): rels_seen is now a boolean, not a
count, since there's no maximum. All uses changed.
Add member dsts_seen.
(local_zone): Accumulate dsts_seen rather than relying on tm_isdst
not being INT_MAX.
(get_date): Initialize dsts_seen, and check that it doesn't go over 1.
Use pc_rels_seen to decide whther a date is absolute.
* lib/getdate.y (number): Don't overwrite year.
(get_date): Initialize pc.year.digits to 0, not 4, to enable above
check.
--- lib/getdate.y 21 Feb 2005 08:08:38 - 1.95
+++ lib/getdate.y 4 Apr 2005 19:47:42 -
@@ -175,12 +175,13 @@ typedef struct
long int rel_seconds;
long int rel_ns;
- /* Counts of nonterminals of various flavors parsed so far. */
+ /* Presence or counts of nonterminals of various flavors parsed so far. */
bool timespec_seen;
+ bool rels_seen;
size_t dates_seen;
size_t days_seen;
size_t local_zones_seen;
- size_t rels_seen;
+ size_t dsts_seen;
size_t times_seen;
size_t zones_seen;
@@ -255,7 +256,7 @@ item:
| day
{ pc->days_seen++; }
| rel
- { pc->rels_seen++; }
+ { pc->rels_seen = true; }
| number
;
@@ -306,9 +307,15 @@ time:
local_zone:
tLOCAL_ZONE
- { pc->local_isdst = $1; }
+ {
+ pc->local_isdst = $1;
+ pc->dsts_seen += (0 < $1);
+ }
| tLOCAL_ZONE tDST
- { pc->local_isdst = $1 < 0 ? 1 : $1 + 1; }
+ {
+ pc->local_isdst = 1;
+ pc->dsts_seen += (0 < $1) + 1;
+ }
;
zone:
@@ -504,7 +511,7 @@ unsigned_seconds:
number:
tUNUMBER
{
- if (pc->dates_seen
+ if (pc->dates_seen && ! pc->year.digits
&& ! pc->rels_seen && (pc->times_seen || 2 < $1.digits))
pc->year = $1;
else
@@ -1179,7 +1186,7 @@ get_date (struct timespec *result, char
pc.input = p;
pc.year.value = tmp->tm_year;
pc.year.value += TM_YEAR_BASE;
- pc.year.digits = 4;
+ pc.year.digits = 0;
pc.month = tmp->tm_mon + 1;
pc.day = tmp->tm_mday;
pc.hour = tmp->tm_hour;
@@ -1197,11 +1204,12 @@ get_date (struct timespec *result, char
pc.rel_month = 0;
pc.rel_year = 0;
pc.timespec_seen = false;
+ pc.rels_seen = false;
pc.dates_seen = 0;
pc.days_seen = 0;
- pc.rels_seen = 0;
pc.times_seen = 0;
pc.local_zones_seen = 0;
+ pc.dsts_seen = 0;
pc.zones_seen = 0;
#if HAVE_STRUCT_TM_TM_ZONE
@@ -1269,9 +1277,8 @@ get_date (struct timespec *result, char
*result = pc.seconds;
else
{
- if (1 < pc.times_seen || 1 < pc.dates_seen || 1 < pc.days_seen
- || 1 < (pc.local_zones_seen + pc.zones_seen)
- || (pc.local_zones_seen && 1 < pc.local_isdst))
+ if (1 < (pc.times_seen | pc.dates_seen | pc.days_seen | pc.dsts_seen
+ | (pc.local_zones_seen + pc.zones_seen)))
goto fail;
tm.tm_year = to_year (pc.year) - TM_YEAR_BASE;
@@ -1292,7 +1299,7 @@ get_date (struct timespec *result, char
}
/* Let mktime deduce tm_isdst if we have an absolute time stamp. */
- if (pc.dates_seen | pc.days_seen | pc.times_seen)
+ if (!pc.rels_seen)
tm.tm_isdst = -1;
/* But if the input explicitly specifies local time with or without
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mktexpk: non-POSIX compliant use of "tail"
Paul Eggert <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] (Karl Berry) writes: > >> What harm can there be in *GNU* tail always accepting tail -10? > > I am becoming more inclined to agree with you. I don't know about > Jim, though. I agree. I don't like it, but think it is necessary. I think the best we can do is to `undocument' the old usage, as Paul suggested. After recently fixing bugs (albeit a little obscure) in the mixing of short/obsolete and long-named options of both pr and uniq, I would have liked to maintain only one set of options, but am resigned to being stuck with both. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Command "Who" does not work properly in Linux console
Amir Marani <[EMAIL PROTECTED]> writes: > I am using Mandrake Linux 10. I have a problem when I am using > command 'who' in comsole it does not gives any out put. But when I > gives command: "prompt>who -a" it gives out put. Possibly your /var/run/utmp file (or whatever it is called on your system) is corrupted. Can you please email a copy of it to bug-coreutils@gnu.org, as an attachment? Thanks. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
chmod +++++++++x file
I found I could get away with chmod +x file. Perhaps catch it. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Patch] Adding examples to the man pages
"Dr. David Alan Gilbert" <[EMAIL PROTECTED]> writes:
> OK, here is a handful of stuff against the CVS checkout.
> Is this OK?
A few comments:
We need to have ChangeLog entries.
The programs should use program_name to generate their own names.
(This requires a tweak to man/Makefile.am as shown below.)
I'd scale back on the examples a bit. I don't think users ordinarily
want to know what "basename functions.lisp p", "cat -s", or "chgrp
--reference" do. And the comments can be made shorter without losing
utility. Admittedly these are all judgment calls, but there is a
danger in having too many examples in what is supposed to be a fairly
terse reference.
The examples need to be written up in doc/coreutils.texi as well.
Jim, do you think they should be before or after the exit-status
documentation? The patch below puts it before (since "ln invocation"
already does this), but after might make sense too.
Here is a proposed patch illustrating the sort of format I was
thinking of. Jim, is this worth installing as-is as an "example of
how to do examples", or do you want some more changes to the format,
or do you want all the examples in one big patch?
2005-04-03 Paul Eggert <[EMAIL PROTECTED]>
* doc/coreutils.texi (cat invocation, chown invocation)
(chgrp invocation, basename invocation, dirname invocation):
Add examples.
(ln invocation): Use same format as other examples above,
for consistency.
* man/Makefile.am (.x.1): Remove "COMMAND.td/" from examples.
* src/basename.c (usage): Add examples.
* src/cat.c (usage): Likewise.
* src/chgrp.c (usage): Likewise.
* src/chown.c (usage): Likewise.
* src/dirname.c (usage): Likewise.
Index: doc/coreutils.texi
===
RCS file: /fetish/cu/doc/coreutils.texi,v
retrieving revision 1.246
diff -p -u -r1.246 coreutils.texi
--- doc/coreutils.texi 26 Mar 2005 18:43:30 - 1.246
+++ doc/coreutils.texi 4 Apr 2005 05:25:49 -
@@ -1309,6 +1309,16 @@ characters at the end of each line are a
@end table
+Examples:
+
[EMAIL PROTECTED]
+# Output f's contents, then standard input, then g's contents.
+cat f - g
+
+# Copy standard input to standard output.
+cat
[EMAIL PROTECTED] smallexample
+
@exitstatus
@@ -7703,9 +7713,14 @@ Print the name of each file before linki
Examples:
@smallexample
-ln -s /some/name # creates link ./name pointing to /some/name
-ln -s /some/name myname # creates link ./myname pointing to /some/name
-ln -s a b .. # creates links ../a and ../b pointing to ./a and ./b
+# Create link ./name pointing to /some/name.
+ln -s /some/name
+
+# Create link ./myname pointing to /some/name.
+ln -s /some/name myname
+
+# Create links ../a and ../b pointing to ./a and ./b.
+ln -s a b ..
@end smallexample
@exitstatus
@@ -8264,6 +8279,19 @@ Recursively change ownership of director
@end table
+Examples:
+
[EMAIL PROTECTED]
+# Change the owner of /u to "root".
+chown root /u
+
+# Likewise, but also change its group to "staff".
+chown root:staff /u
+
+# Change the owner of /u and subfiles to "root".
+chown -hR root /u
[EMAIL PROTECTED] smallexample
+
@exitstatus
@@ -8372,6 +8400,16 @@ Recursively change the group ownership o
@end table
+Examples:
+
[EMAIL PROTECTED]
+# Change the group of /u to "staff".
+chgrp staff /u
+
+# Change the group of /u and subfiles to "staff".
+chgrp -hR staff /u
[EMAIL PROTECTED] smallexample
+
@exitstatus
@@ -10186,6 +10224,16 @@ result on standard output.
The only options are @option{--help} and @option{--version}. @xref{Common
options}. Options must precede operands.
+Examples:
+
[EMAIL PROTECTED]
+# Output "sort".
+basename /usr/bin/sort
+
+# Output "stdio".
+basename include/stdio.h .h
[EMAIL PROTECTED] smallexample
+
@exitstatus
@@ -10210,6 +10258,16 @@ If @var{name} is a single component, @co
The only options are @option{--help} and @option{--version}. @xref{Common
options}.
+Examples:
+
[EMAIL PROTECTED]
+# Output "/usr/bin".
+dirname /usr/bin/sort
+
+# Output ".".
+dirname stdio.h
[EMAIL PROTECTED] smallexample
+
@exitstatus
Index: man/Makefile.am
===
RCS file: /fetish/cu/man/Makefile.am,v
retrieving revision 1.37
diff -p -u -r1.37 Makefile.am
--- man/Makefile.am 24 Jan 2005 08:21:39 - 1.37
+++ man/Makefile.am 4 Apr 2005 05:25:49 -
@@ -131,7 +131,7 @@ mapped_name = `echo $*|sed 's/install/gi
(cd $t && $(LN_S) ../../src/$(mapped_name) $*); \
$(PERL) -- $(srcdir)/help2man \
--include=$(srcdir)/$*.x\
- --output=$@ $t/$*
+ $t/$* | sed 's|$*\.td/||g' > $@
@chmod a-w $@
@rm -rf $t
Index: src/basename.c
===
RCS file: /fetish/cu/src/basename.c,v
retrieving revision 1.59
diff -p -u -r1.59 b
Re: mktexpk: non-POSIX compliant use of "tail"
[EMAIL PROTECTED] (Karl Berry) writes: > What harm can there be in *GNU* tail always accepting tail -10? I am becoming more inclined to agree with you. I don't know about Jim, though. Part of the motivation for removing support for usages not allowed by POSIX was conformance. But part of it, to be honest, was the hope of simplifying the maintenance burden. The obsolete usage was buggy and was never documented properly, and I thought it easier to drop it than to fix and document it. But simplification hasn't happened as much as I'd like. Assuming this POSIX compromise becomes official, I'm becoming more inclined to add back support for the more commonly-used obsolete usages that do not conflict with the revised POSIX. This would include "tail -1". It would not include usages that conflict with POSIX (e.g., "tail -c file" as an alias for "tail -c 10 file", or "touch 04030201 file" as an alias for "touch -t 04030201 file"). However, I doubt whether many people rely on these conflicting usages nowadays and you have to draw the line somewhere. Alas, doing this correctly will require some thought -- it's not just a simple switch-flip, since the new default behavior would be neither the 1992 nor the 2001 behavior -- so it's not likely to happen this week. As I mentioned, I was concerned about the hassle of maintaining the user documentation, as describing all the obsolete usages would bloat the documentation and place an extra burden on all users. So, if we do add back support for these obsolete usages, I'd rather not document them in detail. I don't want to burden new users with this ancient backwards-compatibility gorp. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
md5sum and filenames containing \
Dear GNU, I was testing one of my own scripts for robustness against exotic filenames containing "\" when I noticed a peculiar behaviour from the md5sum utility (version 5.2.1). To demonstrate: [EMAIL PROTECTED] test]$ touch test\\test [EMAIL PROTECTED] test]$ ls test\test [EMAIL PROTECTED] test]$ md5sum * \d41d8cd98f00b204e9800998ecf8427e test\\test I have tried this with bash and tcsh. ls confirms the file has a single \ character. It appears (to me at least) that md5sum is escaping the \ to \\, but I'm baffled as to the extra \ at the beginning of the hash! Regards, Steve Lilly ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: dd hangs with SIGINT
Paul Eggert wrote: Guillaume Chazarain <[EMAIL PROTECTED]> writes: With recent linux distributions (using NPTL), dd can hang waiting on a futex when being killed. I'm not quite sure how to parse that, but it sounds like a problem with some part of the system other than "dd", not with "dd" itself. Maybe, I first thought about posting it to LKML. When "dd" gets a signal, it closes the input and output files, prints some statistics, and exits. If it gets a second signal it exits immediately. I don't offhand see why this could cause a hang that was dd's fault. I thought calling fprintf in a signal handler was risky, but it's not, so yes it should not be dd's fault. Sorry for the noise. It sounds like you may need to investigate this on your own host. Actually it happens on many hosts : Fedora Core[1-3] and it disappear with LD_ASSUME_KERNEL=2.4. But if only me can see the "dd frozen"_//_/__/ loop with a recent kernel, my hopes are low :-( You don't mention which version of "dd" you're having the problem with. "dd --version" should tell you. Both 5.2.1 and 5.3.0. Thank you. -- Guillaume ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
nice: error in help-text about new format
First let me thank you for your hard work and all your excellent commands and utilities. I would like to report a bug regarding the 'nice' command. I'm using: => nice (GNU coreutils) 5.2.1 I've noticed that your fazing-out the old way of specifying values for several commands (like 'nice', 'tail' and 'head') with simply a hyphen and the value (e.g. -15) for the n-option and the value (e.g. -n 15). I'm not too keen of this change, and hope you'll also keep the old way (which I'm used to). So, the bug: If you specify the nice-value to 'nice' the old way, you get a help-message... this message is *wrong*: => $ nice -15 top => nice: `-15' option is obsolete; use `-n -15' since => this will be removed in the future Following the hint, would have the *oposite* effect (*increasing* the importance, rather than lowering it), and would require root-priviliges. To get the same effect -- a *lowering* of the importance by increasing the nice-value -- one *should* use: => nice -n 15 top ...a *positive* value! Because "nice -15" is equivelant to "nice -+15", while "nice --15" would be what should become "nice -n -15" with the new notation. The first "-" in the old writing, specify an *option*, not the sign of the number... Incidently, using "nice --15" gives the *exact* same help-message... ofcourse, *this time* it would be correct. -- Baard Ove KOPPERUD | [EMAIL PROTECTED] 2625 FAABERG | ICQ# : 24367492 NORWAY | AIM : bokopperud = Vidi, vici, veni = ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
bug in date(1)
Hello, I found some weird behavior in the date command version 5.2.1 date --date= displays Sat Apr 2 23:00:00 EST 2005 while date displays Sun Apr 3 09:56:08 EDT 2005 Seems to be a bug. Maybe a usage msg for the first instance [EMAIL PROTECTED] ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Command "Who" does not work properly in Linux console
Hi, I am using Mandrake Linux 10. I have a problem when I am using command 'who' in comsole it does not gives any out put. But when I gives command: "prompt>who -a" it gives out put. My point is that some commands are working and do not. Please let me know if it is possible. Regards, Amir Marani ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: install(1) man page
Rene Kapeller <[EMAIL PROTECTED]> writes: > Too bad, it's realy useful. No way to make that a standard option of > install(1)? If someone contributes a clean patch to implement it, I'd volunteer to review it. The final decision would be Jim's, though. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Patch] Adding examples to the man pages
* Jim Meyering ([EMAIL PROTECTED]) wrote:
> Thanks for persevering.
> Please base your changes on what is in CVS.
> Here are instructions for checking out the latest:
>
> http://savannah.gnu.org/cvs/?group=coreutils
OK, here is a handful of stuff against the CVS checkout.
Is this OK?
Dave
P.S. Which type of copyright thing do I need for this? If someone
can point me at the relevant stuff I'll try and get it sorted.
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\ _|_ http://www.treblig.org |___/
diff -ur ../../orig/coreutils-cvs/src/basename.c src/basename.c
--- ../../orig/coreutils-cvs/src/basename.c 2004-11-17 00:56:25.0
+
+++ src/basename.c 2005-04-03 16:32:28.0 +0100
@@ -64,6 +64,15 @@
"), stdout);
fputs (HELP_OPTION_DESCRIPTION, stdout);
fputs (VERSION_OPTION_DESCRIPTION, stdout);
+ fputs (_("\
+Examples:\n\
+ basename /usr/foo/lossage/functions.l returns functions.l\n\
+ basename /usr/foo/lossage/functions.l .l returns functions\n\
+ basename functions.lisp p returns functions.lis\n\
+ basename functions.foo .bar returns functions.foo\n\
+\n\
+"), stdout);
+
printf (_("\nReport bugs to <%s>.\n"), PACKAGE_BUGREPORT);
}
exit (status);
diff -ur ../../orig/coreutils-cvs/src/cat.c src/cat.c
--- ../../orig/coreutils-cvs/src/cat.c 2004-09-21 23:26:42.0 +0100
+++ src/cat.c 2005-04-03 18:00:19.0 +0100
@@ -118,6 +118,15 @@
-B, --binary use binary writes to the console device.\n\n\
"), stdout);
#endif
+ fputs (_("\n\
+Examples:\n\
+ cat first middle lastConcatenate the three files onto standard output.\n\
+ cat first - last Concatenate 'first', then standard input then\n\
+ 'last' onto standard output.\n\
+ cat -s first lastConcatenate 'first' and 'last' to standard output\n\
+ removing adjacent blank lines. [GNU only]\n\
+\n\
+"), stdout);
printf (_("\nReport bugs to <%s>.\n"), PACKAGE_BUGREPORT);
}
exit (status);
diff -ur ../../orig/coreutils-cvs/src/chgrp.c src/chgrp.c
--- ../../orig/coreutils-cvs/src/chgrp.c2005-03-28 18:47:48.0
+0100
+++ src/chgrp.c 2005-04-03 18:50:52.0 +0100
@@ -153,6 +153,15 @@
"), stdout);
fputs (HELP_OPTION_DESCRIPTION, stdout);
fputs (VERSION_OPTION_DESCRIPTION, stdout);
+ fputs (_("\n\
+Examples:\n\
+ chgrp mygroup file1 file2Change the group ownership of both files
to\n\
+ 'mygroup'.\n\
+ chgrp mygroup -R mydir Change the group ownership of 'mydir' and\n\
+ all children to 'mygroup'.\n\
+ chgrp --reference=myfile file2 Change the group ownership of 'file2' to\n\
+ be the same as 'myfile'. [GNU only]\n\
+"), stdout);
printf (_("\nReport bugs to <%s>.\n"), PACKAGE_BUGREPORT);
}
exit (status);
diff -ur ../../orig/coreutils-cvs/src/chown.c src/chown.c
--- ../../orig/coreutils-cvs/src/chown.c2005-03-28 18:47:06.0
+0100
+++ src/chown.c 2005-04-03 20:32:11.0 +0100
@@ -148,6 +148,18 @@
to login group if implied by a `:' following a symbolic OWNER.\n\
OWNER and GROUP may be numeric as well as symbolic.\n\
"), stdout);
+ fputs (_("\n\
+Examples:\n\
+ chown auser file1 file2 Change the user ownership of both files
to\n\
+ 'auser'.\n\
+ chown -R auser mydir Change the user ownership of 'mydir' and\n\
+ all its children to 'auser'.\n\
+ chown auser:mygroup file1Change the user ownership of 'file1' to\n\
+ 'auser' and group ownership to 'mygroup'.\n\
+ chown --reference=myfile file2 Change the user and group ownership of\n\
+ 'file2' to be as of 'myfile'. [GNU only]\n\
+"), stdout);
+
printf (_("\nReport bugs to <%s>.\n"), PACKAGE_BUGREPORT);
}
exit (status);
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: dd hangs with SIGINT
Guillaume Chazarain <[EMAIL PROTECTED]> writes: > With recent linux distributions (using NPTL), dd can hang waiting on > a futex when being killed. I'm not quite sure how to parse that, but it sounds like a problem with some part of the system other than "dd", not with "dd" itself. When "dd" gets a signal, it closes the input and output files, prints some statistics, and exits. If it gets a second signal it exits immediately. I don't offhand see why this could cause a hang that was dd's fault. It sounds like you may need to investigate this on your own host. You don't mention which version of "dd" you're having the problem with. "dd --version" should tell you. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: bug in the unix join command or maybe in the sort command
Robert Castelo <[EMAIL PROTECTED]> writes: > q.txt==(tab-separated columns) > aa value-aa > a value-a > === > both versions 5.2.1 and 5.3.0 output > > aa value-aa > a value-a > > when sorting over the entire line: > > sort q.txt > > or more specifically: > > sort -k 1,2 q.txt > > should not sort output first "a value-a" than "aa value-aa" > also when sorting over the entire line ?? Yes. And I get the expected behavior with coreutils 5.3.0: $ sort q.txt a value-a aa value-aa Most likely this is a locale problem. What is the output of the "locale" command on your host? Here's what happens with mine: $ locale LANG=POSIX LC_CTYPE="POSIX" LC_NUMERIC="POSIX" LC_TIME="POSIX" LC_COLLATE="POSIX" LC_MONETARY="POSIX" LC_MESSAGES="POSIX" LC_PAPER="POSIX" LC_NAME="POSIX" LC_ADDRESS="POSIX" LC_TELEPHONE="POSIX" LC_MEASUREMENT="POSIX" LC_IDENTIFICATION="POSIX" LC_ALL= ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
