Hope the chgrp and chown docs mention some operating systems don't let
just anyone just change to any group...
chgrp: changing group of `m': Operation not permitted
version 5.97
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/m
Bet you don't document anywhere that/why
$ echo a|cat - -
will only give one "a".
Or maybe even raise an error...
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
MF> what were you expecting to happen ? it is not possible for cat to
MF> re-read stdin once it has consumed it.
Yes, but you don't document it I bet. At least not in the path that
starts with man cat.
Just reading the coreutils docs, one wouldn't know why
$ date|cat q b - c q - q - b
worked exce
Yes yes. I'm just saying supposing a theoretical new user's first
encounter with all this stuff was the document trail that started with
the cat man page, then he would think "-" was broken.
So still an understanding of Unix is implied as the docs perhaps
describe 95% but not yet 100% of what one
J> But the main problem is to figure out where to put such a document
J> so that new users will actually read it. What do you think?
Somewhere around
$ info -o - coreutils|grep -C 2 Intro
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://list
Gentlemen, your assignment: tell me how many blank lines are at the
end of each file:
$ tail -n 3 sd?
==> sd1 <==
=_1201017022-21167-0
==> sd2 <==
=_1201077677-7431-0--
==> sd3 <==
=_1201017022-21167-0
$ tail -n 3 sd{3,2,1} #let's try again, shall we?
==>
EB> Consider upgrading (we've told you this before). The latest stable
EB> version of coreutils is 6.10.
OK, I'll tell debian to get in chime with the times,
http://bugs.debian.org/462340
EB> What are you suggesting?
Maybe something like --omit-blank-line-at-separator. Anyway make sure
it is sho
J> Would you *please* consider sending a precise suggestion
Sorry. OK, To both
man page:
--group-directories-first
group directories before files
And info page:
`--group-directories-first'
Group all the directories before the files and then sort the
directories and
Mention in the ls docs at --group-directories-first, that "-U nullifies
its effects, sorry" :-)
ls (GNU coreutils) 6.10
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
JM> +(@option{-U}) disables this option altogether.
Looks good.
JM> + disable with --sort=none (-U);\n\
Looks bad. One thinks "disable by not using it in the first place".
Just word it like the first one above.
Yes the options are so complicated that one needs a n-to-the-nth-power
grid chart to s
$ cut -s' '
cut: invalid option --
Try `cut --help' for more information.
What do you mean, " "?
I typed an -s. Give a proper error message.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Ok, reported http://sources.redhat.com/bugzilla/show_bug.cgi?id=5762
I bet I will get nasty glibc email, so I leave it in your guys hands.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Please don't let me get away with
# chown : file...
# chown -R : file...
# chown . file...
# chown -R . file...
without raising an error.
"The user thought -R meant --reference. He returned on Monday to find
a pink slip on his desk as the boss was not able to access the presentation."
___
P> Is this just an academic worry, or were you really bitten by it?
Yes. About once a year I do chown -R . file, thinking that -R meant
recursive, oops, I mean "reference"... never expecting it to "work if
it doesn't work", as with most commands, if it doesn't complain, then
it must have worked, a
GbTS> Well, there's your answer. You were probably asking for a date/time that
GbTS> did not exist due to the daylight savings time skip.
OK, but maybe the error message should give more details, as it would
usually be very hard for the user to guess such a rare occurrence.
Say more clearly what default it is you are talking about.
Some may think all processes have a default niceness of 10.
-n, --adjustment=N
- add integer N to the niceness (default 10)
+ add integer N to the niceness.
+ No -n INT is the same as giving -n
Shorthand on the sort page
--sort=WORD
sort according to WORD: general-numeric -g, human-numeric -h,
month -M, numeric -n, random -R, version -V
is not going to be understood by the beginner. Sorry.
Only the Info page makes it clear what you are trying to sa
This message,
mv: try to overwrite `/cf/updates/F.cpio.gz', overriding mode 0644 (rw-r--r--)?
y
does not make it clear that the file owner is different.
mv (GNU coreutils) 8.5
Mention in the join(1) documents that "all bets are off if the file
contains non-unique join fields", e.g.,
a
b
b
c
Also mention if you get this email.
Package: findutils
X-debbugs-Cc: bug-coreutils@gnu.org
Version: 4.5.10-1
Severity: minor
According to http://article.gmane.org/gmane.discuss/14277
any mention of e.g., bug-findutils should be updated throughout this and
other affected packages.
Ah ha, reading
http://article.gmane.org/gmane.discuss/14277
I thought
EA> bug-sh-ut...@gnu.org
EA> bug-textut...@gnu.org
EA> bug-fileut...@gnu.org
EA> have been replaced by
EA> bug-coreutils@gnu.org
i.e., 3->1
when in fact,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638388#1
I see this upon search at
http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=jidanni&submit=Search!&max=20&result=normal&sort=date:late
Search String: [jidanni ] Search! Display:
[20 ] Description: [normal] Sort:
[in reverse chronological
OK
It all started when that guy at gmane got the history backward.
OK, glad to know they are supported. Indeed,
$ join <(printf "%s\n" 'a 1' 'b 2' 'b 3' 'c 4') <(printf "%s\n" a b 'b 5' c c)
a 1
b 2
b 2 5
b 3
b 3 5
c 4
c 4
So be sure to mention it wherever you mention files must be in sorted
order.
I mean probably if you don't mention it, nobody will be sure wh
$ ls -t1 --time-style=%c -og
ls: invalid argument `%c' for `time style'
Valid arguments are:
- `full-iso'
- `long-iso'
- `iso'
- `locale' <-you forgot to also mention "+FORMAT"
Try `ls --help' for more information.
$ ls -t1 --time-style=+%c -og
Well wherever you say 4/5ths of something
that means the other 1/5th does not exist,
so it would be better to say nothing.
Thanks!
> "JM" == Jim Meyering writes:
JM> is misleading in that it might encourage someone to use the []'s.
Like You Know Who :-), who also recommends you figure out a way to get
rid of the
JM> $ src/ls -l --time-style=x
"src/" even in these e-mails/commits, as it is bad for the eye, even though
> "JM" == Jim Meyering writes:
JM> Hence, including that prefix shows what I've done. Without it,
JM> the reader would wonder if I'd simply used whatever ls is in my path,
JM> which could easily represent a mistake.
Well OK then.
The new symlink on Debian,
$ ls -og /etc/mtab
lrwxrwxrwx 1 12 12-23 22:00 /etc/mtab -> /proc/mounts
Has caused
$ df
Filesystem 1K-blocksUsed
Available Use% Mounted on
rootfs 1071468 287940
(info "(coreutils) Backup options") should add some examples, for
"So how do we make a backup file of m?"
$ ls
m
$ cp -b m m #no go
$ cp m n
$ mv -b n m
OK but (info "(coreutils) Backup options") should also link back to the exact
cp -b spot, else most folks will miss it.
P.S., There _is_ an easier way of making backups of several files,
But there is a bug, one has to do it one at a time despite -b. Bug bug bug.
$ \cp -fb h k l .
cp: `h' and `./
JM> I deliberately restricted the "make backup only" functionality to the
JM> very limited case that is documented.
Well you had better explicitly document that it does not work with
all forms in the cp SYNOPSIS, else people will think it is broken...
(info "(coreutils) fold invocation") should mention what happens if the
command is used on multibyte characters.
The man page should too.
sort(1) doesn't say SEE ALSO uniq(1), and vice versa.
Man you guys are bananas using "K" here:
-c, --bytes=[-]K
print the first K bytes of each file; with the leading `-',
print all but the last K bytes of each file
Why can't you use "X" etc. etc.?
It took 15 minutes for me to figure out that you weren't talk
OK, then use "NUMBERS" instead of "K". Something, anything. I swear I
changed my Xquery script several times wondering why it was only
printing the first character instead of 1000.
Anyway your man pages must make sense over the telephone.
Everybody knows K bytes is kilobytes.
You are all under arrest.
I'm sending this to Risks Digest.
$ man head
... print the first K bytes of each file...
I could have sworn they were talking about kilobytes, but no,
they were talking about the first K bytes.
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13216
OK indeed
"print the first K bytes of each file"
would mean something like "print the first FEW kilobytes of each file,"
like
"pluck the first K leaves off of each tree"
naa... that would mean
"pluck the first 1000 leaves off of each tree"
Anyways, the busy executive just glances at these quick re
$ rm -i *
rm: remove regular file `Ph_D_Thesis'? you had better ask my mother
$ ls
$
I think the info pages should make very clear what is going on in this
case, to avoid legal threats one day.
Package: coreutils
Version: 8.13-3.3
File: /usr/share/man/man1/truncate.1.gz
X-debbugs-CC: bug-coreutils@gnu.org
$ truncate /tmp/erere
truncate: you must specify either `--size' or `--reference'
What a shock. Not mentioned on man or info pages!
And
truncate OPTION... FILE...
should be
I thought it would do the obvious, like touch does.
NAME
touch - change file timestamps
SYNOPSIS
touch [OPTION]... FILE...
DESCRIPTION
Update the access and modification times of each FILE to the current
time.
A FILE argument that does not exist is created
Well I bet that rm is as evil.
If the user tries to figure out how to skip one byte
just from reading the dd man page, and not info,
in order to finally figure out how to do
$ echo abc|dd ibs=1 skip=1
bc
it seems
ibs=BYTES
read up to BYTES bytes at a time (default: 512)
should be instead
ibs=BYTES
Package: coreutils
Version: 8.21-1
File: /usr/share/man/man1/split.1.gz
.PP
CHUNKS may be:
N split into N files based on size of input
K/N output Kth of N to stdout
l/N split into N files without splitting lines
l/K/N output Kth of N to stdout without splitting lines
r/N like '
718...@bugs.debian.org
14...@debbugs.gnu.org
Fellows, I don't think
(info "(coreutils) cp invocation")
mentions how
$ touch m
$ cp m n
$ chmod 444 m
$ cp m n #THESE LINES
$ cp m p #MAKE DIFFERENT THINGS
$ ls -l
-r--r--r-- 1 jidanni jidanni 0 07-28 11:20 m
-rw-r--r-- 1 jidanni jidanni 0 07-28 11:21 n
-r--r--r-- 1 jidanni jidann
Thanks.
man uniq:
-d, --repeated
only print duplicate lines
ADD:
, one for each group.
Even though the Info page says something.
In (info "(coreutils) comm invocation")
mention that even with --check-order
there can still be some erroneous output emitted before the error is detected.
Therefore check first with sort -c to be sure...
Fine, when we produce an erroneous death row list, don't blame me...
(info "(coreutils) shuf invocation") says
These examples all have four input lines, so `shuf' might produce any
of the twenty-four possible permutations of the input. In general, if
there are N input lines, there are N! (i.e., N factorial, or N * (N -
1) * ... * 1) possible output per
I note a lot of packages come with
Installation Instructions
*
Copyright (C) 1994-1996, 1999-2002, 2004-2012 Free Software Foundation,
Inc.
Copying and distribution of this file, with or without modification,
are permitted in any medium without
(info "(coreutils) seq invocation")
... seq [OPTION]... FIRST INCREMENT LAST
`seq' prints the numbers from FIRST to LAST by INCREMENT. By
default, each number is printed on a separate line. When INCREMENT is
not specified, it defaults to `1', even when FIRST is larger tha
$ cp -i a/s b/s c
cp: overwrite ‘c/s’? y
cp: will not overwrite just-created ‘c/s’ with ‘b/s’
Mmmm OK, but maybe don't ask then.
All I know is that if it is smart enough to say
>> cp: will not overwrite just-created ‘c/s’ with ‘b/s’
which is indeed rather smart, then it should be smart enough to
gather all its thoughts together before presenting them to the user.
Hmmm, then it should be also smart enough to recognize the col
> "JM" == Jim Meyering writes:
JM> enough that without it, cp is vulnerable to a subtle type of exploit.
Well some word about this should be in some footnote in the cp INFO manual.
> "BV" == Bernhard Voelker writes:
BV> So I don't think the man or info pages are the right place.
Huh? Hush hush for security, or just not to bog the pages down?
BV> BTW: I'm not sure if we're talking about two different things now:
(All one big blur to me anyway.)
> "BV" == Bernhard Voelker writes:
BV> No, there is no (known) security problem. Please read Jim's message
OK then the ought to add a footnote to the docs.
$ touch f
$ mkdir w
$ cp f f f w
cp: warning: source file ‘f’ specified more than once
cp: warning: source file ‘f’ specified more than once
Hey, you yourself say that more than once itself!
So either say
cp: warning: source file ‘f’ specified more than once
just once, or say
cp: warning: source
Cc [EMAIL PROTECTED]
Subject: pr: -T wipes out any meaning of -l
From: Dan Jacobson <[EMAIL PROTECTED]>
Date: Wed, 19 Mar 2003 08:50:58 +0800
Message-ID: <[EMAIL PROTECTED]>
User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charse
101 - 162 of 162 matches
Mail list logo
