bug#15650: "cp: warning: source file ‘f’ specified more than once" said more than once too!
$ 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 file ‘f’ specified again n-1 times.
bug#15232: cp -i a/s b/s c
> "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.
bug#15232: cp -i a/s b/s c
> "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.)
bug#15232: cp -i a/s b/s c
> "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.
bug#15232: cp -i a/s b/s c
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 collision and stop before any of it happens... By which time the algorithm to prevent user error becomes so big as to introduce different errors... so maybe PB> So I'm inclined to leave this as is? is the right thing. The only problem is five years later certain "j" users will rediscover it and write back again expecting a free t-shirt etc. :-)
bug#15232: cp -i a/s b/s c
$ 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.
bug#15068: `seq' prints the numbers from FIRST to (maybe almost) LAST by INCREMENT
(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 than LAST. FIRST also defaults to `1'. So `seq 1' prints `1', but `seq 0' and `seq 10 5' produce no output. Floating-point numbers may be specified. *Note Floating point::. OK but I think you forgot to mention cases like $ seq 0 5 17 Will the last value printed be 15, 17, or 20? the user wonders. Hard to tell from the man/info page.
bug#15066: ./configure && make && make install
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 royalty provided the copyright notice and this notice are preserved. This file is offered as-is, without warranty of any kind. Basic Installation == Briefly, the shell commands `./configure; make; make install' should configure, build, and install this package. The following I think that should say `./configure && make && make install' Please tell whoever writes that file, as the file itself doesn't say. (Bad also!) Also maybe it should say ./configure && make && make install All on its own line for easy cut and pasting...
bug#15055: shuf --all-permutations
(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 permutations. Please add an option to produce all permutations. Perhaps separated by blank lines or a --separator=...
bug#15040: closed (Re: bug#15040: comm --check-order doc boost)
Fine, when we produce an erroneous death row list, don't blame me...
bug#15040: comm --check-order doc boost
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...
bug#14996: man uniq -d mention more
man uniq: -d, --repeated only print duplicate lines ADD: , one for each group. Even though the Info page says something.
bug#14972: cp docs should mention permissions result when destination already exists
Thanks.
bug#14972: cp docs should mention permissions result when destination already exists
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 jidanni 0 07-28 11:21 p All we read is In the absence of this option, each destination file is created with the mode bits of the corresponding source file, minus the bits set in the umask and minus the set-user-ID and set-group-ID bits. *Note File permissions::. So it says 'created', but doesn't mention what happens if the destination already exists. Yes I am deliberately not using -p here. (This would also explain the mystery of how openssh-client: /usr/bin/scp works.) $ cp --version cp (GNU coreutils) 8.21
bug#14971: bug tracking numbers for split man page bug
718...@bugs.debian.org 14...@debbugs.gnu.org
bug#14971: split man page table mushed
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 'l' but use round robin distribution r/K/N likewise but only output Kth of N to stdout becomes 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/Noutput Kth of N to stdout without splitting lines r/N like 'l' but use round robin distribution r/K/Nlikewise but only output Kth of N to stdout on the man page. Tested with # su - nobody -c 'man split'
bug#14846: dd how to skip one byte from reading the man page
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 reset the input block size (default: 512) or something...
bug#14686: Bug#713022: truncate man and info pages must mention -s / -r mandatory
Well I bet that rm is as evil.
bug#14686: Bug#713022: truncate man and info pages must mention -s / -r mandatory
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 empty, unless -c or -h is supplied. NAME truncate - shrink or extend the size of a file to the specified size SYNOPSIS truncate OPTION... FILE... DESCRIPTION Shrink or extend the size of each FILE to the specified size A FILE argument that does not exist is created. Who would have guessed that for some reason an argument is required, I don't see why $ truncate FILE cannot just work too. You know, to truncate the file, to zero bytes. But hey I'm not a pro.
bug#14686: Bug#713022: truncate man and info pages must mention -s / -r mandatory
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 truncate <--size|--ref...> [OPTION...] FILE... Also mention size is in bytes. Don't just hope the reader will examine every options' wording to ferret that out.
bug#14231: mv, rm, cp -i need super clear explanation of -i...
$ 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.
bug#13216: notsp: Everybody knows K bytes is kilobytes
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 reference man pages, so "K bytes" becomes "NUMBER K bytes" in his head rather easily. So best to avoid any dangerous confusions!
bug#13216: notsp: Everybody knows K bytes is kilobytes
$ 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
bug#13216: head(1) man page not talking about kilobytes
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.
bug#13216: head(1) man page not talking about kilobytes
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.
bug#13216: head(1) man page not talking about kilobytes
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 talking about kilobytes. Yes one only has to read down further. But kindly fix it anyway.
bug#11994: sort(1) doesn't say SEE ALSO uniq(1)
sort(1) doesn't say SEE ALSO uniq(1), and vice versa.
bug#11903: fold should mention what happens if the command is used on multibyte characters
(info "(coreutils) fold invocation") should mention what happens if the command is used on multibyte characters. The man page should too.
bug#11809: document "So how do we just simply make a backup file?"
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...
bug#11809: document "So how do we just simply make a backup file?"
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 `./h' are the same file cp: `k' and `./k' are the same file cp: `l' and `./l' are the same file $ \cp -fb h h $
bug#11809: document "So how do we just simply make a backup file?"
(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
bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for /
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 729100 29% / udev 248048 0 248048 0% /dev tmpfs 50564 372 50192 1% /run /dev/disk/by-uuid/551e44e1-2cad-42cf-a716-f2e6caf9dc78 1071468 287940 729100 29% / tmpfs 101128 712 100416 1% /tmp tmpfs 101128 0 101128 0% /run/shm /dev/sda64270273 3711316 341987 92% /home /dev/sda75341549 4336289 733858 86% /var /dev/sda86406856 3024600 3056800 50% /usr output to 1) repeat / twice, 2) give the long name for /. This should be reproducible for anyone who has used standard grub and thus has $ grep -h UUID /boot/grub/grub.cfg /proc/cmdline matches. More details in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653073 .
bug#10253: mention +FORMAT in ls time style reminder help blurb
> "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.
bug#10253: mention +FORMAT in ls time style reminder help blurb
> "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 it yes surely disappears in production. Having walked from the airport... I'll be dead soon http://www.youtube.com/watch?v=Tp8XcAKYsKo&list=PL6E40919035151385
bug#10253: mention +FORMAT in ls time style reminder help blurb
Thanks!
bug#10253: mention +FORMAT in ls time style reminder help blurb
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.
bug#10253: mention +FORMAT in ls time style reminder help blurb
$ 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
bug#9325: closed (Re: bug#9325: document that "all bets are off if the file contains non-unique join fields")
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 what the behavior will be.
bug#9326: update bug addresses to point to bug-coreutils instead
OK It all started when that guy at gmane got the history backward.
bug#9327: searching coreutils archives gives "can't open the index"
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 order] Results: References: [ (can't open the index) ]
bug#9326: gmane.comp.gnu.fileutils.bugs - discontinued list - mark read-only?
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#15 it is really 1->4!
bug#9326: Bug#638388: update bug addresses to point to bug-coreutils instead
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.
bug#9325: document that "all bets are off if the file contains non-unique join fields"
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.
bug#9263: mv overwrite message when owner different
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
bug#9228: Shorthand on the sort page
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 say in this paragraph.
bug#9207: nice -n man page clarifications
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 10. Yes, Info says more.
bug#8241: closed (Date does not exist in that timezone)
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.
bug#8241: Bug#618009: date: invalid date `TZ="America/Chicago" now' but Europe/Paris OK
Package: coreutils Version: 8.5-1 File: /bin/date X-debbugs-cc: bug-coreutils@gnu.org for i in Asia/Taipei America/Chicago America/New_York Europe/Paris do for j in monday now yesterday today tomorrow 12pm do echo TZ=\"$i\" $j; done; done|date -f - gives date: invalid date `TZ="America/Chicago" now' etc. ONLY when in America, and ONLY when using now etc. Monday etc. don't trigger the bug. By the way, America is undergoing a Daylight Savings Time jump right about now.
bug#7877: sleep 5 -4
> "PE" == Paul Eggert writes: PE> (Have I written enough to tempt ... to extend 'sleep' PE> to allow negative numbers? :-) Right you are young man. We here at NerdLabs already use $ sleep -- -100 to give us a few moments to go back and correct errors. But due to National Security, that's all I can say, except that one shouldn't make assumptions about what future generations might want to do...
bug#7877: sleep 5 -4
$ sleep 5 -4 sleep: invalid option -- '4' $ sleep -- 5 -4 sleep: invalid time interval `-4' No fair prejudicing negative numbers. At least document it. 'However, GNU `sleep' accepts arbitrary floating point numbers (using a period before any fractional digits).' is what it says on Debian.
bug#7877: sleep takes undocumented hex args
You see I was trying to make very special arguments to sleep so that I can make sure to kill the one I want pkill -u jidanni -fx sleep\ 22 It is not clear if that will still work. Maybe the man/info page should say a regexp that matches all valid args.
bug#7877: sleep takes undocumented hex args
The documentation doesn't say that one can also use hex args: $ time /bin/sleep 0x10 real0m16.007s However not octal args: $ time /bin/sleep 010 real0m10.003s Maybe say how too.
bug#7618: man mktemp/[deprecated] clarification
man mktemp -p DIR use DIR as a prefix; implies -t [deprecated] -t interpret TEMPLATE as a single file name component, relative to a directory: $TMPDIR, if set; else the directory specified via -p; else /tmp [deprecated] It is not clear what is deprecated, -p, or both. Move [deprecated] closer to the front of the sentence. Or add a DEPRECATED OPTIONS section. Also I know the info page says why, but at -u, --dry-run do not create anything; merely print a name (unsafe) the reader thinks 'why, will it grind up my filesystem?' If --dry-run is unsafe, then I'd hate to try --wet-run. Say (unsafe to use for ).
bug#7568: stat 'i\i' shows 'i\\i'
stat 'i\i' shows 'i\\i'. Backspaces in filenames are doubled. stat (GNU coreutils) 8.5
bug#7529: Bug#605639: deal better with different filesystem timestamp resolutions
X-Debbugs-cc: bug-coreutils@gnu.org, bug-m...@gnu.org Package: coreutils Version: 8.5-1 man cp says: `-u' `--update' Do not copy a non-directory that has an existing destination with the same or newer modification time. If time stamps are being preserved, the comparison is to the source time stamp truncated to the resolutions of the destination file system and of the system calls used to update time stamps; this avoids duplicate work if several `cp -pu' commands are executed with the same source and destination. But it seems that isn't working too much/well, $ touch /tmp/f $ /bin/cp -avu /tmp/f . `/tmp/f' -> `./f' $ /bin/cp -avu /tmp/f . `/tmp/f' -> `./f' $ /bin/cp -avu /tmp/f . `/tmp/f' -> `./f' $ ls -l --full-time f /tmp/f -rw-r--r-- 1 jidanni jidanni 0 2010-12-02 08:25:47.682527260 +0800 /tmp/f -rw-r--r-- 1 jidanni jidanni 0 2010-12-02 08:25:47.0 +0800 f $ mount /dev/sda6 on /home type ext3 (rw) tmpfs on /tmp type tmpfs (rw) It might work great f -> /tmp/f, but not the other way around. By the way, make(1) lacks any of this time comparison resolution machinery at all! I'll CC them.
bug#7502: wc --verbose should say xx lines, yy words, zz characters
Idea: new option: --verbose $ wc --verbose should say xx lines, yy words, zz characters or xx lines yy words zz characters etc. With TAB separator too.
Re: say that cut can't handle more than one field demarcator
> tr -s '[:blank:]' '\t' | cut -f5 And perhaps mention less painful tr -s \ \\t | cut -f5 and perl -anwle 'print $F[4]' if the user's input permits such simplification...
Re: you are not going to be able to sort this by the fifth field.
EB> Except that you can specify overlapping keys. I find the idea of multiple EB> separate lines of underscores, one per key, much easier to follow in OK, any --debug=... is better than nothing.
Re: you are not going to be able to sort this by the fifth field.
Thanks. I see I neglected the -b. On the info page in the `--field-separator=SEPARATOR' discussion, do mention the effects of -b on ' foo' etc. PB> $ LC_CTYPE=C sort --debug -sb -k5,5 < taichung_county_atm.htm (Use .txt, not .htms in examples.) Anyway, your --debug stuff would be clearer with just pipes added inline: $ echo 'a b c'|sort --debug=show_fields a| b| c or something like that.
say that cut can't handle more than one field demarcator
On (info "(coreutils) cut invocation") please add: cut has no way to specify a group of blanks as a field demarcator. If you want that, use perl -a. Also use perl's split if you want regexp demarcators, etc. If that is indeed the case.
you are not going to be able to sort this by the fifth field.
Try as you might, there is no way you are going to sort by this field, $ LC_CTYPE=zh_TW.UTF-8 w3m -dump \ http://www.tcb-bank.com.tw/tcb/servicesloc/atm_location/taichung_county_atm.htm | perl -anlwe 'print $F[4] if exists $F[4]'|LC_CTYPE=C sort without ripping it out of the table first using perl. Go ahead, try -t ... -k ...,... You won't be able to order that field in the same way one can after ripping it out of the table. sort (GNU coreutils) 8.4 P.S., perhaps add a --debug-fields mode which adds field boundary | pipe symbols into the output.
Re: -readable by who
Gentlemen, some of these are clearer than man test or (info "(coreutils) Access permission tests") bash$ help test|grep you -r FILETrue if file is readable by you. -w FILETrue if the file is writable by you. -x FILETrue if the file is executable by you. -O FILETrue if the file is effectively owned by you. -G FILETrue if the file is effectively owned by your group. Likewise, for find -readable, something should be done. > "JY" == James Youngman writes: JY> On Wed, Jan 13, 2010 at 11:06 PM, wrote: >> -readable >> Matches files which are readable... >> Also mention "by the current user" I suppose. JY> Since there is more than one possible interpretation of the "current JY> user" this clarification doesn't help much, I think.
Re: diff "--git"
AMS> That is what it says, though not in so many words. Having an option AMS> for each VS would really be a headache (SCCS, RCS, CVS, hg, darcs, AMS> bzr, tla, git, ...). Well all I know is we then harangue the system administrator for not installing the latest diff that the other guys are already using... when in fact they are not using diff at all and diff --git would fail on their machine too because they have boldly invented a fantasy unlike any other seen there on the command line... So maybe there should be a general disclaimer added about some people spreading false rumors about diff options...
diff "--git"
$ diff --git diff: unrecognized option '--git' I think diff should say at this point "real diff, at least up to year 2010, does not have a --git option, you are probably getting that idea from git output" or something. Or ask those git pros for a patch to give diff a --git option, or tell them that they are overstepping their bounds...
Re: expr say "non integer argument"
$ diff --git diff: unrecognized option '--git'<--see my next email coming soon. $ dlocate src/expr.c|wc 0 0 0 Actually at one point I was much more involved. http://article.gmane.org/gmane.comp.version-control.git/103400 However today its bash: git: command not found for me, as I'm intent on taking it easy.
Re: expr say "non integer argument"
CFAJ> That'll teach me to post early in the morning! The problem is that you live in the incorrect timezone :-|
Re: expr say "non integer argument"
EB> jidanni, it would be a two-line patch to expr.c. Would you care to write EB> such a patch, rather than just complaining? It would be much more efficient for me to just play the role of the bug reporter here trust me. Thanks.
Re: expr say "non integer argument"
> "CFAJ" == Chris F A Johnson writes: CFAJ> On Thu, 18 Feb 2010, jida...@jidanni.org wrote: >> $ expr 3.1 + 3 >> expr: non-numeric argument <---say "non integer argument" >> $ expr 3.1 + 3b >> expr: non-numeric argument CFAJ>The expr command's arithmetic only works with integers. Yes CFAJ>3.1 is not an integer, nor is 3b. Yes CFAJ>To do calculations with decimal fractions, I recommend awk. Yes. 3,1 is numeric!
expr say "non integer argument"
$ expr 3.1 + 3 expr: non-numeric argument <---say "non integer argument" $ expr 3.1 + 3b expr: non-numeric argument
Re: tee|tee|tee
> "GS" == Giuseppe Scrivano writes: GS> jida...@jidanni.org writes: >> The tee(1) documents fail to say what happens when tee is given no >> arguments. Do say what is going on in >> $ echo o|tee|tee|tee GS> "The `tee' command copies standard input to standard output and also to GS> any files given as arguments." GS> it looks quite clear to me, if you don't specify any file then stdin is GS> copied only to stdout. OK, then perhaps mention what actions are a no-op... as it all looks mysterious to beginners.
tee|tee|tee
The tee(1) documents fail to say what happens when tee is given no arguments. Do say what is going on in $ echo o|tee|tee|tee o Also there is a Info reference to (bashref), but here on Debian there is no such match in apt-file(1).
Re: Bug#565218: info boilerplate on man page gives only the hard way
> "MS" == Michael Stone writes: MS> On Thu, Jan 14, 2010 at 06:00:17AM +0800, jida...@jidanni.org wrote: >> Well, it turns out that we find we often can also just do >> $ info WHATEVER MS> Yes, that's why it used to say that. But if something goes wrong with MS> info, that invocation will fall back to displaying the man page, and MS> then we get a bunch of bug reports complaining that the info page is MS> the same as the man page. So, that's why I suggested saying __both__ methods. But you already closed the bug before reading to the end.
Bug#565218: info boilerplate on man page gives only the hard way
X-debbugs-cc: bug-coreutils@gnu.org Package: coreutils Version: 8.1-1 Severity: wishlist We see many The full documentation for WHATEVER is maintained as a Texinfo manual. If the info and WHATEVER programs are properly installed at your site, the command info coreutils 'WHATEVER invocation' should give you access to the complete manual. Well, it turns out that we find we often can also just do $ info WHATEVER Therefore perhaps say info coreutils 'WHATEVER invocation or often just info WHATEVER or something like that.
mv -v, cp -v messages should be different
Gentlemen, I object. The messages for these two commands should be different. $ cp -v f g `f' -> `g' $ mv -v f g `f' -> `g' Exactly how different etc. I leave up to you. Maybe even just => for the latter instead of ->.
Re: quoted-printable [--decode]: it's time
> "JM" == Jim Meyering writes: JM> GNU recode does that: JM> $ printf '\0\1'|recode ../QP Ah ha, then checkmate, $ recode -l|grep -i base64 /Base64 64 b64 I.e., you must either 1. Make a separate quoted-printable(1) command too, just to be fair. 2. Leave a note on the base64(1) man page saying that if one is looking for quoted-printable(1) try recode instead... however this isn't a good place to leave such a note... hmmm OK, whatever. I'll try to remember recode.
quoted-printable [--decode]: it's time
OK, now that there is a base64(1) command, I could have sworn I also saw
a quoted-printable command too [or else I wouldn't have deleted mine so
fast :-(].
OK, I restored mine
$ cat bin/qp-decode
#!/bin/sh -e
#jidanni *** replacement for mime-codecs package ***
case $0 in
*qp-encode)perl -MMIME::QuotedPrint -wne 'print encode_qp($_)';;
*qp-decode)perl -MMIME::QuotedPrint -wne 'print decode_qp($_)';;
*base64-encode)perl -MMIME::Base64 -wne 'print encode_base64($_)';;
*base64-decode)perl -MMIME::Base64 -wne 'print decode_base64($_)';;
*)exit 88;;
esac
And as
$ apt-file search quoted-printable|wc -l
8
aren't coreutils, ("qp" finds even more), I hereby sure wish coreutils
had one.
Bug#545721: info: No menu item `mktemp invocation' in node `(coreutils.info.gz)Top'.
X-debbugs-cc: bug-coreutils@gnu.org Package: coreutils Version: 7.5-3 Severity: minor $ man mktemp|col -b|grep -C 3 'info coreutils' The full documentation for mktemp is maintained as a Texinfo manual. If the info and mktemp programs are prop erly installed at your site, the command info coreutils 'mktemp invocation' should give you access to the complete manual. $ info coreutils 'mktemp invocation' 1>&- info: No menu item `mktemp invocation' in node `(coreutils.info.gz)Top'. P.S., the man page should say what directory the temp file ends up in if no options are given. Maybe it currently does but one has to look among the options to find out. Also mention what "Create a temporary file or directory, safely" means. Guaranteed not to overwrite any other existing file perhaps, and ...
Re: Bug#505927: just use the date(1) -d library instead of your own poorer date parser
>>>>> "BSB" == Bernd Siggy Brentrup writes: BSB> Hi jidanni, BSB> I'm extremely angry about you forwarding my findings to the BSB> Debian BTS. Sorry. I just try to increase people's networking, and assumed the bug number, which I saw in the Subject, had fallen off the CC list and needed to be put back. So maybe I'm not the safest person to send things too. BSB> ps: Do you grant me permission to cite you to at...@free-it.org, BSB> which obviously is an address for at-ng related stuff? Yes, everybody can cite anything I say, it's all OK.
Re: Bug#505927: just use the date(1) -d library instead of your own poorer date parser
>> >> However to get at to accept such a date, one needs: >> >> $ at -v $(date --rfc-3339=date -d 'now + 5 years + 11 months') >> >> Fri Oct 17 03:56:00 2014 >> >> warning: commands will be executed using /bin/sh B'B> How do you like these: B'B> at-ng/build% ./at now + 5 years + 11 months B'B> Job will run at or after Wed, 29 Jul 2015 20:26:00 +0200. B'B> It was a trivial fix adding just 2 lines to the grammar. I'll cc them to let them know...
Re: Bug#505927: just use the date(1) -d library instead of your own poorer date parser
> Regarding http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505927 > "BSB" == Bernd Siggy Brentrup writes: BSB> Hi, BSB> I'm currently evaluating at's wishlist bugs for my 'at' replacement BSB> 'at-ng' which is a complete rewrite from scratch. Uh oh, "at no good"? :-) BSB> On Mon, Nov 17, 2008 at 05:49 +0800, jida...@jidanni.org wrote: >> Package: at >> Version: 3.1.10.2 >> Severity: wishlist >> >> At should be more flexible. Just use the date libraries instead of >> your own parser. >> $ at -v 'now + 5 years + 11 months' >> syntax error. Last token seen: + >> Garbled time >> $ date -d 'now + 5 years + 11 months' >> Fri Oct 17 03:53:15 CST 2014 >> However to get at to accept such a date, one needs: >> $ at -v $(date --rfc-3339=date -d 'now + 5 years + 11 months') >> Fri Oct 17 03:56:00 2014 >> warning: commands will be executed using /bin/sh >> If at would use the same library as date -d, you could 1. parse lots >> more types of dates. 2. Eliminate maintenance of duplicate code. BSB> If there only were such a library, static or preferrably dynamic! BSB> ldd /bin/date shows there is no dynamic one and dpkg -L coreutils shows BSB> no static version either. BSB> I might get coreutils sources and use the relevant parts but that BSB> deprives me of my freedom to choose a license at my will. IANAL but BSB> in my understanding using GPLed source code means you must release BSB> everything under the GPL. I'll Cc the coreutils people and thus hook you up so you fellows can figure out the best way to reuse code. I'm a big Stallman http://jidanni.org/comp/index.html#rms fan, so any license of his is good with me. BSB> I'm not yet decided what to do, in particular when thinking about BSB> i18n which may demand to cope with cultural differences. How does BSB> date handle these? I recall its output was better than its input, but then on your at(1) man page you can say "if at(1) can't parse Chinese dates yet, blame date(1)"! BSB> Regards BSB> Siggy BSB> [1] https://launchpad.net/~at-ng BSB> not much there for now, but by next week there will be BSB> demos for the cli commands at & friends. Server-side BSB> will take somewhat longer.
Re: Savannah report new bug link not obvious
EB> Actually, for coreutils, we are just as happy with email bug reports (as Well do leave a path for those of us who have been toiled-trained by e.g., Bugzilla that the only real report is a browser generated report, and can't find the "Pavlov's dogs lever", http://en.wikipedia.org/wiki/Classical_conditioning (Do mention along the way that email reports are also fine.) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Savannah report new bug link not obvious
> "GS" == Giuseppe Scrivano writes: GS> jida...@jidanni.org writes: >> Logged in to https://savannah.gnu.org/ >> the user cannot find the link to "report a new bug". GS> Is https://savannah.gnu.org/bugs/?func=additem&group=coreutils the page GS> you are looking for? Ah, indeed it is. OK, all I know is when I browse https://bugzilla.wikimedia.org/ (logged in), there is a link "Enter a new bug" in the side panel. What you Savannah fellows need to do is add a similar link to your side panel. Yes, bugzilla then asks "First, you must pick a product on which to enter a bug.". So Savannah could do the same. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
document or fix dangers of sort -u + any other option
Please fix the third command, $ echo -e 'a1\nb2\nc3\nb2'|sort -n|sort -u a1 b2 c3 $ echo -e 'a1\nb2\nc3\nb2'|sort -u|sort -n a1 b2 c3 $ echo -e 'a1\nb2\nc3\nb2'|sort -nu a1 or warn right there on the man page. Sure, you say -u, --unique with -c, check for strict ordering; without -c, output only the first of an equal run but still warn that the above will happen if one tries to combine anything with -u. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Savannah report new bug link not obvious
Logged in to https://savannah.gnu.org/ the user cannot find the link to "report a new bug". ___ 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
say when comm separator disappears
In (info "(coreutils)comm invocation"), after: With no options, `comm' produces three-column output. Column one contains lines unique to FILE1, column two contains lines unique to FILE2, and column three contains lines common to both files. Columns are separated by a single TAB character. The options `-1', `-2', and `-3' suppress printing of the corresponding columns. Also see *note Common options::. Please add: If two of them are used, the separator is no longer needed and will not be printed. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls -l --show-me-each-link-in-the-symlink-chain
> "EB" == Eric Blake writes: EB> According to jida...@jidanni.org on 3/25/2009 12:23 PM: >> ls -l shows you the start of the symlink chain, >> ls -lL shows you the end of the symlink chain, >> but to see each link, one needs many ls -l's. >> There ought to be an option to see each link. EB> readlink is what you're looking for. OK, please add a note to that effect at ls -L. And readlink needs an option to show each link in the chain! ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
ls -l --show-me-each-link-in-the-symlink-chain
ls -l shows you the start of the symlink chain, ls -lL shows you the end of the symlink chain, but to see each link, one needs many ls -l's. There ought to be an option to see each link. Sure, there is usually just one link, but sometimes there is more. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
must use cp && rm as mv has no --no-preserve
Gentlemen, I have discovered I must use cp && rm as mv has no --no-preserve. # touch k; mv k /cf mv: failed to preserve ownership for `/cf/k': Operation not permitted # touch k; cp -a --no-preserve=owner k /cf && rm k You see, moving to VFAT, one will get that message under different mount owners. And the only way to avoid it is my workaround. So do mention on the mv Info page this workaround for if you don't like 2>&-, and don't like warnings, but like -a. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls -s documentation misleading
By the way, turning to -l, looking high and low on (info "(coreutils)What information is listed") doesn't say why ls follows symlinks, but ls -l doesn't: $ ls q f $ ls -l q lrwxrwxrwx 1 jidanni jidanni 1 2009-02-22 01:57 q -> z (Made with:) $ mkdir z $ touch z/f $ ln -s z q ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH,resend] date doc: warn at -d about LC_TIME
We also warn here about LC_TIME, so the user will know even if he
doesn't look in the @xref{Date input formats}.
Signed-off-by: jidanni
---
Also no reply last time. Resending.
doc/coreutils.texi |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index d8df107..35d98b2 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -13470,6 +13470,11 @@ format. It can contain month names, time zones,
@samp{am} and @samp{pm},
14:19:13.489392193 +0530"} specifies the instant of time that is
489,392,193 nanoseconds after February 27, 2004 at 2:19:13 PM in a
time zone that is 5 hours and 30 minutes east of @acronym{ut...@*
+Note: input currently must be in locale independent format. E.g., the
+LC_TIME=C below is needed to print back the correct date in many locales:
+...@example
+date -d "$(LC_TIME=C date)"
+...@end example
@xref{Date input formats}.
@item -f @var{datefile}
--
1.6.0.6
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH, resend] document sort --ignore-case --unique interaction
Signed-off-by: jidanni
---
No reply last time so resending.
doc/coreutils.texi |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index d8df107..06b259c 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -3742,6 +3742,10 @@ is a space or a tab, but the @env{LC_CTYPE} locale can
change this.
Fold lowercase characters into the equivalent uppercase characters when
comparing so that, for example, @samp{b} and @samp{B} sort as equal.
The @env{LC_CTYPE} locale determines character types.
+When used with @option{--unique} those lower case equivalent lines are
+thrown away. (There is currently no way to throw away the upper case
+equivalent instead. (Any @option{--reverse} given would only affect
+the final result, after the throwing away.))
@item -g
@itemx --general-numeric-sort
--
1.6.0.6
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils.texi too big
EB> Care to submit a patch? (To tell you the truth I never tested my previous patches worked in textinfo or texinfo or whatever it's called :-) I just did monkey see monkey do) as you see somebody has to be in the ideas department, passing on ideas to the implementation experts... ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
coreutils.texi too big
Gentlemen, it dawned on me. coreutils.texi is too big, from a source code management point of view. It should be broken down into logical parts, one for stty, one for sort, etc. Then you can pull it all together via @includes. Anyway, it makes no sense for e.g., edits to stty invocation to conflict with edits to sort invocation. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Subject: [PATCH] date doc: warn at -d about LC_TIME
We also warn here about LC_TIME, so the user will know even if he
doesn't look in the @xref{Date input formats}.
Signed-off-by: jidanni
---
doc/coreutils.texi |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index d8df107..35d98b2 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -13470,6 +13470,11 @@ format. It can contain month names, time zones,
@samp{am} and @samp{pm},
14:19:13.489392193 +0530"} specifies the instant of time that is
489,392,193 nanoseconds after February 27, 2004 at 2:19:13 PM in a
time zone that is 5 hours and 30 minutes east of @acronym{ut...@*
+Note: input currently must be in locale independent format. E.g., the
+LC_TIME=C below is needed to print back the correct date in many locales:
+...@example
+date -d "$(LC_TIME=C date)"
+...@end example
@xref{Date input formats}.
@item -f @var{datefile}
--
1.6.0.6
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] document sort --ignore-case --unique interaction
Signed-off-by: jidanni
---
doc/coreutils.texi |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index d8df107..06b259c 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -3742,6 +3742,10 @@ is a space or a tab, but the @env{LC_CTYPE} locale can
change this.
Fold lowercase characters into the equivalent uppercase characters when
comparing so that, for example, @samp{b} and @samp{B} sort as equal.
The @env{LC_CTYPE} locale determines character types.
+When used with @option{--unique} those lower case equivalent lines are
+thrown away. (There is currently no way to throw away the upper case
+equivalent instead. (Any @option{--reverse} given would only affect
+the final result, after the throwing away.))
@item -g
@itemx --general-numeric-sort
--
1.6.0.6
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Date can dish it out, but not parse it back in
OK, better add after `-d DATESTR' `--date=DATESTR' Display the date and time specified in DATESTR instead of the current date and time. DATESTR can be in almost any common format. That it wants ASCII... P.S., nobody saw my http://lists.gnu.org/archive/html/bug-coreutils/2009-01/msg00051.html http://lists.gnu.org/archive/html/bug-coreutils/2009-01/msg00085.html ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Date can dish it out, but not parse it back in
Date can dish it out, but not parse it back in, for other languages: $ date 五 1月 16 00:49:11 CST 2009 $ date|date -f - 五 1月 16 00:00:00 CST 2009 $ LC_ALL=C date|date -f - 五 1月 16 00:49:26 CST 2009 $ locale LANG=zh_TW.UTF-8 LC_CTYPE=zh_TW.UTF-8 LC_NUMERIC="zh_TW.UTF-8" LC_TIME="zh_TW.UTF-8" LC_COLLATE=C LC_MONETARY="zh_TW.UTF-8" LC_MESSAGES=C LC_PAPER="zh_TW.UTF-8" LC_NAME="zh_TW.UTF-8" LC_ADDRESS="zh_TW.UTF-8" LC_TELEPHONE="zh_TW.UTF-8" LC_MEASUREMENT="zh_TW.UTF-8" LC_IDENTIFICATION="zh_TW.UTF-8" LC_ALL= $ date --version date (GNU coreutils) 6.10 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
document sort -uf[r]
Regarding sort: `-f' `--ignore-case' Fold lowercase characters into the equivalent uppercase characters when comparing so that, for example, `b' and `B' sort as equal. The `LC_CTYPE' locale determines character types. OK, but also document this: $ echo -e 'A\na'|sort -uf A $ echo -e 'A\na'|sort -ufr A $ echo -e 'A\na'|sort -urf A The man page doesn't say what to expect. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
No more "Your first commit: the quick and dirty way"
In the file HACKING, please remove the "Your first commit: the quick and dirty way". Just directly mention the right way, "Make your changes on a private "topic" branch" It only costs the user a couple more commands. Else you are starting many first time git users on the wrong foot; days of misery and twisted development habits that will take months to recover from mentally. $ grep -i never git/Documentation/*.txt ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
